[WinXP, LV2009.1] No bad VIs in mass compile, but error 1003 during build

[GeorgeG]

I am in the middle of code development for a big application (500 VIs currently) on Windows XP with LabVIEW 2009 SP1. The application currently has 24 classes, 3 levels of OO inheritance, one XControl whose data type is one of the classes and uses the friend scope, lots of VI server calls (dynamic VIs, reentrant dynamic VIs, property and invoke nodes, etc), and a couple of external DLLs. In the development environment everything runs wonderfully. Mass compiling the project shows no bad VIs, but an attempt to build the top level VI into an application fails immediately with Error 1003 (shown below). I have googled and googled, and this seems to be a common enough problem, but none of the solutions I have found have gotten me any closer to an executable. I have tried disabling blocks of the diagram to try to find the offending VI or VIs, but no luck there either. If I disable the entire diagram it will build, but I have not been able to disable anything less than the entire top level diagram and get it to build. I have also tried many build configurations, including keeping all of the front panels and block diagrams, disconnecting type definitions, telling the application builder to include all of the VIs in the build. I am running low on ideas of how to even start narrowing down the problem to a specific class or VI. The single, unhelpful, error message is below. Any ideas?

George

The VI is broken. Open the VI in LabVIEW and fix the errors.

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1003 occurred at AB_Application.lvclass:Open_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.

[Daklu]

Two probably useless thoughts...

1. The vi name "AB_Build_Invoke.vi.ProxyCaller" seems rather peculiar. Is the AB_Application.lvclass one of the classes in your application? Maybe it's a dynamically class created by the build engine?

2. You try removing the old top level diagram from the project, creating a new blank top level diagram, and adding in bits of functionality and checking if you can build it.

[GeorgeG]

Two probably useless thoughts...

1. The vi name "AB_Build_Invoke.vi.ProxyCaller" seems rather peculiar. Is the AB_Application.lvclass one of the classes in your application? Maybe it's a dynamically class created by the build engine?

2. You try removing the old top level diagram from the project, creating a new blank top level diagram, and adding in bits of functionality and checking if you can build it.

1. All of those VIs in the error message are NIs. I assume they are the code of the application builder.

2. That is what I am doing right now, and still haven't isolated the "broken" VI. When making a top level VI from scratch and just adding tiny subsets of the functionality, I can get it to build sometimes, and not others, but I still haven't discerned the pattern. I can have the exact same sequence of VI's, and just change which class object is at the front of the chain, and that is the difference between building and failing.

I didn't mention in my original post, but I also make extensive use of dynamic dispatch with the classes.

[Francois Normandin]

Error 1003 occurred at AB_Application.lvclass:Open_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

MIght not be that, but I sometimes get this kind of messages with "AB_Build_Invoke.vi.ProxyCaller" that is solved when I shorten the build directory path length. Make sure the hierarchy you're trying to save on disk is not longer than 255 characters.

[GeorgeG]

MIght not be that, but I sometimes get this kind of messages with "AB_Build_Invoke.vi.ProxyCaller" that is solved when I shorten the build directory path length. Make sure the hierarchy you're trying to save on disk is not longer than 255 characters.

Moved the whole project to C:\project\ and tried to build it, but got the same error message. Thanks for the idea though! I fear the problem is something obscure like this

Since I made my original post, I have been playing around with a nearly empty top level VI trying to find the simplest VI that wouldn't build. Right now I have a class object constant wired to a default indicator of that class, and won't build.

[Shaun Hayward]

Are any VIs that include the Xcontrol (either as a variable, or on the front panel) loaded and/or open? If so, try making sure all other VIs are closed before you build - this solved an error that I had that looked similar (I cant remember the exact code).

Shaun

[GeorgeG]

All VIs are definitely closed when I try to build the application. I think I have, however, narrowed the problem down to something about the XControl or its underlying classes. I have created a new, empty project and added the XControl and the associated class. I then created a top level VI with just the XControl on its front panel. This will not build. Unfortunately there are still some 200 VI's involved, so I still don't have a clear idea of what is causing the problem.

[GeorgeG]

Found this post from a thread in February:

I have one of those errors... tracked it to a LV class that has in its private data control a strict VI Refnum that used the class itself as part of the conpane. Any chance that's your bug?

And I do indeed have such a strict VI refnum in the private data of a class. This is a "bug"? Why does this compile in the development environment, but not build in the application builder? Is there a work around?

And taking that out of the private data and turning the corresponding accessor VIs into stubs fixed the build problem. Is there a reason the compiler doesn't complain about this situation or a reason the compiler and the application builder treat it differently?

[GeorgeG]

Problem solved! Aristos stated the problem exactly, and to fix it and keep the original functionality unchanged, I replaced the Refnum with a string in the private data, and in the accessors I added code to flatten and unflatted from string. Thus the refnum is still stored in the class, and no code outside the class had to change, and I was able to hide from LabVIEW that ugly strict refnum it seems to hate so much.

I would still like to hear why this is a problem, and, more importantly, why it is not stated more clearly by the compiler or the application builder. I want my two days back!

George

[Daklu]

Thus the refnum is still stored in the class, and no code outside the class had to change

I love encapsulation.

Can't help you with your lost two days, but think about how bad it could have been had you not been able to hide the way you stored the refnum.