Accessing VIs across contexts

[Antoine Chalons]

Hi,

I'm trying to make small utility VI that can set front panel properties of other VIs in memory. No special issue with that.

I then wanted to put this utility VI in my Tool menu and here it begins to be a little trickier..

I found out that when the my utility VI is launched from the menu it doesn't execute in the LV context called "Main Application Instance" but in the LV context called "NI.LV.Dialog".

So I thought "ok.. let's modify my utility VI so that it gets the VIs opened in the "Main Application Instance" context", the thing is I can't find the way to do that

Anyone can help ?

EDIT :

Just found a solution with a coworker (thanks Falko).

[LAVA 1.0 Content]

Hi Antoine,

there is a special method for retrieving the application instance of the VI that invoked the utility VI:

Ton

[Antoine Chalons]

QUOTE (Ton @ Jan 22 2009, 02:03 PM)

Hi Antoine,

there is a http://forums.lavag.org/AppMenuLaunchVI-t4163.html&p=16921#' target="_blank">special method for retrieving the application instance of the VI that invoked the utility VI:

Ton

Hmmm... looks like I re-invented the wheel

Thanks for the hint

I learnt a bunch of thing I was ignoring doing this utility VI but I feel I still haven't discovered everything..

I used to think that a "project" was a LabVIEW context, but now I see it more as a group of contexts.

The "links & relationships" between the LV app, projects and contexts is still a bit hazy for me, I'd have to dig into that when I get a moment.

..But if anyone has it clear in his mind I'd appriciate some explanations

[Aristos Queue]

QUOTE (Antoine Châlons @ Jan 22 2009, 07:25 AM)

The "links & relationships" between the LV app, projects and contexts is still a bit hazy for me, I'd have to dig into that when I get a moment.

..But if anyone has it clear in his mind I'd appriciate some explanations

a) The term "application instance" is used in all public documentation, but in the LV C++ code, those same things are called "contexts". Because R&D folks occasionally post to customers without tech writers reading over our shoulders, we slip up and use the other term. So you should generally regard those terms as interchangeable, but know that "application instance" is preferred for a long list of (very good) reasons.

b) An app instance is very nearly an isolated LabVIEW.exe. The VIs in one app instance cannot interact with the VIs in another context unless they do the same things that would be required to talk to a VI that was loaded on a separate machine entirely. So whatever you would do to talk to a network VI is the stuff you generally have to do to talk to a VI in another app instance.

c) Application Refnums are the references to an app instance. Prior to 8.0, you would open an app reference to an entire LabVIEW execution system. Now you open an app reference to one app instance within the execution system.

d) All LabVIEW files -- VIs, libraries, projects -- load into an app instance. The same file may be loaded into multiple app instances simultaneously. Editing one of the "reflections" (a term that R&D uses which is distinct from "clones" of a VI, which has to do with reentrancy) does not change the other reflections of that file until you synchronize the app instances (either by pressing that green arrow button that appears on the VI next to the Run arrow OR by saving the file).

e) Projects are loaded into an app instance, but they also manage a set of app instances. The "My Computer" instance is the one that the project is actually loaded into. If you add any targets to a project -- an FPGA target, RT target, etc -- those are other app instances. *All* of the app instances that a project creates, including the "My Computer" instance, are life-time managed by the project, meaning that when you close the project, you close the app instance, which closes out all the VIs and Libraries loaded into those app instances.

f) Any given app instance may be owned by zero or one projects, but not more.

g) LabVIEW has multiple private app instances, including the "NI.LV.Dialog" app instance which is where VIs from the Tools menu run. These private contexts allow tools written with VIs to run without interfering with the user app instances, so there is never a chance of one of those VIs cross linking with user VIs or keeping a user VI from being able to load because a VI of that name is already in memory. Various parts of LV will create temporary app instances -- for example, AppBuilder creates a temporary app instance which it loads all the source VIs into so that it can rename them, strip diagrams, etc, without touching the user's original source files.

h) Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LV where my knowledge is pretty weak and others may be able to fill in more details.

[LAVA 1.0 Content]

Stephen, where is that kudos button :thumbup:

QUOTE (Aristos Queue @ Jan 22 2009, 07:51 PM)

h) Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LV where my knowledge is pretty weak and others may be able to fill in more details.

Yes we can!

However we can't really control them well.

If you open up a private context there should be a way of closing that context well.

However I have succeeded in removing the context from memory by first calling the Context.RefCount.Dec method

http://lavag.org/old_files/monthly_01_2009/post-2399-1232651093.png' target="_blank">

However when you open up LabVIEW the next time you will get an error:

QUOTE

The last time you ran LabVIEW, an internal error or crash occured at LVContext.cpp, line 1887.

QUOTE

and others may be able to fill in more details

I assume you know better who these so called others are, please bring them.

Ton

[Aristos Queue]

QUOTE (Ton @ Jan 22 2009, 01:07 PM)

Yes we can!

However we can't really control them well.

If you open up a private context there should be a way of closing that context well.

Calling the "Close Reference" primitive ought to do it. I take it from your post that that doesn't close the context?

[LATER] I have asked Those Who Know and they say this: "If you create a temporary app instance and then you open a VI reference to a VI in that app instance and then you close the app reference, the still-open VI reference will keep the app reference in memory." In other words, you have to close all the VI references and all the app references in order to make an app instance shut down.

[Antoine Chalons]

Thanks alot Stephen for all this informations ! :worship:

Maybe this should be wikied, no ?

[crelf]

QUOTE (Antoine Châlons @ Jan 23 2009, 01:43 AM)

Maybe this should be wikied, no ?

Absolutely - go fot it!

[Antoine Chalons]

QUOTE (crelf @ Jan 23 2009, 03:26 PM)

Absolutely - go fot it!

I've tried but without success I then saw that Michael managed to publish what I failed to publish.

If someone can tell me why the page : http://wiki.lavag.org/Category:Application_Instances does not exists (this is the one i tried to create) and why it is instead this :

[url="http://wiki.lavag.org/index.php?title=Http://wiki.lavag.org/Category:Application_Instances"]http://wiki.lavag.org/index.php?title=Http...ation_Instances[/url]

From reading to Wiki help it looks quite doable to publish a nice article but I just can get it correctly

[LAVA 1.0 Content]

You started a so called 'Category' page. This special page is like an index to all pages that contain the [[Category:xxxx]] tag.

Your page is located at Application_instance, I added the page to the Category:Application_Control.

Ton

[Antoine Chalons]

QUOTE (Ton @ Feb 3 2009, 11:46 AM)

You started a so called 'Category' page. This special page is like an index to all pages that contain the [[Category:xxxx]] tag.

Your page is located at Application_instance, I added the page to the Category:Application_Control.

Ton

Ok, thanks for the help, it *slowly* starts to make sense in my brain..

by the way, be careful with upper/lower case, Category:Application_Control does not exist yet, Category:Application_control does

[LV User]

Hi Antoine,

there is a special method for retrieving the application instance of the VI that invoked the utility VI:

Ton<p>

I am not able to see the special method....Link is broken

[Antoine Chalons]

I am not able to see the special method....Link is broken

Hi raj, indeed the image was lost during the LAVA upgrade. Here is the method :

[Antoine Chalons]

oops.. sorry, wrong image :S

this one is better

[NATE]

I found this snippet of code in DEAB Open LV80 Project App Reference.vi because it is currently throwing an unhandled exception for me, I'm hoping you can help me out. I'm attempting to use OpenG Builder 3.0 with LabVIEW 2009 SP1 on WinXP. It works fine if I perform the build through the Builder GUI, but when I try to automate the build using Build Application from Build File__ogb.vi, this exception pops up. The subVI calling this VI is a member of an .lvlib containing all of the code to perform the total automated build. This .lvlib was itself auto-created by a Source Distribution build spec. This same automated build process worked fine with OpenG Builder 2.0 and LV 8.6.1. We just updated to LV2009 this week.

I'm tempted to use VI Scripting to have my build tools auto-comment this snippet of code out to prevent the error. I have to do it this way instead of just modifying OpenG builder because our build tools have to be CM'd so the builds can be performed by our SQA. But that feels like a real hack.

The built application otherwise comes out fine, it just pauses my build tool in the middle, which is a booger because there's a lot more my build tool has to do after the EXE has been created.

Thanks for your help!

Nate

[Ton Plomp]

I found this snippet of code in DEAB Open LV80 Project App Reference.vi because it is currently throwing an unhandled exception for me, I'm hoping you can help me out. I'm attempting to use OpenG Builder 3.0 with LabVIEW 2009 SP1 on WinXP. It works fine if I perform the build through the Builder GUI, but when I try to automate the build using Build Application from Build File__ogb.vi, this exception pops up. The subVI calling this VI is a member of an .lvlib containing all of the code to perform the total automated build. This .lvlib was itself auto-created by a Source Distribution build spec. This same automated build process worked fine with OpenG Builder 2.0 and LV 8.6.1. We just updated to LV2009 this week.

Hi Nate,

Could you post the snippet that you mention?

Ton

[NATE]

Hi Nate,

Could you post the snippet that you mention?

Ton

I'm sorry, it's the above image of the while loop with the Context.Ref Count.Dec method in it. The invoke node is throwing a LVContext.cpp error.