open vi reference by string in executable

[Norbert_B]

Thoric,

you set the option"Show frontpanel when called" in the VI settings ofsubvi2?

If so, i would expect some controls/indicators which corrupt the frontpanel of subvi2. Could you post subvi2?

hope this helps,

Norbert 

[Thoric]

Hi Ben,

Sorry for the confusion, what I meant to say was:

Normally, "show front panel when loaded" is not checked, but for the purposes of this testing phase I have had "show front panel when loaded" checked to show the front panel. This seems to be what is causing the problem for me. When checked I get the crash, when unchecked (and clearly there's no front panel in this case) the code runs ok 

Still, I wonder why I get the crash when it is checked?

[Thoric]

---

you set the option"Show frontpanel when called" in the VI settings ofsubvi2?

---

Yes, I do, and that's when I start seeing this crash.

---

If so, i would expect some controls/indicators which corrupt the frontpanel of subvi2. Could you post subvi2?

---

Corrupt controls/indicators? I hate it when this happens! All too often these days too it seems...

I've posted the subvi (it's actually called Log on keypress service.vi). As I mentioned in my first post, I've been describing but a small portion of my much larger project. This subvi is meant to send user-events to subvi1.vi when certain key-presses are detected, via a type-defined event cluster reference control called Inter-code event cluster ref. Apart from this control, there are only two boolean indicators and the standard error in and out clusters. Please take a look and let me know if there's anything here that could be 'corrupted'.

Thanks

[Norbert_B]

Thoric,

what Ben said is absolutly valid and a possible reason:

When LV compiles code for an executable, it removes as much components as possible. The frontpanel is such a component: it is only required if the frontpanel is shown later on. If you accidently remove the frontpanel during the build-process, but try to display it when running the exe, the exe has to crash. The crash does not need a crash similar to the one you are observing, nevertheless, it is possible......

Therefor please doublecheck your build-settings if you remove the frontpanel of "subvi2.VI" during the build-proces...

hope this helps,

Norbert 

[Thoric]

Yes, I am aware of how the compiler removes unecessary components, including the front panels of subvis that no longer require them. I do not explicitely disclude the front panel in the application builder, nor do I attempt to programmatically show it during run-time. I've simply been checking and unchecking the "show front panel when loaded" option depending on whether I want to see or not-see the front panel.

The problem in my case seems to be when this option is checked. Here, LabVIEW must be including the frontpanel in the build, and when this subvi is called from the main vi, it then crashes. When the option is unchecked, the application does not attempt to show the subvi's front panel and the application runs through great. Bizarre.

Message Edited by Thoric on 04-27-2009 02:39 PM

[Norbert_B]

Thoric,

the frontpanel of the VI seems ok, if the typedefinition does not mess it up. so if not the frontpanel removal-thing creates the crash, please play around with the setting "Disconnect typedefinitions" in the build script.

hope this helps,

Norbert 

[Thoric]

Thanks for the suggestions Norbert,

I tried disconnecting type definitions in the build, but it still crashes.

Out of interest, I kept this option checked in the application builder, but left "show front panel when loaded" unchecked in subvi2.vi. The program still works. It definitely seems to be a front-panel related complication.

Any more suggestions anyone?

[Thoric]

I learned a trick from an NI technical engineer once regarding corrupt vis - drag and drop the block diagram into a blank vi, relink the controls and indicators to the terminal icon and save as a new vi. Replace all calls to the original with the new vi. But it didn't work. Does this failure perhaps indicate there are no corrupt controls/indicators? I don't know, I guess we can't be sure. Just thought I'd mention it anyway.

Still trying to work around this one.....

Message Edited by Thoric on 04-27-2009 02:52 PM

[Ben]

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

Are you setting the ref before calling?

Ben

[Norbert_B]

Err, something very different is coming to my mind:

You are using the user32.dll, a system dll.

LV should detect this dll as dependency and copy it into the data-folder. This will lead to the crash you are observing. Please delete the user32.dll from the data-folder in your build-folder.

hope this helps,

Norbert