jakaom

you have to wire the "application reference" input of the "open VI reference" VI with the correct application reference.

That topic was discussed here

cheers,

CB

I tried that just by wiring the output of "Open Application Instance" without anything wired into that function, but this didn't help.

Also, NI replied with this being the issue:

as of LabVIEW 8.20, VIs in an executable can no longer

be programmatically controlled from outside of the executable. In

addition, developers can no longer build LabVIEW executables and use

them as VI libraries. This means that you can no longer rename an

exe to a .llb and gain access to the VI. The reason why this

behavior changed wasn't for this security issue, but for

compatibility with the upcoming Windows Vista.

Meaning that they changed how one can access VI's from inside .exe's.

Are they mixed up? Do I just need to give it a different application reference?

If what they said is true, any opinion on the best way for me to call VI's from an executable on a run-time system? (I deploy to machines that don't have the LabVIEW development system installed). Do I need to place a .llb instead of the .exe on the machine, and call the VI that's inside the .llb with VI server? Or is there a better way to achieve this? The goal is to have a core executable that never has to change that calls VI's dynamically. That way you can deploy new VI's on a run-time system without have to rebuild the entire application.

Thanks!! Jason

In 8.20 I'm seeing an issue with doing what's contained in this link:

http://digital.ni.com/public.nsf/websearch...F5?OpenDocument

It just returns:

Error 7 occurred at Open VI Reference when the VI contained in the .exe is called dynamically.

But the code runs perfectly in 8.0.1

Any ideas?

Thanks!

One technique I've seen in general for using "by reference" semantics is to use a single element LV queue. The basic idea is you create a queue of length one, and everytime you want to use the data, you dequeue it with an infinite timeout (so in case someone else is using the element you wait until it is your turn) and then once you are done with the object, you enqueue it again. Unfortunately, this approach does create a lot of clutter on your diagram everytime you access your object, and if you're dealing with multiple objects, you have to be careful not to deadlock.

When reading thru the release notes, I do not recall seeing mention of GOOP.

I do remember a rather long list of problems.

No I did not download it. Just looked at the release notes and then is wasn gone.

Ben

From what I can tell they've implemented some watered down form of GOOP that doesn't allow you to create multiple objects in the class. Not even clear how they are protecting attributes while they are being modified. On the other hand it looks like they have inheritance. Looks like a useful tool, but different from the GOOP I'm used to.