Jump to content
ak_nz

Getting Reference to Application Instance from Launched VI in Tools Menu

Recommended Posts

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by ak_nz

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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:

 

post-4441-0-53480500-1391442003.png

 

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

 

Share this post


Link to post
Share on other sites
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.

 

 

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:

 

attachicon.gifproj.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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By Francois Normandin
      View File UI Tools
      UI Tools v1.4.0
      Copyright © 2009-2016, François Normandin
      All rights reserved.
      Author:François Normandin
      Contact Info: Contact via PM on www.lavag.org
      LabVIEW Versions:
      Created and tested with LabVIEW 2012
      Dependencies:
      OpenG Application Control Library >= 4.1.0.7
      OpenG Array Library >= 4.1.1.14
      OpenG File Library >= 4.0.1.22
      OpenG LabVIEW Data Library >= 4.2.0.21
      OpenG String Library >= 4.1.0.12
      LAVA Palette >= 1.0.0.1
      Description:
      This package contains tools for designing user interfaces.
      A first palette helps create special effects using transparency of front panel. Using them allows to quickly create fade-ins or outs using linear or exponential variation of the intensity. A second palette contains VIs to calculate the position of GObjects for many purposes like alignment, snap, mouse follow, etc. A third palette contains VIs to create dialog boxes based on class instances. "Simple Error Dialog" and "Simple Selection List" are featured with or without backrground blackening effect. A fourth palette includes some VIs to move objects programmatically on the front panel, using a basic deceleration algorithm to provide an impression of a smooth movement. The packaged VIs are all namespaced using a suffix “__lava_lib_ui_tools” which should not conflict with any of your own code.
      Includes:
      Front Panel Transparency (Fade In & Fade Out) Utilities (Alignment, Snap) Dialog (OOP based, extensible) Engine (Beta) for object movement Instructions:
      This package is distributed on the LabVIEW Tools Network (version 1.3) and updates are on LAVA (1.4). It can be installed directly in the addon folder of any LabVIEW version from 2012 to now. The addon installs automatically under the LAVA palette of the addon submenu.
      License:
      Distributed under the BSD license.
      Support:
      If you have any problems with this code or want to suggest features, please go to www.lavag.org and navigate to the discussion page.
       
      Submitter Francois Normandin Submitted 09/21/2009 Category LabVIEW Tools Network Certified LabVIEW Version  
    • By Francois Normandin
      UI Tools v1.4.0
      Copyright © 2009-2016, François Normandin
      All rights reserved.
      Author:François Normandin
      Contact Info: Contact via PM on www.lavag.org
      LabVIEW Versions:
      Created and tested with LabVIEW 2012
      Dependencies:
      OpenG Application Control Library >= 4.1.0.7
      OpenG Array Library >= 4.1.1.14
      OpenG File Library >= 4.0.1.22
      OpenG LabVIEW Data Library >= 4.2.0.21
      OpenG String Library >= 4.1.0.12
      LAVA Palette >= 1.0.0.1
      Description:
      This package contains tools for designing user interfaces.
      A first palette helps create special effects using transparency of front panel. Using them allows to quickly create fade-ins or outs using linear or exponential variation of the intensity. A second palette contains VIs to calculate the position of GObjects for many purposes like alignment, snap, mouse follow, etc. A third palette contains VIs to create dialog boxes based on class instances. "Simple Error Dialog" and "Simple Selection List" are featured with or without backrground blackening effect. A fourth palette includes some VIs to move objects programmatically on the front panel, using a basic deceleration algorithm to provide an impression of a smooth movement. The packaged VIs are all namespaced using a suffix “__lava_lib_ui_tools” which should not conflict with any of your own code.
      Includes:
      Front Panel Transparency (Fade In & Fade Out) Utilities (Alignment, Snap) Dialog (OOP based, extensible) Engine (Beta) for object movement Instructions:
      This package is distributed on the LabVIEW Tools Network (version 1.3) and updates are on LAVA (1.4). It can be installed directly in the addon folder of any LabVIEW version from 2012 to now. The addon installs automatically under the LAVA palette of the addon submenu.
      License:
      Distributed under the BSD license.
      Support:
      If you have any problems with this code or want to suggest features, please go to www.lavag.org and navigate to the discussion page.
       
    • By chrisempson
      Hi, I'm writing a LabVIEW application using the Actor Framework. This is the first time that I have used the framework and I need some advice regarding application architecture. My apologies if this is a basic question!

       

      How is a settings dialog box best implemented? In the past in non-Actor Framework applications I have loaded the configuration from a functional global variable, displayed the settings dialog, then written the updated settings back to the functional global. I'm not sure this would work correctly (or optimally) within the context of the Actor Framework, though. 

       

      My application uses the template generated by Create Project -> Actor Framework. The top-level Actor manages the user interface. Two child Actors control separate pieces of hardware. The top-level actor must read a saved configuration from an INI file when the application starts, and save the final configuration back to the INI file on exit.

       

      Instinctively I think it would be best for each child actor to maintain its own settings, as a cluster in its class private data. Ideally I don't want to have to keep a separate instance of the two clusters of settings in the top-level Actor's private data in order to populate a settings dialog; this duplication seems unnecessary.

       

      The only way I can think of to make this work is as follows.

       

      At application start

      1. Top-level Actor reads settings from INI file.

      2. Send messages to both child actors with the new settings, and tell them to apply those settings to their private data.

      3. Each child Actor should respond to acknowledge that the private data has been updated.

       

      To update the settings using a dialog box

      1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor.

      2. Wait for both child Actors to reply.

      3. Display the dialog box.

      4. If the user clicked 'Ok' and not 'Cancel', send messages to both actors with the new settings, and tell them to apply those settings to their private data.

      5. Each child Actor should respond to acknowledge that the private data has been updated.

       

      On exit

      1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor.

      2. Wait for both child Actors to reply.

      3. The top-level Actor writes the settings to the INI file.

       

      This doesn't seem like a sensible approach, though. Waiting for message replies sounds like the wrong thing to do. I wouldn't know where in the block diagram to implement this scheme, either.

       

      Can anyone offer me any advice? There must be a fairly standard way of doing this that I'm missing!

       

      Thanks in advance,

      Chris

       

      ---

      Dr. Chris Empson

      Robot Screening and Instrumentation Specialist

      School of Chemistry

      University of Leeds

      UK

       

      CLD

    • By Manudelavega
      Hi,
       
      I am facing a weird situation and would like to get your insights. My application is quite large (>1000 VIs). When I run it, an initialization phase takes place, and around 10 or 20 objects are created (LVOOP). Most of these objects start their engine using the Open VI Reference and then the Run method. If they encounter any warning during that phase, they enqueue a message to display, and a dedicated VI keeps checking this queue and opens a LV Dialog (with just a OK button) when it finds an element. The purpose is to allow the initialization phase to continue instead of waiting for the user to acknowledge the window. Then when the init phase is complete, the user can just acknowledge all the dialogs one after another. (usually there is like 1 or 2, not much more).
       
      I ran my code this morning and was surprised to see that the init phase would still wait for me to acknowledge the dialog. A few probes showed me that the application was stuck in one of the Open VI Reference call. After I acknowledge the window, it would process normally.
       
      I am wondering what is causing this behavior and whether it is a known issue. Could it be related to the fact that the Dialog is modal and somehow holds the thread in which the Open VI Reference executes? This is weird, because other complex operations (connecting to a database,...) manage to execute while the dialog is open...
       
      Thank you very much for your help
       
      Emmanuel
    • By zack13532
      Hi all, I'm somewhat new to Labview so excuse any ineptitude that may arise. I have a program that is centered around an array of Devices - they are various different object types that descend from an abstract Device class. I'm trying to make a VI that can call the correct method VI for a given device in this main list (in an object oriented way, of course). So far this has been fine for most VIs, but now I'm trying to make an overridden VI in each class that opens when called, like a dialog box. As of right now, calling the "Display Info.vi" (the VI in question) on a given device opens the Display Info VI from the Device class, which is basically just a blank, unimplemented VI and therefore useless. Are there some settings I need to check to enforce polymorphic behavior on this VI? Thank you for any info you can provide!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.