Error7 occurred at Open File+.vi for the build executable.

[Donat-Pierre]

I build an application to use as an exec on a PC with LabView7.0 runtime. It seems to be built ok but when I run it on the ported PC, here is the displayed message:
"Error7 occurred at Open File+.vi: Open file
LabVIEW: File not found etc...

This vi file is part of the vi.lib\Utility\file.llb shipped with LabVIEW. Any idea how I can make the built version work?

I saved this vi in my own vi application (i.e. saved as) but it still does not work.

I look forward t o hear back from you very soon as I need this up and running to analyze data.

Donat-Pierre LUIGI

[Carlos Romero]

I don't know. Maybe file.llb has been changed.

I send you my file.llb

You see it.

[Dennis_Knutson]

I doubt that there's a problem with the VI. The error is probably occuring because the file you're trying to open cannot be found. How are you getting the path to the file that you need to open? If your're getting a file path relative to the location of a VI, you must do an extra strip path in a built application. In the development environment, the path to a VI might be c:\folder\my.vi but in a built app, it would be c:\folder\my.exe\my.vi. This problem comes up about once a week on the forum. You can use a property node of app.kind to determine run-time or development and do the extra strip path based on that.

[Donat-Pierre]

I tried a couple of more things such as building a library of my application swith "Save with option" and then building the exec form that library. It built sucessfully once and I still get the same error message regarding FileOPen+.vi. Note that this VI was flatten out in the copy of Read Line From File.vi, which resulting vi is saved in the local directory of the main vi. Thus, even though it does not exist teh error message still pops-up?!
Also subsequent/other build from llb failed. The difference in some case I load teh VI in memory with shift+ctrl pressed when clicking on the run button, then saved all, and/or save a llb of the application and its sub-VIs.

I did not try Mass compile - I should read what it does first. ALready, I might ha
ve touched few files unecessarily with save all. I guess this is frustrating.

I even saved the executable in a directory directory which can be replicated on the source architecture (another Dell PC instead of my laptop, both with Windows 2000).

I think I get the gist of what you suggested here. But using an app property node to strip the path would not defy the purpose of having a Builder which should embed all this source code into an excecutable file?

Could you tell me how and where such strip with an application property node path should be applied in my code.

Many thanks for your help. I look forward to your reply.

Donat

[Donat-Pierre]

I tried a couple of more things such as building a library of my application swith "Save with option" and then building the exec form that library. It built sucessfully once and I still get the same error message regarding FileOPen+.vi. Note that this VI was flatten out in the copy of Read Line From File.vi, which resulting vi is saved in the local directory of the main vi. Thus, even though it does not exist teh error message still pops-up?!
Also subsequent/other build from llb failed. The difference in some case I load teh VI in memory with shift+ctrl pressed when clicking on the run button, then saved all, and/or save a llb of the application and its sub-VIs.

I did not try Mass compile - I should read what it does first. Already, I might ha
ve touched few files unecessarily with save all. I guess this is frustrating.

I even saved the executable in a directory directory which can be replicated on the source architecture (another Dell PC instead of my laptop, both with Windows 2000).

I think I get the gist of what you suggested here. But using an app property node to strip the path would not defy the purpose of having a Builder which should embed all this source code into an excecutable file?

Could you tell me how and where such strip with an application property node path should be applied in my code.

Many thanks for your help. I look forward to your reply.

Donat

p.s.: I forgot to send this when it was writen earlier because of tyeh pause for reviewing. Since then, two copies of my main VI (i.e. a two location in the working directy that always had under My Document) are now afflicted by the same Error 7 for OpenFile+.vi.

It is going from bad to worst... I tried to reset the VI Path Search in Optio
ns to defaults, and then re-inserted the path for OpenG.lib. ANd it did not do the trick. It is very worrying since OpenFile+ is not effectively part of the sub-VI of main Vi (i.e. called by it in any ways).

Help...

[Donat-Pierre]

I tried a couple of more things such as building a library of my application swith "Save with option" and then building the exec form that library. It built sucessfully once and I still get the same error message regarding FileOPen+.vi. Note that this VI was flatten out in the copy of Read Line From File.vi, which resulting vi is saved in the local directory of the main vi. Thus, even though it does not exist teh error message still pops-up?!
Also subsequent/other build from llb failed. The difference in some case I load teh VI in memory with shift+ctrl pressed when clicking on the run button, then saved all, and/or save a llb of the application and its sub-VIs.

I did not try Mass compile - I should read what it does first. Already, I might ha
ve touched few files unecessarily with save all. I guess this is frustrating.

I even saved the executable in a directory directory which can be replicated on the source architecture (another Dell PC instead of my laptop, both with Windows 2000).

I think I get the gist of what you suggested here. But using an app property node to strip the path would not defy the purpose of having a Builder which should embed all this source code into an excecutable file?

Could you tell me how and where such strip with an application property node path should be applied in my code.

Many thanks for your help. I look forward to your reply.

Donat

p.s.: I forgot to send this when it was writen earlier because of tyeh pause for reviewing. Since then, two copies of my main VI (i.e. in two different location in the working directory that always have been under My Document) are now afflicted by the same Error 7 for OpenFile+.vi.

It is going from bad to worst... I tried to reset the VI P
ath Search in Options to defaults, and then re-inserted the path for OpenG.lib. ANd it did not do the trick. It is very worrying since OpenFile+ is not effectively part of the sub-VI of main Vi (i.e. called by it in any ways).

Help...

[Donat-Pierre]

Thank you Carlos. The file.llb was fine and the executable was properly compiled. Indeed I did not get an error message during the Build except while building form llb because of Path issues.
After a day of panic, and scrambling around it went form bad to worst as both my main VI copies (dev and final version) stop working too with teh same error message. It downed on me that the error message from Labview should have been been "Can't open file" in OpenFile+.vi...
Yes, my profond apologies, the data file I was reading from a dialogue box was no ported with the execuctable. That is why, when I test run it on a different PC, the OpenFile+ issued and error because it could not open the file defined in the path, since it did not exist. The message e
rror was built form a cluster of boolen, error# and string. The message component is form a string constant which said "OpenFile+.vi: File Dialog" and error # set to 7.
It followed that an error message, interpreted from the Error code #7 always mention OpenFile+.

Moral of the day or two of crisis. Don't cut on your night sleep too much for work and remember to reset the File Path dialogue after your are done developping.

Many thanks to both of you for your suggestions.

Donat-Pierre

[Donat-Pierre]

Dennis,

Problem solved. Read the explanation I just wrote to Carlos. Also my apologies for sending three times the last message as I edited it.

In a nutshell, the data file I was reading used to be set as default in the dialogue file path. However, the string constant in the OpenFile+ case structures (generating parameters for the Error out) always mentioned itself "OpenFile+". This compounded with Error code 7, was interpreted in the Error Message Dialog as a combined explanation which implied that the VI as the problem instead of "File does not Exist in this path".

What happened earlier with my main VI (i.e. source code)that I reported to you in my previous post(s), is what led me to this realization. I renamed with a typo the input dat
a file I was editing, which is why the error came up all over again.

Simple but stupid. I am such a rookie, only one year programming with LabView and it shows, obviously.

Many thanks for your suggestion. I did not get to implement it. It might be useful in a genuinely path issue for the development environment.

Donat