Aristos Queue

You can't modify the VI at all in the builder VI. Doing so will always wipe the undo stack. You are setting "Active Frame" during the builder VI. You are also deleting frames by calling Remove Frame. None of that should happen in your builder VI. The only modifications to the block diagram should happen if and only if the user actually clicks on your menu option. Looking at your code, I can't see any reason for the code in the For Loop in "Replace with TES.vi" to even exist.

I want to let LAVA know about a feature of LV 2016 that may not get much press. The In-Place Element structure has a new pair of border nodes to let you access the attributes of a variant without copying them out of the variant. This will VASTLY improve the performance of tools that use variant attributes as lookup tables. I strongly encourage everyone who works on this to look at the shipping example: labview\examples\Performance\Variant Attribute Lookup Table\

You have that backward. It has to be reentrant to allow for recursion. If the VI is non-reentrant, it will be broken when you drop a subVI call to itself on its own block diagram.

ARC5200: Here's another example similar to the linked list example written in LV 8.5. What I did in that old example still works today, though there's some cleanup I could do on the code in a more modern editor... still, it should give you code you can load and look at for inspiration.

JKSH: I wasn't commenting on the pros/cons of naming/renaming user events. I just wasn't seeing the connection to this feature. :-)

Oh. I see the older post. I'd forgotten about that idea. ShaunR: It's a good thought you had, but, no, this doesn't change anything with respect to constant propagation or anything like that.

I don't understand. Why would you expect VIMs to have changed anything with respect to events? This is an edit-time feature, not a run-time feature. Can you explain the link that you're seeing?

Unfortunately, the beta is closed to new members now. The beta cycle is finishing up now. To borrow from a popular TV show: "August is coming." :-)

Giant VI hierarchy. Runs for some long amount of time. Somewhere in the mess, a value is generated that is causing the program to go awry. You only know about it at the point where the program goes wrong, which appears to be a long way from where the value was generated. Your challenge: Find the VI that is generating that value and make it generate some other value. I've had to debug things like this in LabVIEW before... I just tried something that worked surprisingly well. It works if the value to be generated is somewhat unique in your application (i.e. a particular string or a particular double value... doesn't work so well for common values like "1" that may occur a lot in your application). Steps: Run a quick bit of scripting to change all of your VIs to enable "Show front panel when called" and disable "Close afterwards if originally closed". See picture. Run your top-level VI. Set a breakpoint in the subVI where things are going wrong -- which you know has to be after the value is generated. (optional) Abort the VI hierarchy. This just cuts down on other stuff happening in the system. Now you can use ctrl+F and do a text find for the value. Because all the panels were open, the value they last emitted is on their panels. Even if it is nested inside an array of cluster of array of cluster of... etc. Even if it eventually got packaged into a DVR or passed through some other data-passing mechanism, the original VI that generated the value will still have the value on its panel unless that VI has been called again for some other purpose. This does slow down your whole application -- having the panel open makes LV spend a lot of time updating the controls and indicators, which is a lot more data copies. But at least in my most recent case, this strategy was effective. I figured I'd pass it along. By using the "Show front panel when called" option, you get all the reentrant clone VIs, which you won't get if you just open all of the source VIs in your project.

I got a question asked today: "So... if you don't invoke the Call Parent Node at least once a week, do they start worrying and invoke the Call Child Node?" :-)

There is a Sunday gathering already planned. Details: https://decibel.ni.com/content/message/130541#130541 I just realized you're asking about meeting *before* that event. My mistake.

"Open" is used in two contexts. Opening the VI is separate from opening the front panel of the VI. Run when open -- specifically when the VI is opened using File >> Open or its equivalent of double clicking the VI in the OS file system. It has no effect on VIs loaded programmatically. Open panel when called -- when the VI is called as a subVI, open the VI's panel.

Terminals are at the edges of nodes. You clicked in the middle of the node. Try again over one of the connection points. :-)

When you opened your VI, you should have seen a dialog looking for its dependencies. To get the error dialog that you show in your picture, you hit Cancel when it asked you to find the missing files. If you reload the VI and this time tell LabVIEW where to find the subVIs that it asks for, you can then save the VI and you won't be prompted in the future.

Depends upon how you configured your build. There are options in the build settings to include or exclude them as you choose.

Ah... I didn't have any property/invoke nodes on this particular VI, nor did I have anything special set in VI Properties... of the various reasons to hold the FP in memory, none existed from LV's point of view. I just need some sort of static property node to signal "hey, I'm doing UI stuff with this thing." Probably a rare use case -- most UIs are going to have *some* property work.

If I run it with the panel hidden and then close the panel to insert it into the subpanel, that's going to reset all the values to default values, isn't it? (that's what it seems to be doing for me... maybe I've still got something wrong.)

I would like to run a VI, open its panel Hidden, execute it to update all its indicators and then display that VI's panel in a subpanel. Can I do that? Or does a VI have to already be running before it goes into a subpanel? Do I have to close the panel before I put it into the subpanel? I think there's at least some special cases because I've burned myself a few times in the past trying to set up similar situations. I just don't do UI work often enough for it to stick in my head, so I figure someone here who does UI regularly knows what I have to do to get as close as possible to what I want to achieve. PS: After I put the panel into the subpanel, can I close the reference or do I have to keep it open so that the VI stays in the subpanel? If I don't close it and then put a different panel into the subpanel, will the subpanel close the reference for me?

No.

Nope. That's what we want to see from you. This was released as an exploration of what's possible. We have some things that we think would be improved by channels, but we're still exploring the design space. Our goal at this point is NOT to convince you to use them. Our goal now is to see if given them if you find interesting and powerful things to do with them. That may both surprise us with new uses and let's us see what areas are worth more detailed expansion. Had this been an actual release, this feature would have been accompanied by useful example programs and more detailed instructions for use.

My download location won't help you -- I copy mine off of the build machine. :-) To the best of my knowledge, the Mac version isn't available for public download. You purchase it by contacting NI and they tell you how to get it. Details here: https://www.ni.com/mac/ Mac version doesn't have all the same license controls on it to limit piracy, so it isn't just downloadable the way the Windows version is.

TL;DR: There are further developments that will layer on top of channel wires, but the hypothesis we are testing is that channel wires are valuable to write code faster (fewer mouse clicks than setting up other mechanisms mentioned above) that is more comprehensible to future readers of the code and more verifiable for tools like VI Analyzer or code review buddies. Feedback on the hypothesis is welcome. The goal with channels is to provide a visualization of the asynch communication code paths. Shaun may not see evaporating wires as a weakness, but most users do. Users generally, in our observation, do better learning code bases where the code on screen shows what's going on instead of implying what's going on. When data disappears into a queue/event/global/shared-variable/etc., we observe developers unable to keep in their heads where that connection goes. It also means it is impossible for developer to assert all of the points in the code that have their fingers on a comm channel. So channel wires depict the communication. They can run into subVIs. Most of them can be probed (probing is not something we added to all the channel types... we're still playing with how that debugging experience should work). The channel wires also give the compiler a chance to substitute the underlying communications mechanism on different targets. Queues are desktop specific; resource refs are FPGA specific. A channel that just expresses the protocol desired might be compiled one way on one target and another way on a different target with no need to re-code the subVIs. We're also playing with wires that express connections across targets. No idea how that will turn out.

Honestly, folks, JeffK told me years ago it was an experiment he tried that eventually turned into inline VIs. I had no idea there was more to it or I probably would've tried to productize it years ago. One key caveat -- it does use an XNode to do its work. We'll all need to step lightly exploring this part of the LabVIEW attic.

This is why I do my development with the native Mac LabVIEW rather than run in any sort of virtual machine. If for some reason I really want Windows LabVIEW -- generally because I'm drawing a UI with system controls and I want to see how it looks on Windows -- I remote desktop into my work machine. But when I'm developing on my laptop, I just use the Mac version. Avoids all of these weirdnesses.

https://lavag.org/topic/19151-new-community-repository-of-shortcut-menu-plug-ins-for-lv-2015-and-beyond/