Insert Conditional Disable Structure around Call Library Nodes

[ThomasGutzler]

Before I reinvent the wheel, has anyone done this?
I'd like a VI that goes through a block diagram of another VI and places conditional disable structures around any call library node, sets the condition to bitness==32 and Default, duplicates the case, sets the condition of the new case to bitness==64 and changes the path of the called library from path/filename.ext to path/filename_64.ext or similar or something that gets passed in as a parameter.

 

Optionally, there could be a check if a CD structure already exists, if a path is wired to the CLN, what bitness we're currently on (and change above behaviour), etc. etc. but let's start simple

[smithd]

The way I've seen this done typically is to configure the path in on the diagram, and to use a separate (inlined) VI to store this path. The performance difference between hardcoded (in the node) and a path on the diagram is pretty minimal. It also makes it easy to update later on.

 

That having been said there are certain patterns hardcoded into labview. Seems like the easier route is to use the wildcard options:

http://zone.ni.com/reference/en-XX/help/371361H-01/lvexcodeconcepts/configuring_the_clf_node/#Configuring_Library_Name_or_Path

The one in your post would be Filename**.*

[JackDunaway]

configure the path in on the diagram, and to use a separate (inlined) VI to store this path.

 

Having (exhaustively?) tested combinations, I have found this strategy the least of evils. My heuristics for optimization (perhaps relevant for you, perhaps not): cross-platform distribution and developer design-time woe-minimization. As for performance, the price in run-time microseconds -- a pinch on a modern desktop, a dash on LinuxRT.

 

The idea of a scripting VI to do this automatically is super-neato in theory, but probably not practical further than advancing your own meta-programming ability, simultaneously tempering and battle-hardening your temptation to write/trust code that modifies code you maintain. 

[ThomasGutzler]

The way I've seen this done typically is to configure the path in on the diagram, and to use a separate (inlined) VI to store this path.

 

Having (exhaustively?) tested combinations, I have found this strategy the least of evils.

 

I like that, but it really just redefines the function of my scripting VI to: put the vi that contains the paths for different bitnesses on the BD and wire it up to every CLN (after enabling "specify path on BD").

 

The idea of a scripting VI to do this automatically is super-neato in theory, but probably not practical further than advancing your own meta-programming ability, simultaneously tempering and battle-hardening your temptation to write/trust code that modifies code you maintain.  

 

I think this is such a simple task that it must be able to get it right enough to be trusted almost blindly. With my original design, you'd get immediate broken arrows for trying to call libraries of the wrong bitness or incorrect path.

When providing the path via input, those checks don't happen until runtime.

 

This scripting vi was supposed to save time and keep me sane when I have a library with tens or hundreds of CLNs. I'm quite willing to let a script do the first run and then spend a smallish amount of time to fix up the bugs afterwards - as long as I don't have to repeat the same 4 steps a hundred times.

[Yair]

I have code (which I can't share) for batch processing VIs which call the function from a DLL and do a bunch of operations on each. I don't do the specific changes you want, but the concept is the same.

 

Some relevant points:

1. As Jack mentioned, this can be problematic, at least if you also have to start adding the code which you mention in the end of your original reply. I didn't, so this code can only be run after generating the wrappers.
2. Keep in mind that you might want some VIs which don't get this treatment.
3. To do the wrapping, you should create a disable structure, select everything on the diagram (my suggestion - exclude all ControlTerminals) and then call the EncloseSelection method on the VI's diagram (give the created structure as the EnclosureType) and delete the original structure. You can then probably use the properties to set the conditions.