Leaderboard

Time to wipe the dust off this one. I found myself in a similar situation as the OP where I want to exclude code using Conditional Disable Structures. In my project, I have multiple Build Specs and I wanted to change the Conditional Symbols based on which Build Spec I'm running. For example, I could have a Debug and Release Spec. I know that the IfDef.llb (LV\resource\plugins\Utility\) provides a SetSymbols.vi, so my first thought was to have a Pre-Build Action which calls SetSymbols.vi to set my key-value pair. That works fine. This could turn messy if there are multiple Symbols that might need setting for different Build Specs and instead of having lots of small vis that each set a single Symbol I want something a bit more manageable. So why not allow setting of the Symbols via the Build specification description? So I made a small vi that you can drop in your Pre-Build Action.vi, which reads this text and sets any of the symbols it finds. LcExtra_IfDefSetSymbols.viLcExtra_IfDefPreBuildDropIn.vi People who don't like this idea may want to replace reading the Build specification description with reading a separate .txt file which they include in the project that contains symbols for all possible build specs. There are many ways ... Of course, if you're in any way interested in this topic, the first thing you should do is support this idea in the LabVIEW Idea Exchange, which would make all of the above obsolete.

This uses Array Point to RowCol (from the Code Repository.) This is the next Event case. This takes almost no work, which may make up for it not being exactly what you want...

\vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi seems to do what you ask for (see screenshot).

Technically there would be a way to solve this in LabVIEW for almost all instances. The Windows API has generally ANSI functions and Unicode functions for all File IO functions. If they would choose to use explicitedly the Unicode variant internally and make the LabVIEW path to Windows path function a tiny bit smarter they could have solved that years ago for all OSes since Win2K. Since Paths are in LabVIEW a distinct datatype the entire modification could have been done transparently for LabVIEW diagrams without compatibility problems. Why they didn't do it back in LabVIEW 8.0 when they modified all file functions to work with 64 bit file offsets to allow for file access for files <2GB is still not clear to me. It would have been an invasive chance in the LabVIEW source code only with almost no chance for any negative influences for LabVIEW applications. Changing the File functions to use Unicode paths internally would IMHO have been a less involved exercise than supporting 64 bit file offsets throughout. Not to say that 64 bit offsets are not important (they are) but allowing paths to go beyond 260 characters is also a pretty important feature nowadays (and would have been a great opportunity to support 10 years ago when this generally wasn't a real issue for most computer installations).

The Project Provider Framework is an API provided by LabVIEW that has minimal support from NI. This API can be used to create new types of project items, add new menu items, and other stuff like that. They only share documentation about the API with those who apply to be partners, however, and there is a signature mechanism to enforce this. Well I've figured out how that signature is generated, so hopefully the LAVA community can do some cool stuff with this! I haven't really played around with it at all, but I plan to. Each plugin is defined by an INI file, located in resource\Framework\Providers\GProviders. Each INI file has a Signature key, which is required to be valid in order for LabVIEW to load the plugin. To generate this signature, first you need to concatenate all the values (not the keys) in the INI file. Only string values though, not numeric or Boolean ones. I'll use GOOP_MyComputer.ini from OpenGDS as an example: [Provider] SupportedType={CEFE1B10-1732-4678-A70A-299293455410} IsPrimary=0 ItemInterfaceVI=..\Open_GDS\GOOP_MyComputer_Item_Interface.vi CreateNewWizardInterfaceVI=..\Open_GDS\GOOP_MyComputer_CreateNewWizard_Interface.vi CreateNewWizardHost=Source LicenseName=None InterfaceVersion=1.0 Signature=KS5CBT93T9SSJK3SNWB239RLN95WTC9W Ignore the Signature line as well, of course. The concatenated string here will be "{CEFE1B10-1732-4678-A70A-299293455410}..\Open_GDS\GOOP_MyComputer_Item_Interface.vi..\Open_GDS\GOOP_MyComputer_CreateNewWizard_Interface.viSourceNone1.0". Take the MD5 hash of this string. In this case, the hash is "8423091770884C816AF971DB7A632067". The next step is to apply a simple substitution cipher to the MD5 hash: 0123456789ABCDEF T3C5K7W9SBNRJLX2 Just replace the character on the top with the one under it. So the new string will be "SKC5TB399TSSKJS3WN2B93LR9NW5CTW9". One more step! For each pair of characters, i.e. "SK", "C5", "TB", ..., switch the two characters. In this case you'll have "KS5CBT93T9SSJK3SNWB239RLN95WTC9W". And look! That's the signature in the INI file! I've attached a VI that does this for you, minus the step of concatenating the INI values. Just pass the VI a string and it will output the signature. Enjoy, but keep in mind the usual warning about using unreleased features of LabVIEW: don't use it for anything too high-stakes. Generate PPF Signature.vi EDIT: To make this process easier, I have also written a C# program that will automatically sign an INI file for you. Just drag and drop the INI file onto the EXE, or use the command line to specify an output filename as well. Both the source code and EXE are included here. SignPPFPlugin.zip Also, here's some palette files for the PPF's API VI's. Since they won't all fit on one page, I did some very simple categorization, simply creating separate menus for "Get" functions, "Set" functions, and one for all the others. Extract the ZIP file to menus\Categories\Addons, and then just put it in your palette from the palette editor. PPF Menus.zip Finally, here's a tool that will automatically generate the interface VI's for you. I found it annoying to always have to update them. Basically they're just VI's that output a cluster with a bunch of paths to "method VI's", which are basically the PPF equivalent to XNode ability VI's. So this will just search for method VI's in the same folder, and generate an interface VI for you through scripting. I called it "PPF Assistant" in case I ever decide to add stuff to it for other PPF-related tasks. This requires OpenG, as well as gb119's Scripting Tools. PPF Assistant.zip EDIT2: Looks like the PPF was recently officially made public (though still not supported) including NI's official INI signing tool. Glad my thread here could be of assistance to the people having trouble with that tool!

Maybe a (meta)quote from the Big Lebowski might help:: "They treat objects like women, man..."