Leaderboard

Since someone else will beat me to the punch if I try and wait for the software to be posted...here's the link to the LabVIEW 2012 beta announcement post at ni.com. Go ahead. You know you want to.

Congratulations to the incoming freshman class of LabVIEW Champions! Once a year, new members are inducted into the Champions programme, and this year's 9 new members represent a high calibre group of individuals from all over the world. I'm also proud that many of the Champions (if not all?) are leading members of the LAVA, and have shaped, and are shaped, by our community. Congratulations!

Thanks Crelf. It's definitely an international intake for oh-twelve. I am very excited to have been included in the same group as some leading Community members. Oh yes, and... ...Go LAVA

Both? Sheesh!

Well, I am pretty sure it is a simple class not in memory problem. Pity LabVIEW didn't offer that in the error message in the first place. Anyway, getting the classes loaded seemed trickier than I thought it would be. So maybe there is a better way? My solution was to add a pre-build action to store the relative paths to the worker classes. Then the application can use that information to dynamically load all of the worker classes before it does anything else. Pre-Build Action: Changes to top level vi:

A bit of a side note, but if you have a DLL that is not thread-safe, you can still configure it to be called in any thread so long as you ensure yourself that it cannot be called multiple times in parallel. The easiest way to do that is to wrap it in a VI that isn't reentrant.

Thanks to Ton's efforts the Code Capture Tool is now Compatible with LabVIEW - or as we like to say CwLV Just fire up your copy of VIPM to download it straight from the... View the full article

A (perhaps) better solution is to release them on the NI's Instrument Driver Network. Then the source code is out there and available for anyone else to use/improve.