Leaderboard

Please see the above link to download the videos The NIWeek 2016 Videos are uploaded to the ftp server. Please see this link for information on downloading the videos. https://lavag.org/topic/19154-ni-week-2015-videos/#comment-115444

I think the lack of feedback is caused by general confusion about the status quo. I'm sure many people still use the library, though there haven't been any update since 2011: https://sourceforge.net/projects/opengtoolkit/ <= Also that is the right spot for your changes The project is open source, so if you are really committed to get involved, this is what I think you should do: 1. Contact the admins over at SourceForge to either merge your changes or grant you write access. 2. In case you get no reply within say... one or two month, consider the project abandoned and fork it. (you are not limited to SourceForge, use the platform that is to your liking) I think there are a couple of people here at LavaG that would participate in the project if someone would just start being active and committed to the project again.

A power failure crashed my LabVIEW before I pushed some important work to the repository. Recover seemed to work yet I got a message saying that the vi can't be saved and it was actually corrupted: "Cannot load diagram of "....vi"" and the only option is "cancel save". Regular cut and paste tricks didn't work and before starting to go over the Hex code I tried something that I didn't see anyone write about and it worked so here it goes for those future corruption fighters (I can't promise it will work each time though): The VI was written in LV 2011. I tried opening a new vi by using the still opened corrupted vi as a template. It didn't work. I moved up to LV 2013 and it still didn't work. Trying the same with LV 2014 did the magic. All that was left to do is to save to previous version (LV 2011) and correct the file's location and name. Done.

That's great! One other thing you might try - I think the build process should also work if the Conditional structure default case was "empty path" and that the "Linux" path was as you coded it - in that case it avoids the unnecessary hardcoded path to the .SO file in the unsupported cases (non-Linux). I think the code will still open as 'non-broken' if open on a Linux target context (as it should be) and it will open broken on a Windows context (as it should be). Its probably best that the code is broken when opened in an unsupported context - because its better to break at development time than at run-time in this scenario.

I would check the "specify path on diagram" and try passing the path into the CLFN node and use a conditional disable structure to pass in the extension (or hard code it to only support Linux targets). Best practice would be to create a subVI with the constant so that you use the same path for all instances.

The command line option only works if you know no other versions of LabVIEW are currently open. LabVIEW communicates over DDE to other versions of LabVIEW, and that is why some times you'll see LabVIEW try to open the wrong VI in the wrong version. If you double click a VI, or open it over the command line, it may choose to open it in the wrong version even if the command line specified which version to open it with. Here is a post I made on it a while ago and many other applications (like VIPM launching LabVIEW, and LabVIEW version selection tools) suffer from this issue. The work around is using the technique I've mentioned. But if you can ensure no versions of LabVIEW are running, maybe by closing them all, making a VI that runs when opened is much easier.