LabVIEW Public Beta Program in 2024
New Open VI Reference Functionality
Per LabVIEW 2024 Q1 Features and Changes, Open VI Reference can now accept a VI reference for the vi path input. I took a vim I use for calling reentrant VIs and started to play with this new feature. With this new feature, I was able to eliminate a property node from my vim (getting the VI's name). I wired a strict typed static reference straight to the vi name input and left the type specifier unwired. I saw my VI type properly propagate, even allowing me to wire up a Start Asynchronous Call. But I got error code 1026 when I ran the code at the Start Asynchronous Call. The Open VI Reference just returns a Not A Reference and no error. The fix was to wire up the type specifier as well. But this just seemed strange that if I am giving Open VI Reference a strict typed static reference for the path, why do I also need to tell it the type in order to get a runtime reference? And if this is by design, why am I not getting a compile time error?
Attached is my code for reference.
To get a strict type from Open VI Reference, type has always been required. So I guess this behavior would be a nice to have. Of course if it compiles it should run.
So what if you don't want a strict type from the strict reference?
Is it harmless to simply ignore the strictness....?
Is there any penalty (e.g. performance) for getting a strict type when you want a normal reference? Because AFAIK it's impossible to go from a normal reference to strict type...
Search LabVIEW like a graph!
wiebe@CARYA wrote:
So what if you don't want a strict type from the strict reference?
1. Use a non-strict constant to the type specifier.
OR
2. Just use a non-strict from the beginning
It just makes sense to me that if you wire a reference to the VI Path, the output should match the reference type (string or non-strict) by default.
@GregR wrote:
It's a bug. The type propagation is intending for this to work. Unfortunately the execution code is creating a non-strict reference so we end up with a non-strict reference on a strict reference wire.
I just saw that 2024Q1 Patch 1 dropped on Friday. This bug (2643576) is on the list of bug fixes. I'm installing it now and anxious to test it out.
Attached is my updated example with 2024Q1 Patch1 installed. It works perfectly. This update is going into my reuse library.
I know this is a small, possibly niche, feature, but it is one of the small things that does make things a lot simpler. Good job on this, NI.
The strict type seems to work for me.
More importantly, if the type isn't wired, Open VI Reference does not wait for a free root loop!
In <24Q1 this hangs when a menu is activated:
It's the only way to get a strict type reference.
This doesn't wait for the root loop, but it's not a strict type (e.g. no Call By Ref, Call And Collect\Forget), the alternative, Run VI method, also needs a free root loop...)
In 24Q1, this still needs a free root loop:
But this doesn't!!
This is a HUGE win!
Also see Re: What am I doing wrong with asynchronous call and forget? - NI Community
wiebe@CARYA wrote:
The strict type seems to work for me.
More importantly, if the type isn't wired, Open VI Reference does not wait for a free root loop!
In <24Q1 this hangs when a menu is activated:
It's the only way to get a strict type reference.
This doesn't wait for the root loop, but it's not a strict type (e.g. no Call By Ref, Call And Collect\Forget), the alternative, Run VI method, also needs a free root loop...)
In 24Q1, this still needs a free root loop:
But this doesn't!!
This is a HUGE win!
Also see Re: What am I doing wrong with asynchronous call and forget? - NI Community
Now try it with an option flag wired up to the Open VI Reference. I'm seeing the "freeze" at the Open VI Reference if I have a menu open.
@crossrulz wrote:
wiebe@CARYA wrote:
The strict type seems to work for me.
More importantly, if the type isn't wired, Open VI Reference does not wait for a free root loop!
In <24Q1 this hangs when a menu is activated:
It's the only way to get a strict type reference.
This doesn't wait for the root loop, but it's not a strict type (e.g. no Call By Ref, Call And Collect\Forget), the alternative, Run VI method, also needs a free root loop...)
In 24Q1, this still needs a free root loop:
But this doesn't!!
This is a HUGE win!
Also see Re: What am I doing wrong with asynchronous call and forget? - NI Community
Now try it with an option flag wired up to the Open VI Reference. I'm seeing the "freeze" at the Open VI Reference if I have a menu open.
Ah, I see, so that's the bug they are going to fix!
Hopefully we end up with this bug fixed and no free root loop requirement. 👍
For NI:
This free root loop dependency is simply programmer's hell. There's really no way to win. Strict type: can't open, no strict type: run method hangs. This should be easy...
Once this new Open VI Reference functionality works, please have a look at fixing this for the Open VI Reference by name\path.
wiebe@CARYA wrote:
Ah, I see, so that's the bug they are going to fix!
The bug mentioned above was fixed with the patch: the strict type reference works at run-time now. So what you are seeing with the root loop is likely an artifact of the strict type reference not being passed properly at run-time before the patch.
