Error 1003 when dynamically calling VI within an executable

[thutch79]

Now this gets to the root of my question. How to debug...

I'm not sure putting indicators will help me much. I'm not getting a file or vi not found error, I'm getting an error that the VI is not executable. If that is occurring because that VI can't find a certain dependant, I have no way to tell which dependant that is. Putting an indicator on that VI won't help because it can't execute. I was hoping there is some way to programmatically output the error list on a VI, but so far I have found a way. My thinking was I could open a reference to the "broken" VI and have it report its compile errors.

That brings up another issue. If the VI is indeed broken, shouldn't the build fail? I thought all VI's included in a build needed to be execuatble for the build to be successful.

[Drew_H]

This is probably a very silly suggestion, but what happens if you move your executable to the base C:\ directory?  I ask because I know LV has some issues when file paths exceed 256 characters, and if the VIs that are failing have slightly longer names than those that are succeeding, it might point to that as the culprit -- especialy if your current executable is buried somewhere deep in a file heiarchy.

[David-A]

Do you get the same error if you dynamically call a VI that resides within a compiled library? For example, using your code, try to dynamically call a VI that resides within a packed project library and see if that throws the same 1003 error.

[dan_u]

Did you try to open a reference and use this to open the broken VI's front panel? If you have the front panel of the broken VI open (even in the exe) you can click the broken run arrow and it should report what it is missing.

Yes, VIs must not be broken when compiling, but you say they are fine in the development system. The compiler seems to do something that breaks it.

[mikeporter]

---

@thutch79 wrote:

This VI does use a number of classes. I get many warnings with regards to naming conflicts. However, that, in many cases, is the whole point of using classes. I have many dynamic dispatch VIs. How is this handled within executables? Is it OK that many of my method VIs have the same name by design? Not sure if that's the root of the issue, but I suspect it could have something to do with the issue since many of our recent changes are around moving towards more object oriented code.

---

Wait a minute, we may have a more fundamental problem here. You should not ever get name conflict warnings. Even with classes and dynamic dispatch, two VI's can not have the same name. Remember that if a VI is part of a structure like a class or a library, from LV's point of view the name of that structure becomes part of that VI's name.

Also it isn't just OK, it's required that the override VIs for a method have the same file name as the parent method. This is why dynamic dispatch VIs need to be separate directories: Windows doesn't know about LV classes or libraries.

Do you have your class inheritances setup correctly?

Sounds like you have some basic things you need to learn about object-oriented approaches.

Mike...

[Thoric]

I seem to remember being here myself once a few years ago. I can't recall the specifics, but I think there's a way to take the VI reference and call a method on it to list its dependencies. You can then check those dependencies one by one for issues to work out which subVI (etc.) is causing the error.

[thutch79]

I (with the help of my coworker) worked on opening the front panel to see what the error is. Attached is the error 2228 reported from the VI. I used "explain error" function to learn this is an undefined error. I have no idea where to go with this.

I was wrong about there being warnings in the build. I think those were there when I was trying the LV 8.x file format option out. 

---

@mikeporter wrote:

Sounds like you have some basic things you need to learn about object-oriented approaches

---

Thanks to everyone that is patiently helping. As for this input, thank you for not disappointing me when I expect someone to chime in with a condescending and completely useless comment...

[mikeporter]

You clearly seem to be missing a lot of knowledge about how OO works. I am soooo sorry if it warps your self esteem to have someone point that out. Of course you could also take it as guidance to get the education you need -- something that would be very helpful and very useful. However you would first have to get the chip off your shoulder.

By the way, do you have the inheritances set correctly? Have you resolved the duplicate file name errors?

On second thought, don't bother answering. I've stopped listening. I have better things to do with my time than to deal with people like you.

Mike...

[A1Penguin]

I see this post is over a year and a half old, but has there been a solution?  I seem to be having the same problem. Everything works fine in development mode, but the problem arrises when I compile.   I have a main vi that calls another VI by reference. 

The calling vi has no trouble finding the referenced vi, however the referenced vi fails to run and has a broken arrow.  Clicking the arrow launches a dialog box indicating that the referenced VI can not find some if its sub VIs.  These sub VIs are standard LabVIEW VIs.  In the development mode, LabVIEW has no trouble finding them.  I have the same problem whether I use the call by reference VI or the RunVI invoke node. 

A web search provided many suggestions, but of these, only two change the behavior of the compiled version.  Of these, neither is acceptable.

The first one was to check the Use LabVIEW 8.x file layout box in the applications properties window.   This created a huge directory of copied VIs in the build directory.   The second one was putting a path to labview libraries in the .ini file.  This caused the referenced VI to search for the missing VIs.  The search window that appears seems to find a lot of missing files, however I still have a broken arrow on the referenced VI and when clicking it, I am still missing all of the same VIs.

I should note that the referenced VI is in the Always Included box in the source files section of theapplication properties window.

Also, I am using LabVIEW 2013 and in the past, I have done exactly what I am trying to do in LabVIEW 2009 and not had this trouble.

I am including a very stripped down test case in a zip file.

Thanks in advance for any help.

[A1Penguin]

My previous zip file did not contain all of the files I meant to be in my example.  Please use this one.  Sorry for the confusion.