FraggerFox

From what I think, when you say "inline subVI", labview will add the inlining code to the top level code where it is called, while its compiled. Now, if you have changed the contents of the class later, and have kept the option of keeping compiled code separate of VIs, it shouldn't automatically add the inlining code to the top level of your VI. Did you have the option of separating the compiled code from the main VI enabled when you encountered this problem? -FraggerFox

If I use a Run VI method which is using the LV2G which is already initialized before in another hirearchy, and having a valid reference in its SR (I am not re-initializing the .NET constructor in dynamically called VI, I am just reading the reference out of SR), does that mean that it would still be loaded in a different hirearchy and would have an invalid reference? I think it shouldn't?

I am not re-initializing the VI during dynamic call, but just using the "execute" command case from the LV2G. Logically, it should pick up the same reference from the Shift Register, execute the method, and keep the reference in memory. In my case, as soon as this dynamic VI is executed, the reference becomes invalid, though its hirearchy hasn't been initiated in the dynamically called VI. Any Ideas?

The VI in which the reference is first created is always running, however, I found that a dynamic call to other VI later in the stage, which uses the same LV2G to execute some commands, and which runs only once and stops, causes this issue. Logically, this should not happen, since, as said, "the hierarchy which controls the lifetime of a reference is the hierarchy it was created in."

To add to the above post, my top-level application calling this LV2G is always running.

Hello all, I have a .NET constructor node inside LV2G, and I execute a certain set of functions from external .NET dll. I have three cases: 1) Initialize - Which gives us the .NET reference which could be used with invoke nodes to execute external dll functions, which will execute only once in my app 2) Execute - Takes the reference from above and execute some function 3) Get Reference - Just reads out the .NET reference Now, if I use this LV2G in different VIs, with the Get Reference case, I could see that the reference becomes invalid after a while (It shows Ref is no longer valid on probe, even if I keep executing some functions continuously) Maybe I am missing on some basics here, but has anyone come across such problems in their applications? -FraggerFox!

Ton, How about using the following process, for controlling any third-party executable running on cmd prompt using WinAPIs: 1) Get the third party window handle by using GetWindowHandle API. 2) Use AttachConsole() API from kernel32.dll - This would make the third party console controllable through LabVIEW 3) Use GetConsoleScreenBufferInfo() from kernel32.dll, with which you can read the console information 4) Use another function (can't remember the function name) which would write to the console 5) Repeat Step 3 and read the output for the written command in step 4 (you might need to do some string parsing to get the desired output) 6) Use FreeConsole() function from kernel32 again, to free up the console at the end of the application. This way, you don't need to redevelop the third party app in labview, rather you could re-use the cmd prompt with this method with labview and have control/read data on it. I am planning to make a small example of this and post it very soon. -FraggerFox!