I’m a big fan of JKI VIPM, and I’ve been usen Source code control with labview for some years (First with mercurial and now with GIT). Following the good practices with SCC and LabVIEW I always check the separate compiled code from vi to avoid unwanted changes on Vis.
In the other hand I’ve read that the performance of labview is better with the compiled code in the VI. Besides that the labview IDE does not allow you clear compiled cache of some of your vis, you have to delete all the compiled cache…When I have some compilation errors and I delete the compiled cache It takes a lot of time to open again the project…
My question is… VIPM allows you to execute some code after the package installation (post-installation-action). Could it be a good idea to unmark the separate compiled code programmatically on each installed file (vi, ctl, class, lvlib… )?.
Maybe I have to make this question in VIPM forums also, to check when is executed that post-installation-action, if it is executed before or after the masscompiling
Who uses Git Submodules? I know Greg Payne does and have watched his talk, but does anyone else have experience. I'm especially interested in experience with projects with multiple developers and multiple products (that might need to use different versions of the subprojects).
By Francois Normandin
As I've reported in the UI Tools support page, I've started migrating the open source code I still have on bitbucket (Mercurial-based repos) to Github.
I didn't think that it might be worth a specific topic until @LogMAN mentioned it. Personally, I'm moving my code to Github in the process. I know there are some reports of Hg-to-Git transitions not going so well when using sub-repositories, so please share your migration experience if you've had to jump into some hoops to get it done!
For all of you who still use Mercurial and host your open source and/or enterprise repos on Bitbucket, this blog post is worth reading:
By The Q
The QControl Toolkit by Q Software Innovations is an object-oriented and extensible alternative to XControls. Use the QControl Toolkit framework and the QControl Creation Wizard to create QControl Classes and receive the benefits of XControls without the headaches. Take advantage of easy UI logic code reuse. Encapsulate and decouple the UI logic away from the business logic of the main application and from the UI skin. Use wherever the VI Server and LabVIEW object-oriented programming are allowed. Easily extend the capabilities of current LabVIEW controls through access to all properties available at run time. And easily use the toolkit with more complex frameworks like the Actor Framework or other plugin architectures where LabVIEW libraries and packed project libraries are used and where XControls can behave unpredictably.
Check it out now on the NI Tools Network here.
I also started a thread on the NI Community: UI Interest Group page, here.
I use SVN for version control in my project and am often faced with many conflicted VIs that must be dealt with. I have found that frequently, the changes causing these conflicts are not "real" changes (for example, a wire was moved or a typedef for a cluster control was changed). So, I am trying to create a tool that queries my project directory for any VIs that have conflicts, and running the VI Comparison tool with only non-cosmetic changes enabled to automatically find VIs that don't have any "real" changes and marked the conflicts as resolved. I would like to build the tool into a .exe because I would like to be able to run this tool from the command-line so that I can create a right-click menu item in my Windows environment to easily run the tool from any folder containing conflicted files.
I found vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi which performs the comparison operation, allows me to specify which types of changes to detect, and returns if there are differences. This is exactly what I need and it works perfectly in the development environment. However, when I build my tool to a .exe file, I get a LabVIEW error with the following description:
Error 1574 occurred at Open VI Reference in SCCSup Compare Two VIs.vi->Resolve False Conflicts.vi Possible reason(s): LabVIEW: (Hex 0x626) Cannot open a file with separated compiled code in the LabVIEW Run-Time Engine. An error occurred loading VI 'my.vi'. LabVIEW load error code 59: The source file's compiled code has been separated, and this version of LabVIEW does not have access to separated Where my.vi is the path to the VI that it is attempting to compare. All of the VIs in my project have "Separate compiled code" enabled since I use version control on them, therefore turning it off it not an option. Is there any way to get around this issue?