Aristos Queue

The reason that it cannot ever be fixed for these types is that these types are hacks. They use the Type Cast primitive to cast over to be datalog file refnums, but they are not actually datalog file refnums. The "Not A Refnum" primitive does work for datalog file refnums, and it is correctly returning FALSE that these refnums are not valid datalog file refnums. Take a look at the circled part of the Context Help for a Semaphore wire...

A) I'm completely with Jon on this one. If you have a subVI that does all this work, why not just call the dynamic dispatch VI inside the inplace element structure? B) If you really want to go with your solution, the following code does the same thing as yours but will seriously outperform yours:

A reasonable question. First of all, you clipped the full phrase. I said "stability and performance release". The emphasis here is in going beyond basic functionality to fix issues that individually aren't important but collectively are.A lot of the work is focusing on optimizing behind the scenes code. Good code development says "functionality first, optimize later." Decades of software research show that developers have a very poor sense for what will slow a product down, so trying to optimize code too soon generally just leads to code that is hard to maintain and doesn't actually hit the hotspot. It takes a lot of effort to get high performance code, and so LV R&D generally spends that effort on the execution engine, so that VIs run fast. We don't often spend time hammering the performance of edit-time features. Within an editor environment, lots of small slowdowns can be added and users won't really notice. Fixing them can be time consuming and doesn't actually improve the user experience. A good example is some new feature adding 100 ms to the launch time of the application. No one notices when the application launches slower by 100ms from one release to the next. But add 100ms every release for 10 releases, and suddenly a full second is definitely noticed. But when it comes time to fix that, each of those tedious 100ms fixes has to be tackled individually, diverting a lot of development effort from any other work. Then there are the dark corners. For any set of features, each feature can be tested thoroughly in isolation. In that respect, it is functional. When you start testing the interactions between features, the possible interactions can exceed what developers can brainstorm. So two features used in conjunction may have unexpected behavior. I don't mean that it crashes, just that the results are counter intuitive. The vast majority of these are corner cases -- probably encountered by a small handful of customers at most. As such, they can go many releases before anyone reports them, and even when reported, they're not severe enough to get priority attention, especially if a workaround can be found. And they're not severe enough for the lone customer that reported it to stop using LV. It's an irritation, not a showstopper. Any single dark corner may annoy a couple users. As the number of dark corners grows, each user has one corner that they are annoyed by. Eventually, that collective annoyance really can become a showstopper, even though no single dark corner in the collection is actually a serious problem. The best example I can point to is terminals on some nodes that are slightly not aligned with the general patterns of LV, so wiring to/from them always produces a 1 pixel kink wire. Have that on one node, not a critical issue. Have that on every node, critical issue. How many nodes does it take to make it a critical issue? The difference between a patch and a stability and performance release is largely in the integration between features and how deep into the corners we sweep. A patch fixes very targeted bugs, bugs that crash, bugs that have been specifically noted by a large number of customers, or bugs affecting high profile features which have no workarounds available. This release is going after a lot of non-critical issues.

It is definitely fair. It is always the case that one idea or another will get implemented, but not both. There are really good ideas on our brainstorm list that have been on the list since LV 1.0. Someday they may bubble to the top. The idea exchange is not the sole arbiter of "what comes next". Various business interests can push a feature forward. An individual developer working in his/her domain can push a feature forward. What has changed in the last two years is that now the Idea Exchange can push a feature forward.

I think we can all agree that we could easily drum up kudos for that idea as we did with the Create SubVI idea -- making save work after undo has years of customer requests behind it that predate the Idea Exchange.... call it "historical Kudos." :-)

If you want to check out the current list of "in development" ideas, click here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas/status-key/indevelopment/tab/most-kudoed This will pull up a list of ideas filtered to those with status set to "In Development". The list is short this year -- please remember what NI folks have said since the NI Week keynote: LV 2011 is going to be a stability and performance focused release. Even though only a few new features are going in, the ones that made the cut are going to put a smile on a few faces. I know that I'm already enjoying that on my development box I can -- wait for it -- save and then undo! Applause for the pair of really bright developers who figured out that little trick. Anyway, take a look -- there's something in there for everyone.

This is correct. Probably should've just left it blank instead of putting in the ? image. Think it should be changed?

Nevermind.

The review from our side happens but once per year as we're planning out the next release. Start with the highest kudos and review for feasibility and available developers (some changes, although small, may require expertise in a particular subsystem, or we may not be allowing changes in a particular subsystem in a given release in order to make changes to another system that depends upon that one). Work our way through and produce the list of the ones we think we can do. Then get far enough into development that we're sure we can complete the idea before the end of the release... only then does an idea flip over to In Development in the public views. You can generally expect that sometime each year in October/November that the next block of ideas will move to In Development. As to the "being ignored" status, that's part of why I try to post comments in the threads, to let people know that an idea has been seen by someone at NI. The ideas are read by a lot of people, but most developers don't post often. And an idea that is sitting at 80 kudos is neither under consideration nor in danger of closed "not in a million years". It may bubble to the top as we knock out higher kudos ideas. You never know when an idea with just 79 kudos could, in 48 hours, shoot up to 160+ because someone decided to push for it. Also, in a future version of LV, we might have more developers available to tackle new features, instead of the few that we have this round. The whole system is less than two years old. It's an experiment in trying to improve the feedback into LV dev cycle. But that cycle moves in years, not weeks. If an idea has been on the Exchange without real movement for five or six years, then I think we would discuss killing them off.

The number of users who vote for one idea is pretty high. My personal theory is that few people visit regularly. VERY few people have any interest in reviewing the ideas on a regular basis. I've been thinking that when a new idea is posted, it should not be made public -- we should save up a block of ideas and release them once a quarter, or maybe when we hit some target number (say, 50 new ideas). That way people do one visit, scroll through the latest list, and vote for the ones they like. If it is much more infrequent, I think people are more likely to take a moment to scroll through the list. I base this theory on the burst of votes that the 24 ideas that I summarized in an ni.com post -- people saw that post and they went and reviewed the ideas, and they voted. These were clearly people who hadn't seen those ideas before, but many of them had voted for other ideas on the exchange. Thus, I think the problem is one of visibility, not enthusiasm.

Ideally you wouldn't inherit from anything with an Initialize method. You would create an abstract parent class, move all existing methods and data up to that class (except for the Initialize), and your new class would be a sibling class, and thus able to have its own initialize. This is ideal because it maximizes flexibility for future development since each actual concrete class can evolve independently. Sometimes it isn't possible to make this mutation (especially if you need the LV auto-mutation of flattened strings to work for values saved in files or because you don't own the parent class), but if you can, that's probably the best route. When you can't do that, have a protected InitCore.vi that takes a dyn disp input and a public "Init X.vi" where X is the name of the class that does not have the class input. The descendant class would create its own "Init Y.vi", and it would call InitCore.vi to get the parent segment initialized.

And here's the results:

I posted an experiment on ni.com. It's a unique approach to making extensible options dialogs. I have no idea if the parts of it that don't work can be improved, but Yair asked me to post it publicly -- I built it over the course of yesterday and this morning in response to an experiment he tried on his end, which inspired my attempt. You can read more and get the VIs here: http://forums.ni.com/t5/LabVIEW/An-experiment-in-creating-compositable-user-interfaces-for/m-p/1262378#U1262378

Ok... I have something that works well enough now. Thanks for the various suggestions. Winner is Hooovahh for best suggestion. Kudos!

Except that the goal is interleaving, not just concatenating. And if there's an ordering to the interface, the later plugins can dynamically adapt to the content of the earlier plugins.

That still runs into the question of how to pass the click along... I don't know of any VIs that let me say, "Tell VI that a mouse click just happened *here*. Do whatever it is you would've done had the click actually occurred on you."[Later] The screen shot also runs into the problem of updating the visual for mouse move, or for things that are continuously updating as the VI executes. Dead end, but thanks for the idea.

I've been thinking about a UI design that would involve stacking multiple -- maybe 4 or 5 -- subpanel controls, one overlapping the other, with the option "Make Panel Transparent" enabled so that you can see one panel through the other. The problem I'm running into is that mouse clicks are not similarly transparent -- i.e., if I click on the stack of subpanels, the controls in the top panel are live, but the mouse click does not fall through to the panels behind it. Does anyone have a solution to the problem? Anyone figured out a way to redispatch a mouse click to the next layer down?

In general, go with #2 or #3, but each of those has enough advantages/disadvantages that you'll have to look at the behavior of your specific program.

LVOOP has only been out for 4 years. That might sound like a long time in computer terms, but in terms of writing high level programming design texts, it's very short. Having said that, this December, a revised LVOOP customer education course from NI will be available, which does include lessons on design. In the short term, there are several texts on designing various subsystems you can find by going to ni.com and searching in the search bar for "LVOOP FAQ" and scrolling to the bottom of the FAQ document -- it includes links to a few design papers. There's also good stuff for OO design in the 2010 NI Week presentations (instructions for accessing those are included here).

You're looking at a limitation of classes. If the same class is loaded in two projects, it cannot be edited. Plain and simple as that. It has to do with applying edits from one project to the other in a meaningful order. There are many cases where you can edit a file in one project and another file in the other project and the class, which depends upon both files, has to handle the resolution of those changes, but the order in which the changes are applied matters for how the class finally ends up, and there's no way to resolve the changes. And then I read this... jgcode is right... that's very odd... I was assuming that one class used the other and thus they were both loaded in both projects. Is there a third app instance that you're loading these classes into?

Right click on the class in the project tree and select "why is this library locked".

There's an idea on the Exchange that we're thinking of doing in LV 2011, but we've run into some usability stumbling blocks with exactly how the feature should behave. Please follow the link and read the post from ChethanR about the options that R&D is considering for this feature. None of them seem to be the right thing, yet. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-type-def-from-block-diagram-constant/idc-p/1256064#M7875

Hey! No taking G's name in vain! No wonder LabVIEW doesn't always work for you!