App.AllVIs and application instances

[Jim Kring]

How can I access the App.AllVIs property of the user's (main) application instance (and perhaps project application instances) from within the NI.LV.Dialog application instance? We are having issues with OpenG Builder in LabVIEW 8.0 that are affected by the fact that the App.AllVIs property only returns the list of VIs within the application instance of the calling VI.

[kennoncotton]

How can I access the App.AllVIs property of the user's (main) application instance (and perhaps project application instances) from within the NI.LV.Dialog application instance? We are having issues with OpenG Builder in LabVIEW 8.0 that are affected by the fact that the App.AllVIs property only returns the list of VIs within the application instance of the calling VI.

The new application instances have thrown a wrench into some of our toolkits as well (that is why the Internet Toolkit and Express VI development toolkit have patches that will be on the web this week). Application instances are a great thing, they are the magic behind the targets in LabVIEW 8.0 and are sort of a super namespacing so we can avoid name conflicts, not have our VIs that are running in the background show up in your VI Hierarchy Window, etc. The new Application Builder creates a temporary application instance to load the VIs you are building into during the build process, that way you don't have to close the VIs you are building any more.

So what are these application instances? Well page 39 of the LabVIEW Upgrade Notes does a good job of introducing them. Basically there is a Main Application instance which is the default area for VIs that aren't in a project. Also there is an application instance for each target in a project, so you can have an area for the VIs on your desktop machine and an area for VIs on each target (specific RT device, PDA, etc). These areas can have different application level settings and you can have 2 VIs of the same name or even same path in 'memory' one in each application instance. There are also several private application instances one where VIs related to the project run, another for VIs in the Tools Menu, etc. They are a little different from the namespacing you get with project libraries because the application level settings (Tools>Options, Right-click on a target and Properties) can be different in each application instance, such as VI Server settings. And you can have a Project Library open in multiple applicaiton instances.

So specifically for the Tools menu, the items launched from it are launched in the NI.LV.Dialog application instance, which is where we run LabVIEW based dialogs. So if you have a utility such as Web Publishing Tool that needs to be able to access all VIs in memory or like the Express VI Development Toolkit's UI that needs to open VIs in the user's current application instance, what can you do. Since we had this hurdle to overcome, we created a couple of VIs that are in vi.lib that we use in our VIs in the tools menu and you can use as well. They are mentioned on page 11 of the LabVIEW Upgrade Notes.

<vi.lib>\Utility\allVIsInMemory.llb\VIMemory Get VIs in Memory.vi will return an array of clusters containing strings with the Project, Target and VI Name, plus the Application Reference for all VIs in memory. (Yes it says ComputingNode but imagine it says Target). You can optionally only return the VIs that have their front panels open. With the Application Reference and VI Name you can open a VI reference to the VI you need, even though it is in another context.

<vi.lib>\Utility\allVIsInMemory.llb\Get User Application Reference.vi will return the current My Computer application reference the user is using. So it will return the Main Application Instance if they aren't in a project or the Application Reference for the My Computer node if they are in a project. Note it won't return the Application reference for a target, since this VI was designed with Utilities in mind we didn't think that we would want target application instances.

As you mentioned in your referenced post you can either modify the Open G Builder to look in the other application instances or you could modify it to have a launcher VI that opens it in the user's application instance. I think the former might be what you want long term, but the latter will get it working quicker.

So what if that isn't enough for what you need? There are some VI Server properties that allow you to get to this information, like Projects.Projects[] to Project.App. From Project.Targets[] you should be able to get to the application reference, however I didn't find a public way to convert it or get a reference to the Main Application Instance. I thought we had more public than what I'm seeing right now, but it has been a while since I turned off private stuff. I'll check into it and see why those items aren't available.

Kennon

PS why can't I choose LV 8.0 as my current version in my profile? I've been wanting to set it that way for a while

[Jim Kring]

Kennon, thanks for this post. This is just what we need. Also, I have a quick question: How can we create a new application instance, similar to what the Application Builder now does?

[kennoncotton]

Kennon, thanks for this post. This is just what we need. Also, I have a quick question: How can we create a new application instance, similar to what the Application Builder now does?

Well, I figured that I would get that question since I mentioned that App Builder does it. Basically like everything 'fun' in LabVIEW it is done through a private VI Server method. However since the My Computer node of each project has its own application instance you can create a new project, get a reference to My Computer and then add files. With the private method you wouldn't have to create a project but the net result is basically the same.

[Wolfram]

Kennon, thanks for this post. This is just what we need. Also, I have a quick question: How can we create a new application instance, similar to what the Application Builder now does?

I suppose there is some private primitive called "New Application Reference" same like the existing "New VI" primitive.

[david hoadley]

The new application instances have thrown a wrench into some of our toolkits as well (that is why the Internet Toolkit and Express VI development toolkit have patches that will be on the web this week). Application instances are a great thing, they are the magic behind the targets in LabVIEW 8.0 and are sort of a super namespacing so we can avoid name conflicts, not have our VIs that are running in the background show up in your VI Hierarchy Window, etc. The new Application Builder creates a temporary application instance to load the VIs you are building into during the build process, that way you don't have to close the VIs you are building any more.

...

Kennon,

I saw your post from October about the app reference context of VIs launched from the Tools menu in LV8. I have a follow-on question if you have a moment. I have written code that implements your suggestion and I can get a reference now to a VI from my 'Tool' code. My current strategy is to search the output of vi.lib\Utility\allVIsInMemory.llb\VIMemory Get All VIs in Memory.vi for the one with the matching name. Then I get the desired application reference, I can scope to the right memory space, and everything is just fine. The issue I can imagine is this, though: if there are two VIs with the same name in memory, I really can't tell where the Tools menu selection event came from with my current scheme (project or target). I really want to know which VI's menu bar was selected and operate on that VI only. Do you have any recommendation for that case? I imagine some of NI's tools must have the same issue, and I am hoping that there's enough of the API exposed to resolve my problem.

Thanks,

Dave Hoadley

V I Engineering, Inc.

[kennoncotton]

Kennon,

I really want to know which VI's menu bar was selected and operate on that VI only. Do you have any recommendation for that case? I imagine some of NI's tools must have the same issue, and I am hoping that there's enough of the API exposed to resolve my problem.

Dave,

Yes that is an issue with our tools as well, even prior to the application instances in LabVIEW 8.0 and we have a way to deal with it. As far as that part of the API being "exposed", it is actually a private property so it isn't exposed but there is information on it outside of NI. So rather than spelling it all out, I'll get you pointed in the right direction, take a look at this thread:

http://forums.lavag.org/index.php?showtopi...pp.menulaunchvi

Kennon

[david hoadley]

Dave,

Yes that is an issue with our tools as well, even prior to the application instances in LabVIEW 8.0 and we have a way to deal with it. As far as that part of the API being "exposed", it is actually a private property so it isn't exposed but there is information on it outside of NI. So rather than spelling it all out, I'll get you pointed in the right direction, take a look at this thread:

http://forums.lavag.org/index.php?showtopi...pp.menulaunchvi

Kennon

Thanks, Kennon. Between your reference link and another private property that returns the application reference of the menu launch VI (must be new for 8.0), my problem is solved.

Dave.

[Norm Kirchner]

What kind of limitations are there when working between different application instances.

This is a directed question.

The behavior that I am seeing screams of thread locking, but better stated context locking.

I am dynamically executing code in another context that is loaded in that same context.

But what is happening is that the dynamically called code will not exit. It just sits there, locking the vi that is called in the original context (NI.LV.Express)

The details are numerous, BUT the question is simple.

Do the different contexts interact in a way that one context can stop another context from execution?

[kennoncotton]

The details are numerous, BUT the question is simple.

Do the different contexts interact in a way that one context can stop another context from execution?

Norman,

The quick answer is no, application instances can be thought of as 2 separate LabVIEW executables running on the same machine and what goes on in one should not stop execution in another. Notice I said the word should. There has been a report or two of getting into a similar situation.

I think what is going on is you have a VI that is running in one application instance (NI.LV.Express) and when that VI is opened in another application instance (lets say Main Application Instance) it needs to be compiled/edited for some reason. LabVIEW recognizes the need to recompile and wants to propagate those changes to the other application instances. However the VI is running (or reserved for running) in the first application instance and therefore can't be edited in the second application instance. LabVIEW is waiting for the VI in the first application instance to stop running, before it runs the VI in the second application instance. Does this sound like what you are seeing?

I wasn't 100% sure about this, so I spoke to one of the architects who worked on the application instance. He agreed with the assessment. So I guess to workaround you'd either have to figure out why LabVIEW is trying to edit or recompile the VI or have 2 copies of the code or maybe call it dynamically from your express VI so it isn't running when you open it in the other application instance?

There is already a bug report about a similar scenario, so rather than filing another one, I've added a link to this thread. And since I've some interest in knowing which CAR number goes with a problem, the CAR number is 3U1EGOF2.

Kennon

[Norm Kirchner]

For a little more detail on the.... details.

The call is into an EXE.

Using VI server to open an app ref to the exe

Then open a ref to a VI loaded into memory, but not running in the EXE

Call by ref node to that VI in the EXE and wait for it to return.

Don't get hung up on the fact that it's an exe, because the same behavior happens if it's a running VI also.

But not consistently in either case.

Isolation of the problem is underway, and it's difficult to know if it's trying to re-compile or not but we'll look towards that as a focus point.

SIDE NOTE: Thanks to all the NI interaction on LAVA & other forums for those of us staying out of the NI Dev Forum for whatever reason. It's great to have the horses mouth feeding from a few troughs.

[kennoncotton]

But not consistently in either case.

Isolation of the problem is underway, and it's difficult to know if it's trying to re-compile or not but we'll look towards that as a focus point.

Hmm, well, when you open the VI reference you might want to see if the property "Modifications:VI Modifications Bitset" is not 0, if that is the case then the VI has been modified and if it has relinked to subVIs, I think. If you can narrow down a set of code that can reproduce it let me know and I'll append it to the CAR.

SIDE NOTE: Thanks to all the NI interaction on LAVA & other forums for those of us staying out of the NI Dev Forum for whatever reason. It's great to have the horses mouth feeding from a few troughs.

We enjoy keeping up what ya'll are up to with the features we work on. Not everyone in LabVIEW R&D posts or some of us don't post much but there are always good things to read on LAVA and info-LabVIEW.

[Jeff B]

Hello Norman,

As a result of your report, we've identified an issue that can occur when calling remote VIs dynamically (and in particular, when using the call by reference node) when the call by reference node resides on the diagram of an Express VI's configuration page. This actually doesn't have as much to do with the application instance the configuration page VI is running in as it does the specific mechanisms used inside LabVIEW to launch the configuration page when the Express VI is double-clicked or right-click properties is selected.

Please let me know if this seems to summarize your situation, or if you have seen these "hangs" in other situations as well.

One possible workaround might be using the Run VI method instead of the call by reference node, but this can get quite cumbersome in a hurry, and requires the dynamic callee to be idle. Call By Reference Nodes can call VIs that are reserved for execution whereas the Run VI method cannot.

[Norm Kirchner]

As a result of your report, we've identified an issue that can occur when calling remote VIs dynamically (and in particular, when using the call by reference node) when the call by reference node resides on the diagram of an Express VI's configuration page.

Please let me know if this seems to summarize your situation, or if you have seen these "hangs" in other situations as well.

To be brief, Yes this summarizes the issue.

More specifically, it generalizes the problem even further beyond what the dynamic call, calls into (my case exe), (your case anything )

using the Run VI method instead of the call by reference node, but this can get quite cumbersome in a hurry

Definetly not an option.

Now a the note on the details: I think that this forum(maybe another thread) is a reasonable place to discuss the mechanics of why. It would increase the understanding of the community as a whole to another part of the LV guts and therefore allow the community Gurus to assist in helping others and give us the chance to make "furture proof" creative/sneaky code.