open vi reference by string in executable

[Thoric]

Something interesting:

If I check the "show front panel when loaded" checkbox for subvi2.vi and create a build, it launches ok if I have a other Windows application maxmised on the screen. In other words, I launch my LabVIEW application, but before the front panels had an opportunity to appear, I switched to MS Outlook (maximised). Because of this, the problematic subvi did not have to draw its front panel (because it appeared behind Outlook).

I then restored Outlook, which revealed just a portion of subvi2.vi's front panel - still ok.

I then moved the Outlook window slowly to the side, gradually revealing more and more of subvi2.vi's front panel. When I got to revealing the ref control on the front panel, it crashed! So it seems there is a corrupted front panel control - the type def reference control icon won't display.

Now what do I do?

[Thoric]

Norbert,

user32.dll is not in the data folder of my build folder. LV must not be copying it?

[Thoric]

---

Can you show us the code where you are luanching VI2?

---

Yup:

Note there are three subvis being called, but the topmost is not pertinent to the problem. The two of interest are here iconed as MAIN.vi and Log on KeyPress Service.vi.

The coercion dot is there simply because the reference to the control Inter-code event cluster is being passed to a strict type-def of the cluster reference. I use a strict reference to make updating the code easier when it comes to adjusting the content of the inter-code event cluster type def.This coercion dot isn't a problem here (as far as I know).

Message Edited by Thoric on 04-27-2009 03:08 PM

[Norbert_B · Accepted solution]

Thoric,

the dll in the data-folder can create an unhandled exception when loading/unloading it. This is because Windows already has an user32.dll in memory (this should be true for all system dlls).

Please check if you configured other subfolder which might contain system dlls.

Regarding the control-issue: could you try to hide the control for a single run?

hope this helps,

Norbert 

[Ben]

Yikes!

1) In the build try shutting OFF "Disconnect" from typedef. The sub-VI needs to know that type def.

2) Mass compile LV (? ctlt-shift run arrow).

3) Typecast your cluster refnum as a U32 and show value in an indicator. should NOT be "0".

Ben

[Thoric]

Norbert,

I haven't configured any special folders, so the user32.dll could only be copied into data folder of the build. As it isn't there, it mustn't be being copied by LV for the build.  My build folder has no other folders, and the data folder contains no user32.dll.

Ok, attempting a build with the control ref hidden..........

............it WORKS!!!!

Out of interest, the first subvi that is called (Main) also has this control reference (as you can see from the calling code snapshot above), but it has no problems showing its own front panel ??? What I might do is copy the control reference from subvi1.vi (MAIN) and use it to replace that in subvi2.vi (Log on Keypress Service.vi). If the latter is corrupt, this might resolve the issue...

[Thoric]

---

Yikes!

---

My code that scary??

---

1) In the build try shutting OFF "Disconnect" from typedef. The sub-VI needs to know that type def.

---

In the build, I have Disconnect unchecked. Checking this option was only something I briefly tried.

---

2) Mass compile LV (? ctlt-shift run arrow).

---

I've tried this a few times already (I have the LabVIEW Keyboard Shortcuts poster mounted in front of me at all times !  )

---

3) Typecast your cluster refnum as a U32 and show value in an indicator. should NOT be "0".

---

I would, but as no front panel loads before the crash, I still won't be able to see the result 

We seem to have found the source of the crash now - a problematic front panel icon for the cluster reference in subvi2.vi. Hiding the control seems to prevent the crash! 

Although I still don't know why this came to be, I'm pleased I can resolve it now once and for all. Re-create a replacement control.

Thanks everyone! I appreciate all the assitance!

[Norbert_B]

---

Ben wrote:
[...]

1) In the build try shutting OFF "Disconnect" from typedef. The sub-VI needs to know that type def.

[...]

---

Hm, i don't think so. The typedef is only a template for "how instances will look like". If the VI is compiled into an exe, there is no possibility to change the typdef, so it is valid to disconnect all instances from "their" template.

I know that this setting sometimes leads to issues and therefore it is available. But to be honest, i cannot explain why those cases arise....

hope this helps,

Norbert 

[Ben]

---

Norbert B wrote:

---

Ben wrote:
[...]

1) In the build try shutting OFF "Disconnect" from typedef. The sub-VI needs to know that type def.

[...]

---

Hm, i don't think so. ...I know that this setting sometimes leads to issues and therefore it is available. But to be honest, i cannot explain why those cases arise....

hope this helps,

Norbert 

---

I stand corrected AND you can add a check mark to the "I can't explain..." collumn for me as well.

Ben

[snp112]

I have a LabView Executable and I want to control it by python using activex control. When I use the method getvireference I get the error open vi reference no longer matches vis in memory. A filename is no longer sufficient because fullname of  vi has own libraries. What is the reason for this ?

It works for other labview executable. Can you help me in this matter.