Leaderboard

There seems to be two aspects to this discussion. 1. An inbuilt conditional case activated for enabling/disabling user debugging code predicated on existing VI settings and finding other vi specific settings to bolster this one case. 2. An argument for adding one (or more) additional, built-in, conditional disable structure defines in the face of resistance to changing anything in the (probably fragile) codebase. If you win #2, you can do #1 but #1 is a very specific case that I certainly have no need for. However. I have another non vi specific one that I would like to see the conditional disable structure support (ammunition for #2). I would like to see a case implemented for the "LabVIEW version" since I have several pieces of code that have to determine this at run-time and use a normal case structure to switch the code.The run-time gymnastics of this is disproportionate to the simplicity of a conditional disable for this purpose. In a couple of extreme cases it has required a post-process VI to be run on the target system and scripting to make modifications. This has meant that the VIs cannot be password protected and therefore a licence cannot be attached to them (I have had to ask for an NDA).