LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with setting the tag "Bld_localDestDir" in pre-build VI: Project gets saved to previous localDestDir.

Solved!
Go to solution

Hey All,

 

I'm writing a pre-build VI that updates the build destination (and other items, but we're ignoring those for now). This pre-build vi, when run, grabs the Destination Directory from the tag "Bld_localDestDir" and modifies the directory by incrementing a version number.

 

The issue I'm having is that after the pre-build vi is run, the build continues and puts the executable in the *previous* Destination directory instead of the updated one.

 

Example:

Destination Dir = c:\temp\version1   -->   Choose to build the executable   -->   Pre-build VI runs and sets Destination Dir to c:\temp\version2   -->   Build finishes and says "You can locate the build at C:\temp\version1"   -->   Check the build properties, destination dir is C:\temp\version2   -->   build again   -->   Pre-build runs and updates destination to version3   -->   Build finishes and says "you can locate the build at C:\temp\version2"   -->   check build properties, destination dir is C:\temp\version3

 

And so on and so forth. As you can see, the tag setting is working (as witnessed by the Build Properties being updated). However, it looks like the destination directory for the build is determined and set *before* the pre-build VI is run. This is, in my opinion, not intended behavior.

 

Here's a snippet of a watered-down version of the code, which still has the issue. I've also attached the full VI, saved for LV2010.

Pre-Build snippet - simple.png

 

The attached VI will grab the version number of the build, append it to the startup vi's title bar, update the build destinations with a new path that has the version number, and then save the project.

 

 

As a final note, I'd prefer to not use a post-build VI to rename the directory that the build is placed in.

 

 

0 Kudos
Message 1 of 5
(2,911 Views)

Hey dthor,

 

We were able to replicate your problem here as well. We are also seeing that the destination directory for the build is determined and set *before* the pre-build VI is run. Just so I am aware, have you found any other documentation concerning Pre-Build VI's?

 

Thanks,

Message 2 of 5
(2,888 Views)
Solution
Accepted by topic author dthor

Using this approach to modify Application Builder settings is not recommended. While the Appplication Builder code uses the values in the tags, it potentially processes the information and so simply updating values may not have the desired effect.

 

The Pre/Post Build steps we intended to allow users to execute code that pre/post processed their own code or execute actions not performed by Application Builder (i.e. checking source files out before building or moving built files to an export location). Attempting to modify build settings after the build has started, again, is not recommended and (as you have seen) may result in unexpected behavior.

George M
National Instruments
Message 3 of 5
(2,878 Views)

> Leah-L Said:

We were able to replicate your problem here as well. We are also seeing that the destination directory for the build is determined and set *before* the pre-build VI is run. Just so I am aware, have you found any other documentation concerning Pre-Build VI's?

 

Cool, thanks for confirming that I'm not crazy. Smiley Very Happy  And no, I haven't found any documentation concerning this phenomenon.

 

> gmart Said:

it potentially processes the information and so simply updating values may not have the desired effect

 

Good to know. I think this should be in the documentation somewhere though, perhaps in the detailed help for the Get/Set Tag invoke nodes for a Build Spec reference.

 

 

To fix the issue, I've just made my own "Build Executable" vi that sets the tags before the build is started. It uses the same VI that I attached earlier (confirming that the VI works). Instead of starting the build from the project window and having a pre-build vi execute, I run this stand-alone VI and it builds the app.

0 Kudos
Message 4 of 5
(2,871 Views)

Thanks for the post, it looks like nothing has changed over the last 6 years. Good to know this unexpected behavior is expected though.

0 Kudos
Message 5 of 5
(2,518 Views)