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

[Michel_Gauvin]

---

@Bob_Schor wrote:

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

---

Thanks Bob.

[Eric.M]

Here you go. It's password-protected (sorry 'bout that) because it uses a private function but trust me it's not very interesting in there 🙂

[Michel_Gauvin]

---

@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,

See, I don't agree how this is managed since the build specification is part of the "project" and the conditional disable symbols are also part of the project. The build is launched from the project.  The context in which the build is executed should have access to this information.  My proposal here would be:

1. To support the the conditional disable symbols

2. To no support them.  Show a broken arrow when a VI is used in the "Post-Build Action" of a build specification which uses the conditional disable symbols and show a meaningful description of the problem.

I don't think to be in between benefit anyone. So, I still consider this as a bug since it is allowed to put it into the VI but don't behave as it should, simple logic.

Michel

[Eric.M]

Well, fortunately for you (and everyone!), the Application Builder runs in a separate context. A different context ensure the Application Builder VIs as well as your VIs included in your build spec. to run safely in their own data space. This means there will be no cross-compiling issue, naming issue or no other annoying behavior caused by the fact you are calling a VI that might already be loaded in the "My Computer" context.

Regarding your second point, I don't disagree with it, that would be for the best. Yet, I believe the difficulty to implement this will be fairly high for a feature/bug that hardly anyone happen to see. A KB or a note in the help would probably the best option 😃

--Eric

[Michel_Gauvin]

---

@Eric.M wrote:

Well, fortunately for you (and everyone!), the Application Builder runs in a separate context. A different context ensure the Application Builder VIs as well as your VIs included in your build spec. to run safely in their own data space. This means there will be no cross-compiling issue, naming issue or no other annoying behavior caused by the fact you are calling a VI that might already be loaded in the "My Computer" context.

Regarding your second point, I don't disagree with it, that would be for the best. Yet, I believe the difficulty to implement this will be fairly high for a feature/bug that hardly anyone happen to see. A KB or a note in the help would probably the best option 😃

--Eric

---

Of course they won't see it because it's executing the default case everytime.

I don't think I'm doing anything that anyone can't do, I just use the fonctionalities offered by the build specifications to avoid doing manual operation when building an executable.  I think this should be taken care of, but you (NI) think otherwise so there's no point commenting more on this issue.

Best regards,

Michel