open vi reference by string in executable

[Thoric]

Hi all,

Scenario: A top-most vi (main.vi) calls two subvis (subvi1.vi and subvi2.vi) separately such that they run in parallel. subvi1.vi has a front panel that appears when called, subvi2.vi does not.

subvi2.vi uses Open vi Reference to get a reference to subvi1.vi. It then uses this reference in a loop and continually polls the property FrontPanel.IsFrontmost to determine if the front panel of subvi1.vi is frontmost. When it is frontmost, it performs certain actions. When it isn't frontmost - it doesn't.

This all works great in the development environment, but as soon as I build this 'scenario' into an application I get the following error:

 

subvi2.vi is generating the reference to subvi1.vi using the string "subvi1.vi" as an input to the path terminal of the Open vi Reference function. Why does this cause problems in a built executable?

P.S. Clearly this scenario is actually a part of my much bigger project, hence I don't have any simple vi's to attach 

Message Edited by Thoric on 04-27-2009 01:06 PM

[Ben]

The "string" method of naming a VI only works if the VI is already in memory. I would throw in two indicators to help narron this down. For VI1 (that shows it FP), shows its complete path on the FP when in the exe to figure out if name mangiling is happening. In VI2 add a pop-up that hsows you error coluster after you attempt to open the ref to VI1.

Two other things that could be happening (not sure yet) are if the new VI is opening in the same context as VI1 and VI Server setting to allow opening the ref to vi1.

Just trying to help,

Ben

Message Edited by Ben on 04-27-2009 07:39 AM

[Norbert_B]

Thoric,

it's disturbing that LV is crashing on your system due to this error.  What version of LV do you use?

LV 8.6.1 at least (i don't know which version was the first one) creates the following error:

LabVIEW:  Open VI Reference no longer matches VIs in memory by filename. A filename is no longer sufficient because the full name of a VI now includes any owning libraries.

This error occurs even in the developement system.

I asume that the crash itself is created by handling of invalid references.

hope this helps,

Norbert 

[Thoric]

Hi Ben,

Thanks for suggestions - however I'm having a little trouble implementing them:

---

I would throw in two indicators to help narron this down. For VI1 (that shows it FP), shows its complete path on the FP when in the exe to figure out if name mangiling is happening. In VI2 add a pop-up that hsows you error coluster after you attempt to open the ref to VI1.

---

Unfortunately, the crash occurs before the front panel of subvi1.vi appears, and before subvi2.vi runs, therefore I cannot see the result of a path indicator on subvi1.vi nor an error cluster/dialogue in subvi2.vi.

---

Two other things that could be happening (not sure yet) are if the new VI is opening in the same context as VI1 and VI Server setting to allow opening the ref to vi1.

---

Not sure what you mean here Ben, can you elucidate a little for me please?

[Thoric]

---

Norbert B wrote:

Thoric,

it's disturbing that LV is crashing on your system due to this error.  What version of LV do you use?

LV 8.6.1 at least (i don't know which version was the first one) creates the following error:

LabVIEW:  Open VI Reference no longer matches VIs in memory by filename. A filename is no longer sufficient because the full name of a VI now includes any owning libraries.

This error occurs even in the developement system.

I asume that the crash itself is created by handling of invalid references.

hope this helps,

Norbert 

---

Norbert,

I am using LV 8.6 (not 8.6.1). I am using strings to identify vis, not paths. I believe the error you are encountering only relates to using paths for referencing vis.

If your assumption is correct and my crash is due the handling of invalid references, then I need to generate a path to the vi, rather then using it's name. But generating a full (non-relative) path might be tricky? If within subvi2.vi I use the 'current vi's path' function and strip it to determine the executable path, then add subvi1.vi, should that get me the path to subvi1?

[Ben]

Hi Thoric,

THe issue may be realted to not being able to run and show VI1 now that I read that added info. In that case put up some indicators around launching VI to show the error cluster from trying to launch and open it.

RE: my goobly-gook...

Multiple LV exe can run side by side because they run in different contexts (OS memory space is unique to that app). If you look at the inputs of the Open VI ref you will see that you can dictate which context it will open the VI in. VI server also comes into play as well in an exe so this is where the error code (if any) from trying to open and load VI1 can help us out.

Ben

[Ben]

---

Thoric wrote:

---

Norbert B wrote:

Thoric,

it's disturbing that LV is crashing on your system due to this error.  What version of LV do you use?

LV 8.6.1 at least (i don't know which version was the first one) creates the following error:

LabVIEW:  Open VI Reference no longer matches VIs in memory by filename. A filename is no longer sufficient because the full name of a VI now includes any owning libraries.

This error occurs even in the developement system.

I asume that the crash itself is created by handling of invalid references.

hope this helps,

Norbert 

---

Norbert,

I am using LV 8.6 (not 8.6.1). I am using strings to identify vis, not paths. I believe the error you are encountering only relates to using paths for referencing vis.

If your assumption is correct and my crash is due the handling of invalid references, then I need to generate a path to the vi, rather then using it's name. But generating a full (non-relative) path might be tricky? If within subvi2.vi I use the 'current vi's path' function and strip it to determine the executable path, then add subvi1.vi, should that get me the path to subvi1?

---

THis really depends on how you did your build. If VI1 ends up as dynamic file vs part of the app, the paths will be different. Easy enough to check. Look at where your exe is and figure out if VI1 is there in the support/dynamics. If not it is probably inside the exe to the path would then be "My.exe.VI1.vi".

But I am speculating thats the issue so try to get more info.

Ben

[Norbert_B]

Thoric,

changing the VI's name to the (absolute/relative) path is definetly something you should try.

You are correct, in my test i used a path-constant where i simply inserted the name of the VI (without it's relative path).

After changing the path-constant into a string one (wihtout changing the content), i receive the following error:

LabVIEW:  The VI is not in memory.

To load a VI into memory with the Open VI Reference function, a path must be wired for the VI Path input.

So in either case, you have to work with a path. In your developement system it only works if you opened your subVI before, hence you have it already in memory. 

hope this helps,

Norbert 

[Thoric]

I played around a little bit more, and tried using filepaths and got exactly the same error.

Then I removed all the code relating to VI server - and still got the crash. That got my suspicions up, so I back-tracked a few versions and have tracked the error down to subvi2.vi attempting to show it's front panel !?

Normally, subvi2.vi does not need to show it's front panel, so "show front panel when loaded" is not checked in its vi properties. During this testing phase, I've been trying to show the front panel for debugging purposes and that's what has been causing the Windows error ! 

But why simply showing a front panel should cause such a major crash is peculiar - am I missing something here?

[Ben]

---

Thoric wrote:

I played around a little bit more, and tried using filepaths and got exactly the same error.

Then I removed all the code relating to VI server - and still got the crash. That got my suspicions up, so I back-tracked a few versions and have tracked the error down to subvi2.vi attempting to show it's front panel !?

Normally, subvi2.vi does not need to show it's front panel, so "show front panel when loaded" is not checked in its vi properties. During this testing phase, I've been trying to show the front panel for debugging purposes and that's what has been causing the Windows error ! 

But why simply showing a front panel should cause such a major crash is peculiar - am I missing something here?

---

Checking that option force the builder to include the FP. I would not be suprised if the crash is due to not haveing a FP to show.

I sure hope I'm helping more than I am hurting!

Ben