Getting Reference to Application Instance from Launched VI in Tools Menu

[ak_nz]

Hello forum LAVA-ites,

 

I am attempting to write a Tools Menu item to slot into the IDE. The intent of this "Tools" VI is that it determines the application instance that launched it and dynamically run a VI in that application instance so that the launched VI can access VIs in that instance. This is basically a custom Unit Testing tool that looks for particular VIs in the project that houses the application instance.

 

I was attempting to use the App.MenuLaunchApp property in this "Tools" VI so that I could wire up an Open VI Reference node with the right application instance and the name of the VI to run dynamic VI to run. I added an extra indicator on the launched VI to show what application context it is running in.

 

If I have a VI open from a Project and then launch the "Tools" VI from the Tools menu, then the dynamically run VI indicator shows "My Computer" (referring to the project housing the application instance). However - if I launch the "Tools" VI from the Tools Menu while Project Explorer is showing then the dynamic VI launches in the NI.LV.Dialog irrespectively (the indicator on the front panel of this VI shows this).

 

Is this expected behaviour? Is there a way around this so that the dynamic VI gets loaded into the right application instance even if launched from Project Explorer?

 

Thanks in advance.

[hooovahh]

I had something similar happen.  Before today I have never ran a tools menu item from the project window not that I think it is a bad idea.  I have a tool that takes an array of string and makes an enum based on it.  It will make it in the application instance that the VI calling it is in.  When I run it from a VI it works as expected making it part of the project that VI is in.  But similar to your issue when I run it on the project window it makes the enum not putting it in the project instance.  Not sure if this is expected or not just wanted to let you know you aren't crazy.  By the way I see this in 2012 SP1.

[ak_nz]

  On 1/29/2014 at 1:38 PM, hooovahh said:

I had something similar happen.  Before today I have never ran a tools menu item from the project window not that I think it is a bad idea.  I have a tool that takes an array of string and makes an enum based on it.  It will make it in the application instance that the VI calling it is in.  When I run it from a VI it works as expected making it part of the project that VI is in.  But similar to your issue when I run it on the project window it makes the enum not putting it in the project instance.  Not sure if this is expected or not just wanted to let you know you aren't crazy.  By the way I see this in 2012 SP1.

 

Thanks for checking it out (although I might still be a little crazy generally speaking!). I'm on 2012 SP1 as well.

 

I did a little test using a basic VI that grabs the current context and the MenuLaunch context names under a number of conditions:

 

1. Getting Started Window - ThisContext=NI.LV.Dialog, MenuLaunchContext=NI.LV.Editor, MenuLaunchVI=GSW.lvlibp:GettingStartedWindow.vi
   
2. Project Explorer - ThisContext=NI.LV.Dialog, MenuLaunchContext=NI.LV.Dialog, MenuLaunchVI=_ProjectWindow2
   
3. New VI in the Project - ThisContext=NI.LV.Dialog, MenuLaunchContext=My Computer, MenuLaunchVI=Untitled 1
   

Surprisingly there is an actual Launch VI for running from the tools menu in Project Explorer, although I don't know whether the naming is anything specific or could just be random. In any event this doesn't get me the project application context that I was after unfortunately.

Edited January 29, 2014 by ak_nz

[Aristos Queue]

A VI run from the Tools menu always runs in the dialog context. Always. This is intended behavior because the tools VIs are not part of whatever project is currently in memory and should not cross-link with the VIs in the open project. 

[hooovahh]

  On 2/3/2014 at 3:08 PM, Aristos Queue said:

A VI run from the Tools menu always runs in the dialog context. Always. This is intended behavior because the tools VIs are not part of whatever project is currently in memory and should not cross-link with the VIs in the open project. 

The original post can clarify but I think the complaint is that when the VI from the tools menu is ran from the project explorer, the App.MenuLaunchApp doesn't return the application instance that the project is using.

[Darren]

The MenuLaunchApp property only works the way you desire when the menu launch VI is launched from the menu of a VI. If you want to gain access to the project from which the menu launch VI was run, you'll need to use the Active Project property:

 

 

From here, you can parse the project and get the Application Instance (which will be different per target in the project) you want.

 

[ak_nz]

  On 2/3/2014 at 3:30 PM, hooovahh said:

The original post can clarify but I think the complaint is that when the VI from the tools menu is ran from the project explorer, the App.MenuLaunchApp doesn't return the application instance that the project is using.

 

hoovahh is correct - I would like to ensure that I run a VI in the correct application context (in my case it will always be the singular My Computer) of the active project regardless of whether the menu was opened from Project Explorer or a VI opened from Project Explorer. I had hoped that MenuLaunchApp would provide this but Aristos' explanation proves otherwise.

 

 

  On 2/3/2014 at 3:40 PM, Darren said:

The MenuLaunchApp property only works the way you desire when the menu launch VI is launched from the menu of a VI. If you want to gain access to the project from which the menu launch VI was run, you'll need to use the Active Project property:

 

proj.png

 

From here, you can parse the project and get the Application Instance (which will be different per target in the project) you want.

 

This seems like the best idea. Since I want to the same behaviour regardless of whether the menu is called from project explorer or a VI in that project, this would appear to be the only way to ensure that. I am building a simple custom unit test framework so all my tests will be executed in the IDE in the My Computer app instance; I can hard-code the search for that.

 

Thanks for your help guys.

[awang_synovus]

  On 1/29/2014 at 5:41 PM, ak_nz said:

Thanks for checking it out (although I might still be a little crazy generally speaking!). I'm on 2012 SP1 as well.

 

I did a little test using a basic VI that grabs the current context and the MenuLaunch context names under a number of conditions:

 

• Getting Started Window - ThisContext=NI.LV.Dialog, MenuLaunchContext=NI.LV.Editor, MenuLaunchVI=GSW.lvlibp:GettingStartedWindow.vi
• Project Explorer - ThisContext=NI.LV.Dialog, MenuLaunchContext=NI.LV.Dialog, MenuLaunchVI=_ProjectWindow2
• New VI in the Project - ThisContext=NI.LV.Dialog, MenuLaunchContext=My Computer, MenuLaunchVI=Untitled 1

Surprisingly there is an actual Launch VI for running from the tools menu in Project Explorer, although I don't know whether the naming is anything specific or could just be random. In any event this doesn't get me the project application context that I was after unfortunately.

Thanks for all the shared information. How did you get these information tho? I have seen a property node "app.allcontext", however, I cant find it in LabVIEW 2009 or later ( I dont have LV8.6 installed). In addition, can anyone explain the difference between NI.LV.Dialog and NI.LV.Editor? Thanks in advance.

[hooovahh]

So the app.allcontext property node is a private method.  It is something NI uses, but doesn't fully document, doesn't support, and I'm sure they'd prefer if no one other than NI used it due to it's possible non-completeness.  You see if NI is playing around with some new property nodes that are private, they can change the behavior between LabVIEW versions without needing to update the public, or worry about backwards compatibility.  Because they should be the only ones using it.  But if us pee-ons start using these functions, and then they change how they work between versions, now all the sudden users of LabVIEW complain to NI about how some obscure private method broke their production code.

 

That being said many private methods have useful functions, that appear more or less stable.  Over the years NI has tried opening up more private functions, to be public and to that I thank them.  But I'm not sure this function will be made public any time soon.  With it you can screw around with the inner workings of LabVIEW.

 

But if you are the adventurous type, you can enable these private methods.  Here is a thread where I made a tool for enabling and disabling these methods.

 

https://lavag.org/topic/16612-enabledisable-private-methods/

 

But please be aware that code that uses private methods can be dangerous, can change functionality at any time, is undocumented, and can break things.  You also won't get the support you might want from NI.