LabVIEW Public Beta Program in 2024
New Open VI Reference Functionality
Going to the other thread, the following ini key was mentioned.
showRunAtAnyLoopMenuItem=True
I enabled that and toggled the option on Open VI Reference and the freeze is gone.
Of course, now I'm wondering how safe it is to keep that option enabled. It seems like something that should just be, no option should be required. This gets back to "Why is so much being done in the Root Loop and/or UI Loop?"
@crossrulz wrote:
Going to the other thread, the following ini key was mentioned.
showRunAtAnyLoopMenuItem=TrueI enabled that and toggled the option on Open VI Reference and the freeze is gone.
Of course, now I'm wondering how safe it is to keep that option enabled. It seems like something that should just be, no option should be required. This gets back to "Why is so much being done in the Root Loop and/or UI Loop?"
I think, and I feel it's plausible, the root loop has to be idle when you use a string or path. The VI could be in development.
However, if the static VI reference is strict, the VI is locked, and this might eliminate the need for a free root loop.
So in this new situation, where the string\path is replaced with a strict reference, the conditions might actually be safe to skip idle root loop.
This also explains why a non-strict reference on the string\path input still needs a free root loop. This doesn't guaranty the VI is locked.
Just a though. Not sure if it holds.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
But this doesn't!!
This is a HUGE win!
Unfortunately, that may indicate another bug. I'll have to dig into the details but don't be too shocked if this changes in the future.
A note on root loop:
The phrase "a free root loop" was used and that doesn't really make sense. There aren't multiple root loops out there like a resource you can claim. Root loop refers to the UI thread being idle. When we are in a tracking loop, like operating a control or menu, we can do background execution in the UI thread but it is also in the middle of doing something else. Many operations are not safe to do in this situation because it would impact the ongoing operation. With the tracking example, the code would be very confused if the window containing the menu was closed while the menu is being tracked. Similar things can happen with loading, unloading, and even cloning of VIs. This is why it can be dangerous for us to create a VI reference when not at root loop.
@GregR wrote:
wiebe@CARYA wrote:
But this doesn't!!
This is a HUGE win!
Unfortunately, that may indicate another bug. I'll have to dig into the details but don't be too shocked if this changes in the future.
It already stopped working in the patch.
@GregR wrote:A note on root loop:
The phrase "a free root loop" was used and that doesn't really make sense. There aren't multiple root loops out there like a resource you can claim.
That's semantics., and AFAIK it is correct, although a native English speaker might phrase it differently..
I know there's only one root loop.
As far as I know "it needs a free root loop" means the same as "it needs the root loop to be free", precisely for the reason that there is only one.
@GregR wrote:
Many operations are not safe to do in this situation because it would impact the ongoing operation. With the tracking example, the code would be very confused if the window containing the menu was closed while the menu is being tracked.
I appreciate that it's complex, but as it is, it is a enormous problem. And it always has been.
I can't stress enough how limiting this is.
Now, I can deal with this, although there are situations where even I can't win from LabVIEW.
For beginning LabVIEW programmers, this is a puzzle they won't solve.
Note that dynamically starting VIs is commonly suggested as a 'solution' for all kinds of problems. Considering this 'root loop' it's rarely a real solution though, but rather a time bomb destroying otherwise perfectly fine design patterns.
Making things worse, as a programmer you might not notice until a user actually starts using the release after months of building on the design pattern. After ~25 years using LabVIEW even I fall for this every now and then.
@GregR wrote:
Many operations are not safe to do in this situation because it would impact the ongoing operation. With the tracking example, the code would be very confused if the window containing the menu was closed while the menu is being tracked. Similar things can happen with loading, unloading, and even cloning of VIs. This is why it can be dangerous for us to create a VI reference when not at root loop.
So, do something about it!
Simply not letting us (reliably) use dynamically load and\or starting VIs isn't really an option.
A strict static VI reference does lock the VI, and VIs that are actually used as a subVI are locked as well. So why does the root loop
Again, this is a big problem.
@Darren wrote:
it's unsafe to assume nodes with this setting will function properly in all cases.
It is safe to assume that the nodes without this setting don't function as expected too though.
To anybody except very experienced LabVIEW programmers, this is simply a bug waiting to be discovered by a user.
@Darren wrote:I'm assuming this guidance is still equally valid today, so I strongly suggest not enabling this option on any VI Server nodes in your code, and not propagating knowledge of this INI token.
We should stop propagating Call By... and Run Method too (basically anything "dynamic VI"). Or accompany it with it's 4 page manual that doesn't exist yet.
There's no alternative, is there?
Here's an idea that is related Run As SubVI method - NI Community.
And also Run Method should not run in the user interface thread - NI Community.
What I just don't get is that Open VI Reference doesn't need "the root loop to be free" (I'll use IRL, for idle root loop), unless there's a strickt type wired to it.
I also don't see why anything dangerous could happen to the VI. The VI is marked as running (when it's also used as SubVI or if a strickt static ref is used)... It's like any sub VI, and a sub VI is safe to call. Nothing bad can happen to it, IRL or not.
It seems to me the IRL protection is needed for corner cases (like the VI is editable), but could be loosened in very typical cases. Of course, that's all guessing, as there's no insight of any kind explaining how it works or why.
Note that it's not just menus (VI, context, even diagram) that lock the root loop.
MessageBox, Browse buttons, Palette, Tools menu, even a mouse grab to resize a FP. (Often CLFN and .NET probably too). This is global, so any of these actions block the root loop, even if the action is in a totally unrelated VI
Resizing the options dialog blocks Open VI Reference regardless the strict input.. I can live with that, but it sure is silly..
