The function operates differently if you wire a string to the input versus a path - even if the path is just the name of the VI, the open VI reference function still tries to find the VI on disk, versus loading it from memory. Give it a try - if you just wire the name - (as a string) you will see that the function doesn't work.
I think you are correct in that when you run an .exe everything is 'opened', but that doesn't mean its 'in memory'.
Isn't that the purpose of inlining a VI so that it is loaded into memory with the calling VI to reduce the overhead of opening the VI from the EXE when needed? In my mind, that means that the VI exists in a virtual disk structure within the EXE but is not necessary in "memory", even though the EXE itself is in memory, as Dave points out by removing the thumb drive from the PC.
Well, yes, that is interesting! I switched to a string constant, and the VI fails, both in LV and as a .exe. Yes, it works differently with a string than with a path. But that isn't relevant to my conclusion.
Leaving it as a path, but with only the VI name in the path constant, The .exe works. It beeps. Even when the thumb drive with the .exe on it is removed from the computer. AND when the original VI in my development directory has been both moved and renamed. Not that the exe would be able to find it anyway, since it doesn't have even the original path, but it just isn't even there anymore.
I still need to work further to understand the path vs string issue. But it looks to me like that is a different issue.
I don't have much experience with inlining VI's, but perhaps the issue there is that inlining is intended for optimizing when the VI is loaded from disk when used inside the LabVIEW environment. When inlining is then compiled into an .exe, maybe NI designed it so that it still "works", even though the sub-VI is (according to my tests, here, not necessary gospel truth) is already loaded into memory and does not need to be read off of disk.
I understand what youre saying, but I dont think they're separate issues. We really need someone from NI (or someone who really understands how built exes work) to correctly explain, but here is how I am thinking of it - and this could be completely wrong. When you run the exe, all the support files for the exe are opened - a virtual folder directory is opened up if you will. Within that virtual folder directory, the application runs. There is a memory space for the application code that is actually running - this is not the same as the virtual folder directory that was opened, which includes all support files - in our case the beep vi. You taking the USB drive out confirms that the entire folder/file directory is opened up when you run the exe, but changing the input to a string indicates that the folder directory isn't in the application memory. If you add a 'Path' property node to your code after opening the reference, you will see that the path is \..Load Test with Beep1.exe\beep1.vi - the VI path is inside the exe.
If you add another Open VI reference to that code, and use the string name method AFTER you have already opened the VI reference with the path you will see that it works - because the VI is now in the application memory.
I agree with just about all your points. Especially that it would be good to get NI to chime in on this!
If I understand your description correctly, I think you are proposing basically the same model as I tried to propose earlier. When the exe is run, everything in the exe is moved from disk to ram. But it is in a different part of ram than the "fully loaded" LabVIEW code. Then when LV calls the dynamic VI, it "loads" this into the LabVIEW memory space. But at this point, it is loading it from ram, not from disk.
This is similar to aputnum's discussion of inlining a VI. In both the inlining case and the dynamic call case, things work in the LV environment as described in the help and as we were taught, and it's all about when to load from disk. But when you build an .exe, things are different, in ways that aren't all that obvious. They are intended to "work" the same, e.g. provide compatibility, but in the background, they are different.
Done. As expected, it doesn't appear. This further confirms that there is a difference between Windows loading it and LabVIEW loading it. Windows appears to load all the "Always Include" dynamic VIs when the .exe is first run. But they are "loaded" into LabVIEW's "active space" (for lack of the proper term) until LV loads them.
I'm not sure I understand your preference in definition. LabVIEW "loads" a VI into memory at some point. My contention is that the RTE "loads" it from RAM into another part of RAM. I think "Instantiate" would be when LabVIEW uses a VI that is already loaded into memory and instantiates another active copy of it. If those are both correct, we're still lacking a term for when Windows "loads" the VI from disk to RAM as part of starting the .exe.
I use the Open VI Reference to "load" the dynamic VI, followed by the Run method.