LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

EXE does no longer find a control iside itself if moved to another destination

I am using LV2010SP1. Since yesterday I have a serious problem with the executable (built by the application builder) of my LV project.

The EXE is running fine when started in the destination directory where application builder created it. But when I move it to its final destination inside the program files folder of Windows and try to start it there a dialog box pops up asking me to find one of my controls.

The information in the first dialog box shows that the application expects the control to be inside the application (which is ok and where it definitely is). But the first part of the path points to the destination directory where application builder created the EXE.

So it seems as if this path is a fixed absolute path instead of a relative one. Question is why. All other VIs and controls inside the EXE file are found.

I am working on this project for 2 years now and I never saw this before! I always could move the EXE wherever necessary and didn't see this dialog box.

 

What I tried so far:

- remove the control from the project, save, quit, load the project again, add the control again -> no success

- re-compile the main vi inside LV -> no success

- clear the compiled object cache (I have separated source and object files) -> no success

- creating the project anew -> no success

- tell application builder to use the EXE file as destination for this specific control (under "source file settings") -> no success

- use LV8.x file layout -> doesn't work at all as I am using classes

 

Anybody with a good idea?

 

Thanks,

Ingo

0 Kudos
Message 1 of 5
(911 Views)

Sorry, I don't think there is enough information to troubleshoot. Can you create and attach a small application project that demonstrates the problem?

 

Why don't you build an installer instead of moving the executable into the program files hierarchy manually.

 

Another idea...

Are you on 64 bit windows? In this case 32 bit applications should go into the "Program Files (x86)" hierarchy instead. Only 64bit programs belong into the "Program Files" area.


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 2 of 5
(907 Views)

Hi Christian,

the problem is that I cannot reproduce the problem Smiley Sad

Another small EXE using exactly the same control is working as expected. I can move it where ever I want and it is running fine.

 

I am using an installer, too. But only for the initial installation. Later I am only replacing the updated application.

Before this problem came up my EXE was running fine on 50 machines (32 bit XP and Windows 7, of course in their corresponding program directories).

 

What I don't understand is that all other VIs and controls can be found by the EXE inside itself. Except this one control as the path to it seems to be fixed to a wrong absolute path...

0 Kudos
Message 3 of 5
(898 Views)

Did you get to the root of this issue.  I have just rebuilt an application following a minor modification and now it cannot find 3 controls.  The search path seems to be the path to the control appended to the path to the executable.

 

The controls in question, along with several others, are in an auto populating folder.  I am using LabVIEW 2011

0 Kudos
Message 4 of 5
(875 Views)

Hi Kenneth!

I spent a lot of time until I found a workaround. Seems as if this is a scarce bug in LV's application builder...

The control my application could not find was made of a cluster saved as strictly typedef. One of the items in the che cluster itself referred to another typedef control.
I finally ended up by saving both as "normal" controls (no typedef) and now my application is working as before, i.e. I can move it wherever I like to without any problems.

0 Kudos
Message 5 of 5
(850 Views)