Our company does a number of products, and would like to cut down time when working with the SDK. I am almost pleased with the import wizard in 2012, but I would like a few things changed. I have all the code ready to modify the output from the import DLL wizard with the scripting module, but if I could have it automatically generate and run the whole thing (possibly through a command line post-build instruction in Visual Studio), that would save some hassle.
It's not a big deal. I just wanted to speed up the process a little, since our SDK format doesn't change. We had a custom VI generator for our SDKs before, but it gets 95% of the way there, and the wizard does everything we missed and gets about 95% of the way there as well. That, or I could try to convince my coworkers to accept the output from the wizard.
Solved! Go to Solution.
It's probably possible - have you already looked through C:\Program Files (x86)\National Instruments\LabVIEW 2012\resource\importtools\sharedlib ? (adjust as appropriate for your LabVIEW version) It appears that all the VIs are there, although they're password-protected and not documented. Still, you might be able to figure out which ones to call. Try asking on LAVA as well.
Since the SDK was already released it is probably not an option anymore, but you can certainly increase the chances for the import library wizard to do a good job by choosing standard API parameters. Basically this means to only use skalars (passed by value or reference), C strings and simple arrays. Never use structs that contain arrays (both fixed size or not). Structs only containing skalars are fine though, but don't create structosaurusses, the C equivalent of clustersaurusses in LabVIEW, big unwieldy structs/clusters.
Then you have to review all the VIs that use output array or string buffers to let the called function write into, to make sure they are preallocated to a reasonable size for the used function.
Thanks nathand! Those look like what I needed. I'll ask for a little clarification on LAVA.
Thanks for the tips, rolfk. We already have code to manage structs and array preallocation. I didn't get a say in what did and didn't go in structs up until now, so I'll keep that in mind for future work.
You're right, the VI's in the SDK that already went out should not change (more than cosmetically that is). That being said, we occasionally add to the SDK, and this should help with future products.
For anyone else looking to do the same thing, there already is a thread about this sort of thing on LAVA, which basically says you'd be better off doing it by hand because it would take a lot of hack work. I guess I'll write a Sikuli script to automate the unofficial builds of SDKs.