LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Conditional Disable Symbols does not work in a Post-Build Action.vi?

Hello,

 

I want to use the conditional disable symbols in a Post-Build Action.vi.  I want to do this to include or not some files based on the conditional disable symbols value.

 

I have attached a simple example where the conditional disable symbol "test=b".  But when I build the executable the Post-Build Action.vi shows the dialog string located in "test=a"(default) case?  So, it looks like it's always executing the default case.  In addition, when I open the Post-Build Action.vi the right case is enable...

 

Do I miss something? Is this how it should behave? Is this a bug?

 

I'm using LabVIEW 2013.

 

Thanks,

 

Michel

Message 1 of 15
(3,510 Views)

You may be running afoul of what I might call "an undocumented, and unexpected, feature".  I encountered one such on the other end, the Pre-Build Action.  I wanted to use it, along with the new Set Build Specification Version, to (you guessed it!) set the Build Specification Version before I did the Build.  Well, the Build procedure seems to cache the Version before calling the Pre-Build Action.  The Good News is that the function does work, so the next time I build my executable, the previously-updated Version is used ...

 

Perhaps the rules for the Post-Build Action also have some unexpected "Features" that we can discover by doing things that seem legal and logical (to us), but that NI has "implemented in a different way".  Hopefully you'll get more sympathy from NI on your issue than I did on mine.

 

Bob Schor

0 Kudos
Message 2 of 15
(3,494 Views)

Hello Bob,

 

At lease if they can tell me if it's the "normal" behavior and why it is behaving like this would be great.  I'll wait for an answer from them.

 

Also, I just want to say that I have a alternative for this "bug".  See code below how to retreive Conditional Disable Symbols (Get/Set) values in the Pre or Post Build action.

 

getsetsymbols.png

 

Michel.

0 Kudos
Message 3 of 15
(3,474 Views)
I seem to remember something a while back where I was trying to debug a post-build VI and nothing worked. I decided that these functions must be running in their own little world sort of like callback VIs. If that is the case it would make sense that the conditional disable doesn't work because the VI doesn't have access to the project share the conditional definitions are stored.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 4 of 15
(3,444 Views)

You are probably right, but then why does the Template include Project Path?  I know my Pre-Build Action can (and does) run VIs in my Project, so I suspect the Post-Build is similarly "enabled".  This is, I think, somehow wrapped up in the convoluted set of actions that constitutes a Build ...

 

BS

0 Kudos
Message 5 of 15
(3,393 Views)

@mikeporter wrote:
I seem to remember something a while back where I was trying to debug a post-build VI and nothing worked. I decided that these functions must be running in their own little world sort of like callback VIs. If that is the case it would make sense that the conditional disable doesn't work because the VI doesn't have access to the project share the conditional definitions are stored.

Mike...

Hello Mike,

 

With the attached VI in my previous post I"m able to "set" the conditional disable symbols in the Pre-Build Action.vi.  I'm doing that because in development I can set various symbols to some values, which needs to be set to specifics values at compilation time.  I'm also able to "get" the values from the symbol with this function and when I put the conditional disable symbols structure on the block diagram of the Post-Build Action.vi the VI is not broken and in any case the default value will be used (which is wrong).  If there are no documentation relating this behavior I don't have a choice to think that this is a bug and if it's not NI should provide some documentation or an explanation.

 

I'm hoping that some folks at NI can answer this.  As I said, this is not a major issue since I have a workaround.

 

Best regards,

 

Michel 

0 Kudos
Message 6 of 15
(3,378 Views)

@Bob_Schor wrote:

You are probably right, but then why does the Template include Project Path?  I know my Pre-Build Action can (and does) run VIs in my Project, so I suspect the Post-Build is similarly "enabled".  This is, I think, somehow wrapped up in the convoluted set of actions that constitutes a Build ...

 

BS


Hello Bob,

 

PS: For other readers this is not related to this post, but you can read if you want.

 

Can you share the code snippet that you are using to get the svn revision you put into the executable version (X.X.X.svnrevision)? (I'm referring to another post here, but since you are talking about "set of actions that constitues a Build") I take my chances.

 

I going to work on a component that will be used in the Pre-Build Action.vi that will qualify my build as "official".  The definition of "official" means that my svn working copy is up to date with the svn repository which does not contains any M=modification, !=Local deleted VI's, *=Modified on the server, .... etc.  In the Pre-Build Action.vi I'm going to display the VI's that needs to be taking care of for an "official" build.  In addition I still want to be able to build the application if there is any VI's out of sync VI with the repository but the build won't be considered as "official".  The main goal here is that the executable revision number contains the svn version that match my build.  So, at any time you can easily get the source code used to compile the "official" build.

 

Anyway, if you think that this feature exist somewhere let me know.  Otherwise I may start something on some idea page that I saw on NI website.

 

Best regards,

 

Michel

0 Kudos
Message 7 of 15
(3,370 Views)

Here you go.  I'm sure you can figure out an equivalent to my Split at Token VI (I think there's an OpenG equivalent).

SVN Build.png

Bob Schor

 

Message 8 of 15
(3,356 Views)

Just going back to the original question, the Pre and Post Build Action VIs don't execute in the same context (say, Application Instance) as the target (My Computer or equivalent) or the project itself: it's a different context. So because this context is not aware of the Symbol you are using, it runs the default case.

 

You can use this VI to get the context in which  the Pre and Post Build Action execute (Spoil: name is NI.LV.MxLvProvider)

 

Regards,

--Eric

Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.

0 Kudos
Message 9 of 15
(3,318 Views)

@Eric.M wrote:

Just going back to the original question, the Pre and Post Build Action VIs don't execute in the same context (say, Application Instance) as the target (My Computer or equivalent) or the project itself: it's a different context. So because this context is not aware of the Symbol you are using, it runs the default case.

 

You can use this VI to get the context in which  the Pre and Post Build Action execute (Spoil: name is NI.LV.MxLvProvider)

 

Regards,

--Eric


 

Hello Éric,

 

You would be kind if you can send the VI in  LV 2012 version.

 

Thanks,

 

Michel

0 Kudos
Message 10 of 15
(3,309 Views)