david hoadley

A solution to this would be the option to enable or disable creating seperate execution targets for each opened project or being able to add a project to a project. I have not found either of these options. Has anybody else come across this, and if so how did you get around it?

Thanks in advance for any and all help provided.

Hey Todd,

The more 'computer science-y' answer is to store a reference to each application instance in your object pointer cluster such that each object's methods know the context in which they are supposed to be running: namely, the application instance that created that object. I just learned a similar lesson, and I actually think I like LV better this way. I think the tools vendors (VIE included) have some catching up to do to thoroughly support 8.0, though.

Just a thought - if you had a 'readme' diagram in a central application reference (project) and instantiated all of your objects from said project, then you might be OK. a) all VIs would be in memory on the 'main' project and b) creating all objects in the main project would put them in the proper memory context. Hmm, no, I think that's not good enough. I presume you have methods of project A called in project B and vice-versa. If those method calls were now made by reference with the main project app reference used, then this method seems sound. Now THAT's a pain - use Call By Reference everywhere instead of VIs on the block diagram. OK, maybe I don't like it better this way. It's really analogous to proxying method calls for GOOP objects between PCs on a network.

The way I think NI envisioned us using a project was to organize the information for an app on a 1-1 basis. Anything different and your mileage may vary.

Dave.

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.

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.