Conditional Disable based on whether code is executing from a pre-compiled Packed Project Library?

[Nate@UT]

Conditional Disable diagram structure allows one to fork code paths, for example based on whether or the development environment or run-time engine is executing the code. 

Is there any way to do this based on whether the executing code is contained in a Packed Project Library or a traditional library/project?

[ShockHouse · Accepted solution]

This isn't a conditional disable structure, but just a case structure based on whether you are in a PPL or not so you can achieve the same thing.

[Nate@UT]

Thanks!  I was too caught-up with the Conditional Disable structure and figuring out how to do this with "compiler flags" and didn't even think to look for a traditional run-time based approach.  

[paul_a_cardinale]

You can also do it like this:

When no VI reference is wired, it defaults to the current VI.

[Nate@UT]

Interestingly, when code is running from within a PPL, the built-in RUN_TIME_ENGINE flag used for Conditional Disable structures always evaluates to "False" regardless of whether or not one is running in the LV Dev Environment or in a compiled application under the Run-Time Engine.  

Configuring Conditions for Conditional Disable Structures - NI

Is this a LabVIEW bug? or by-design?   It seems to make logic using the RUN_TIME_ENGINE flag useless from PPLs.  (Note, I am using LabVIEW 2023 Q3 64-bit)

[wiebe@CARYA]

---

Nate@UT wrote:

Interestingly, when code is running from within a PPL, the built-in RUN_TIME_ENGINE flag used for Conditional Disable structures always evaluates to "False" regardless of whether or not one is running in the LV Dev Environment or in a compiled application under the Run-Time Engine.  

Configuring Conditions for Conditional Disable Structures - NI

Is this a LabVIEW bug? or by-design?   It seems to make logic using the RUN_TIME_ENGINE flag useless from PPLs.  (Note, I am using LabVIEW 2023 Q3 64-bit)

---

Fiddling with this atm.

The conditional disabled case doesn't (can't) change after a compile. So the fact it's always the same is expected.

When it's compiled, it's unclear if it's run time engine or not. For an exe, this is clear: the result will always run in the RTE. But PPLs can be used in the development environment.

So, I think it's just a choice.

However, I'd like a condition to switch between code compiled in a ppl and code in a vilib.

In my use case I can't use the case structure. I want a dynamically loaded DLL in development of the vilib, so I can actually compile the DLL. When I build the PPL, I'd like a static link to the DLL so the DLL is copied to the PPL, and included in executables that use the PPL.

That trick does work when compiling an exe, but not for a PPL.

The case solution doesn't change what is compiled, so that won't work in this situation.

Adding the DLL to the build spec doesn't work, as to compile the DLL it is deleted, and the build spec automatically removes it...

I just can't win...

EDIT: I can win! I can make my own conditional symbol, and use a pre-build action to set it when building a PPL (and reset it in a post build action). *sigh*