Aristos Queue

What Daklu said.

Thanks for the kudos, everyone. Darren and I will take it from here and see how far we get... keep an eye open for the beta program come spring to see if we made the case. :-)

I like to point out to various and sundry constituencies within NI that a teeny tiny handful of customers ever asked for object oriented programming. We never got a field sales engineer reporting "My customers could really use some better encapsulation." But we got tons of requests for the compiler validating the VIs marked as not-top-level in LLBs weren't called outside of the LLB. We never got requests for inheritance, but we have many requests for more code reuse. R&D is fairly aware that the big changes -- the ones that shift the paradigm of LabVIEW, like the Event Structure or the IPE or OO -- are not common user requests. Putting them on the idea exchange is not a bad thing. That still gives us a place to discuss a new idea in the public forums, and it can provide a one-stop-shop for all the ideas we've considered over time. For example, I don't expect my source code control meta language idea to ever rack up high kudos, but I put it on the Idea Exchange to archive it and to allow the few folks that could envision that idea to comment on it. I probably won't ever work on that idea, but maybe someone on my team will at some point. Anyway, I still like that aspect of the IE, and I hope that the "reach for the stars" and the "hey, I can dream, can't I?" ideas still get posted there.

Darren Nattinger (he of Darren's Nuggets fame) and I need your help. Darren is known for writing useful VI plug-ins for LabVIEW. I've had a history of creating hooks in the C++ code for calling plug-in VIs. He and I both dislike the current behavior of the Create SubVI From Selection feature. It doesn't know about the config token for preferred connector panes, it doesn't put error terminals at the bottom and class/refnum terminals at the top, it sometimes names a control "error out" and an indicator "error in", and the panel isn't laid out as clean as we might like. These are all things that could be fixed in the C++ code, but spare developers are always hard to come by, and Darren already has some G code for doing this work. Thus it made sense for the two of us to work out an interface from C++ to G to improve Create SubVI From Selection. In our spare time, we've found the right place in the C++ code to hook, figured out the data that needs to go across the interface, and gotten the code pretty close to finished. Once we knew it was going to work, we asked for permission to add it as a feature in 2011. That's where we hit a problem we cannot solve alone. As many of you have heard, LabVIEW 2011 is focusing on being a stabilization and performance release. Very few new features are being let in the door. The one gate that new features have is the Idea Exchange. The feature has to be limited in the amount of code it has to touch. It has to avoid performance degradation. And it has to be something customers clearly want. We can show two of those three requirements, but not the third. Without the third, the feature does not meet the goals for LV 2011, so even though Darren and I have the new callback hooks largely ready to go, the code cannot go in. This makes us sad. I mean, it makes perfect sense -- we have to have standards, and limiting the features for this release is important -- but it still makes us sad. "Create SubVI" is an area of LabVIEW that many of you have asked me about over the years, hoping that LV could do a better job. Darren and I really want to see this feature go into LV 2010, and we're pretty sure that there are enough of you out there that would like to see it too. If we could get the Kudos on the idea up so that the idea is in the top 15, we will be able to make the argument that this is a feature that users strongly want. Now, not every idea with high kudos is automatically blessed in the 2011 release, but with enough Kudos, we think we can get permission to proceed. There are 3 ideas on the idea exchange that are all affected by this idea, but let's focus on the one that has the highest kudos already: Create a proper connector pane when doing Edit -> Create subVI As of right now, that's got 79 kudos. To make it into the top 15, we need 160 kudos, or almost exactly double what it has right now. I think this is an idea whose time has come. If you agree, please contact your friends. Make peace with your enemies. Call your mother. Encourage them all to take a moment to go vote for this idea. If you're super ambitious, there are two other related ideas that would also be aided by our feature. You could go vote for them too. But focus on the big one first! Provide a way to define the default connector pane Edit >> Create SubVI: Tweaks Help make Mercer and Nattinger unsad! Help improve Create SubVI! Vote now!

The NI Example Finder already has a fairly extensive defined set of categories and search terms relevant to LabVIEW, programming, and the hardware LV is typically used with. It also has a mechanism for identifying VIs that are keyed with those search terms, and it can search both local harddrives and the online ni.com repositories. It may have other options for extending its search locations further. The Example Finder is written entirely in G. I wonder how hard it would be to make it also search for packages?

Congratulations.

Your guess is as good as mine on Project stuff. What does the online help say?

You will always need two classes for this to work.There's a difference between function recursion and data recursion. The first is a function that invokes itself. The second is a data structure that is self-similar as you proceed through it. LV added function recursion, but that changes nothing about how you define the data types. The data recursion is what we're working with here. A class -- in *any* programming language -- cannot include itself. Every time you tried to instantiate the object, it would instantiate itself, and then another copy inside that, and another copy inside that and... boom, infinite data allocation. No can do. To do data recursion, you need two data types. If you create such structures using references, you can do it with two types -- the class and a reference to that class: the class contains a reference to itself. When the class allocates, it allocates itself and a NULL reference, which does not immediately allocate further. LV has a restriction to prevent this -- we don't allow the class to ever refer to itself, whether in a reference or directly. It's an overly broad restriction, logically speaking, but it dramatically simplifies a whole lot of parts of the back end systems -- we felt it was an acceptable trade-off, and we recognize there will be many customers who disagree. Regardless, what I'm showing in my Linked List impl is a by value data structure that is recursive. You still need two types. The parent class does not have a recursive definition. The child class includes the parent. Thus, when you instantiate the child, it allocates a parent, but the value does not immediately go any further than that.

Static VI refs... ... do load the referenced VI into memory ... do not need to be closed ... won't do anything if you do call Close on it

Yes. No different than replacing a subVI with another of the same name. What made this different -- and thus, why we made it securable -- is that you're opening up access scope to call into a normally off-limits function.

That is... weird. Try changing the conpane of one of those VIs -- change the input terminal to Dynamic Dispatch Input, save it, then change it back and save it again. See if that gets it out of the list. No, it doesn't. That's deliberate, although possibly wrong in retrospect. It's a philosophy question -- what does the label even mean on these terminals? Is it the name of the parameter? If so, it should be the same on all the overrides. The fact that it happens to default to the same as the name of the original parent class notwithstanding. If it is the name of the class, well, for one thing, it is redundant, but it also would mean it should change with each level of inheritance. Honestly, in retrospect, I think the default names should have been something like "dispatch in" and "dispatch out", but I know a lot of people wouldn't like that for various reasons.

2nd alternative: Change the output FPTerminal to just be "Recommended" instead of "Dynamic Dispatch Output (Recommended)". A dynamic dispatch VI does not *have* to have a dynamic dispatch output to match its dyn dispatch input. Making that change would free you of the requirement of maintaining object type across the diagram. WAY MORE IMPORTANT: When I replied before, I was concentrating on the syntax of your diagram and I offered a work around. Now I'm looking at the semantics of your diagram and I'm seeing an issue. Pump is a class. View is a child of Pump. This VI is Pump.lvclass:MessageLoopStopped.vi. Why isn't all of this code on View's override of this VI? In other words, you should create an override VI of this VI on the View class. Whenever the object is a View object, you would dispatch to that version. That eliminates the To More Specific node entirely. Currently, you've got all the children of Pump that do not have their own overrides calling into this VI and they will all return an error because they are not View objects. Do the overriding properly and your issues with the dynamic dispatch propagation vanish entirely.

The node might produce an error. When it produces an error, the output object is not the same type as the input object -- it is a default value of the type wired to the center terminal. Your output FPTerminal is marked as "Dynamic Dispatch Output". That means that the data from Dynamic Dispatch Input may pass through any nodes that modify value, but not through any nodes that modify type. This node can modify type.If you are 100% certain that the downcast will always succeed (because of other logic in the rest of your code ensures this), use the "Preserve Run-Time Class" primitive. Like this: You must wire the center terminal directly from the Dynamic Dispatch Input terminal for this to work so that the node has the original type of the class to work with. If you're not 100% certain the downcast will succeed, run your error cluster wire through the Preserve Run-Time Class prim -- that will tell you when the object couldn't maintain the contract.

No, I am pretty sure it only applies if the password is applied.

One reason: Friends are not loaded into memory when the library loads. But for the security model to work, friends that actually take advantage of the friend relationship have to be marked so that we know that the password was properly supplied when the subVI was dropped. This prevents someone from creating a new file of the same name and swapping in new functionality under the guise of friendship. Thus, if you do "Save As:Rename" on the library, all the friends of that library need to load into memory to update that mark. The path lets the project do this loading. There may be other reasons. I flagged this thread for Trevor since he's the primary developer of friend and community scope.

Um, no. I meant what I said.

Probably and yes.

Have you reported this on ni.com/forums so that a bug report can be filed?

You don't. You put a case structure in the one frame of the event structure that handles Value Change event for the list box.

I bet there's some use cases it doesn't handle. On MacIntosh, does it support the D and S keys?

You're right, we don't, but it is all in C++ code. Never had anyone ask for it before, believe it or not. Unlikely at this time. That's a massively non-trivial task, as in, it took 4 months and four LV developers to get it working for all the various use cases when we rewrote it in LV 8.0. Funny... that's what we said about LV 8.0. Yes. Your time will be better spent.

Try just setting the VI.Path property without calling Save, then call save on the Library, then call save on the VI. If that doesn't work, I think the GOOP Toolkit from Symbio does it by removing all the VIs from the library, saving the library, then adding the VIs back and saving again.

There's a program called Jing. There's a free download of the app. It allows you to capture video of your clicks, and it works in Windows XP (there's app for doing this built into Windows 7). Just to make sure everyone is on the same page, I'd suggest downloading Jing and recording the SWF file showing the bug and then posting it on ni.com/forums so that a CAR can be made and tracked as necessary. Jing has been very valuable for recording exact steps to reproduce in a couple of CARs I've worked on lately.

Nope. The icon was included in the icon library for completeness, in case you had some method like "Set To Public" or "List All Public Methods" or somesuch for which the green key was needed.

You should change the title. This covers both New Accessors and New Overrides.