LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

build application with conditional disabled VI's still tries to load them ...

Bump.

 

We've been struggling with this for years.  We compile on Win32, Win64, and MacOS and use conditional disable structures.  Right now I'm staring at an error list which tells me that all the NI Database VI's are broken on MacOS.  I only notice them when something else breaks and I actually click on the broken arrow (if there's broken but disabled code it doesn't lead to a broken arrow), but, what is the way we can ensure that we don't see errors on platforms where vis aren't supposed to be called?  Our current idea is to create seperate projects for different platforms and segregate platform specific code into this projects and seperate build scripts.

0 Kudos
Message 11 of 14
(527 Views)

Hi Thomas,

 

I once tried to use scripting to set conditional disables and LV made a mess of it. That was a few versions back. Just came across this bit of code from the Caraya TDD example. Hope it helps.

 

-Peter

0 Kudos
Message 12 of 14
(488 Views)

I invented a "solution" for this that was... not elegant.  It was functional, though.

 

For each VI (let's pretend it's "Original.vi") that has a conditional disable in it, create a series of VIs with names something like the following:

 

Original_SHELL.vi

Original_32BIT.vi

Original_64BIT.vi

 

All these VIs needed to have identical connection panes.

 

For all of the VIs except the one with _SHELL on it, the VI is the code but with the conditional disables removed, leaving only the bits of code matching the conditional disable matching the string appended to it.

 

Inside the _SHELL VI was just a small amount of code.  It was code to dynamically load any of the other VIs by path, and it used its own connection pane as a way to strongly type the VI reference.  It had a conditional disable structure in it, except instead of actual code that could be "broken" it just had a string constant used to construct the on-disk name of the VI matching its condition.  Then it did a call-by-reference on the appropriate VI to match the conditional disable.

 

That part of the solution worked for running code in the editor.  When it came time to build EXEs, you had to use "pre-build" and "post-build" VIs in your build.  You'd add a pre-build VI that searched the block diagrams of all of your code, and replaced any VI ending in _SHELL with one that matched the conditional disable structure that was actually in effect on your PC.  The post-build VIs changed them back.

 

...Like I said, it wasn't very elegant.

0 Kudos
Message 13 of 14
(473 Views)

Or switch to LVOOP and use dependency injection to control which code runs on which target.

 

I've started doing this on FPGA and the number of times I need to recompile for interactive debugging has dropped to nearly zero.

0 Kudos
Message 14 of 14
(466 Views)