04-01-2015 08:31 AM
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
04-01-2015 09:59 AM
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
04-01-2015 10:41 AM
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.
Michel.
04-01-2015 08:43 PM
04-02-2015 03:15 PM
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
04-02-2015 06:52 PM
@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
04-02-2015 07:17 PM
@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
04-02-2015 08:40 PM
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).
Bob Schor
04-03-2015 05:58 AM
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.
04-03-2015 06:05 AM - edited 04-03-2015 06:05 AM
@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