Avoiding the NI.LV.Dialog application instance

[Thoric]

I'm creating a utlity VI to launch from the Tools menu. When a VI is launched from here it is thrown into the unique NI.LV.Dialog application context. From here, things get tricky, because we can't immediately see the VI from which the menu item was called.

If you call:

then you get an application instance and a VI name to use in Open VI reference. But that doesn't seem to solve an issue I'm having.

 

In my calling VI (from where Tools > MyUtilityVI was selected) I have front panel control with User Tag information in them. I can get a reference to this VI and use Read User Tag.vi to get to the string data I've embedded in the controls. The string data is actually a LV class flattened to XML. This is where I get a bit confused - in the utility VI I can read the XML string and place an unflatten from XML string function to typecast it back to a LV class. When I debug and run the utility VI in the dev environment (Project application instance) it works fine. But when called from the menu, and in NI.LV.Dialog app instance, I get error 1527 "Attempted to read flattened data of a LabVIEW class that is not currently loaded into LabVIEW"

 

This is presumably because some derivative/child of the class is not in memory in the NI.LV.Dialog app instance. So how do I make sure that the entire class hierarchy is available to this application instance? Into the Unflatten XML String function I'm passing an instance of the class parent, but presumable a child or two is missing. Unfortunately the class has dozens of children, and I'm not keen on placing them all into the block diagram to ensure they're accessible to this application instance!

 

Here I read about accessing VIs across contexts, but I don't see a solution. This opens a reference to the VI in the original instance, but the utility VI is still in NI.LV.Dialog instance so cannot access the class hierarchy.

 

Here is a chap attempting to dynamically launch a VI into the application instance of the calling VI, but it fails. According to Stephen this is not possible, LabVIEW prevents it to keep everything in the NI.LV.Dialog context.

 

Ultimately, my LabVIEW Project will become a tool installed into user.lib, with the utility VI in the Tools menu (project folder). It needs access to the VIs that define the toolkit, which currently are in the active Project (because I'm still developing the tool), but ultimately will be found in the user.lib folder. Will it start working once I migrate all the VIs like this?

 

[Darren]

This is the approach that I've seen taken for this issue...you have to do all the work you would normally do in the NI.LV.Dialog app instance in the app instance that owns the VI from which you launched the Tools utility:

 

 

 

[Thoric]

Darren,

Thank you. I have been trying to dynamically launch something into the correct application context to ensure access to the full class (and library) hierarchies, to no avail. This appears to have worked, so I'm very grateful!

 

If you're at the European CLA Summit in Rome this year you will be able to see the fruits of this effort in my presentation (hopefully!).

[ThomasGutzler]

This is the approach that I've seen taken for this issue...you have to do all the work you would normally do in the NI.LV.Dialog app instance in the app instance that owns the VI from which you launched the Tools utility:

 

I've been trying to solve the same problem. I got it to work, but slightly differently, so I tried out your solution. It works, unless you're trying to start the vi from the project explorer.

 

This is what I came up with. It's a vi, that runs when opened and re-launches itself if it finds itself in the "wrong" instance. (That might be a bit dodgy but it works for me and it was easier than writing a launcher for every tool I want to run in this way.)

Once running happily it can search through the paths of all vis on the block diagram.

Find VIs on BD by path.vi

 

- If I'm opening it from a Block Diagram or a Front Panel window, it should act on *this* vi (works for BD but not FP)

- If I'm opening it from a project explorer it could act on the selected vi (not attempted)

- If I'm opening it from the LV launcher the user needs to select a vi with the browse dialog (works)

I'm still unsure which application instance I should be using for the different cases - there are just so many to chose from.