error code 1 occurs with build of .exe (problem VI attached)

[MoReese]

The problem I have been having with a particular project has been posted many times by others.  I have read through many of the threads related to this (or somewhat related to it).  I've tried some things but not all.  I finally started disabling sections of my code to see if the error went away.  I have tracked it down to the attached VI.  The error code is also attached.  Can someone analyze this VI and see what the problem could be?  It uses .NET objects, so I am not sure exactly what the compiler is looking for.  I should note that this is not my VI, but one I copied from the forum here.  As far as e-mail, the VI works great in development mode, but obviously I desire a stand-alone application.

Also note that I created a new project and dropped this VI on the top-level VI and it built an .exe just fine, which doesn't make any sense to me. Perhaps someone can shed some light on this issue.  When I tried moving it back to the original project, it failed the build.  If all instances of this VI are disabled in my project (using a disable diagram), it builds the project with no errors.  Thanks in advance for your assistance.

Reese

[mikeporter]

I just built it into a standalone executable on my machine and no error...

Mike...

PS: You might want to consider changing your gmail password ASAP seeing as how you just handed it out to the entire planet.

[MoReese]

Thanks, Mike.  Yes, my password has already been changed, no worry there. 

I was also able to create a new project with no error, as I stated.  Do you have any idea as to why this particular VI will not work in my application?

Reese

[MoReese]

Update:  I disabled every structure in my application, and dropped the gmail.vi onto the block diagram and it still would not build; however, if I drop the vi onto a new project, it builds fine.

I will try to create a new project and move all VIs over and see if that fixes it.

Any other suggestions would be appreciated.

Reese

[MoReese · Accepted solution]

Well, I found a solution but I still don't know why the original VI would not build in my app.  I simply created a new VI and copied each section of code from the original over, bit by bit, build, and then copy some more until the whole thing was copied over.  It built with no errors each time.  It's a head scratcher, but the only thing I can think of is, considering the original VI was not my code, there may be a compatability issue going on.  But again, it worked in a brand new project, so I'm not so sure.  The lesson I learned from this (and I know better), is don't wait until the end of your project to do a build.  Lesson learned!

[shb]

I have the same problem, me too.

It took often some time to be able to compile my project. I modified some code in some VIs (but keeping the functionality) until I modified the blocking part by hazard and compile worked. But today it takes me hours and I am still trying on.

When I remember right the message most often told me about a broken VI. (But there was none.) But today I got the same error message as you. There is no helpful information included:

An error has occurred. Expand the Details section for more information.

----------------------------------------------------------------------

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

Error 1 occurred at AB_Application.lvclass:Create_INI_File.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_EXE.lvclass:Copy_Files.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:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488:  Command requires GPIB Controller to be Controller-In-Charge.

Any hints how to quickly identify the problematic code?
(My guess was that it could have something to do with upconverted VIs containing a conditional disable structure. But it looked like this was not always the case.)

Greetings,

shb

[RavensFan]

Another situation that cries out for this idea Better error descriptions for Application Builder.

Please vote for it.

[shb]

A Kudo for the Idea and one for the suggestion to vote! This idea should really be realized!

[MoReese]

Yes, no helpful information at all.  The problem was isolated by disabling different sections of code, little by little.  It took me longer to isolate, because the "bad" code in question was used in three different locations in my program.  But once found, I recoded it from scratch and it worked fine.

[shb]

The last time (see above) compiling was possible on the next day. It worked suddenly without any reason I could see.

Yesterday I had the same problem again. I had to build a new release and compiling failed again. And again I tried for several hours. Today it worked on the 2nd try.

What I tried to make the build work:

• I modified some VIs and started compilation again
• I had the main VI open or had let it closed before starting compiling.
• I restarted LabVIEW.
• I recompiled all VIs. 
• I rebooted the computer.
• I started the build automatically (Build.vi in Application Builder palette)

All I managed was to change between error 1 (invalid input) and error 1003 reporting the main VI as broken. (This change was often when I compiled with the main VI open or closed. But it could be both way round. And there was no rule I could see.) Error 1003 has the advantage that it appears in the beginning of the process while error 1 is just in the end.

I switched off the computer overnight. And today it worked at the 2nd try. I did not modify any code before.

Running LabVIEW 2011 SP1 f2 on Windows 7 SP1

Greetings,

shb (hoping the next release will be easier!)

More technical details follow in the next message.