However, in LabVIEW 2009 this no longer works.  But, there’s still hope.  It turns out that LabVIEW 2009 EXEs are basically just ZIP archives.

And, you can list the contents of LabVIEW 2009 EXE files, programmatically, using the OpenG Zip Tools library, as shown below:

Note: The image above is a VI Snippet and you can just drag & drop it into a LabVIEW 2009 block diagram (but, make sure to install the OpenG Zip Tools first). Or, download the VI File, here: List LV2009 EXE File Contents.vi

Voilà! Problem solved

I definitely couldn’t live without these handy VIs.

For more information, check out the official announcement on the JKI Software Blog.

I’m thankful that NI is giving users ways to communicate ideas for how to improve LabVIEW, and I’m certain that this will really help in giving users a voice about pain points in LabVIEW that might not be readily apparent to NI.  This is yet another example (here are a couple more) of how NI is working hard to open up LabVIEW and let the community participate in making LabVIEW better.

Kudos to NI and the great feature ideas that are already showing up on this powerful, new community tool.

I’m going to be presenting tomorrow, at the LabVIEW Developer Day in Boston (Chelmsford).

I’m going to be discussing LabVIEW Code Reuse in the Enterprise and demonstrating some of the new Enterprise Package Repository Management features that are coming soon in the next release of VI Package Manager.

If you’re able to make it, I look forward to seeing you there.

• Announcing the JKI Right-Click Framework for LabVIEW

I’ve already created a few new right-click menu features and it’s really fun and easy.

If you’re going to be in the San Francisco Bay Area next Wednesday evening (February 18th, 2009 at at 6pm), then be sure to come to the LabVIEW User Group Meeting at the NI Mountain View office.

I’ll be giving a demo of JKI’s new VI Tester and talking about ways to improve your software quality via unit testing. 

For more details, see the meeting agenda page.

I hope to see you there!

Over the years that I’ve been blogging here at Thinking in G, many of my posts have related to the software products of JKI, such as VIPM, EasyXML, and the JKI State Machine.  But, from now on, I’m going to be posting JKI-related articles on the JKI Software Blog.

The goal of this change is to:

1. draw a more clear line between my own personal thoughts on LabVIEW and the messages coming from JKI, and
2. encourage other JKI team members to post articles (on the JKI Software Blog) that relate to JKI and LabVIEW.

Hopefully, this means more great articles about LabVIEW for all of you.  I know for a fact that the JKI team has a LOT of great stuff planned for 2009, so stay tuned in to the JKI Software Blog.

For more information about the JKI Software Blog, visit blog.jkisoft.com.

So, how do you deal with all the unsaved VIs in your project that are not in an area that you “own”?  If you don’t save them, then LabVIEW will keep bugging you to save the VIs.  And, sometimes your LabVIEW code will even run slower until you save all your VIs.  But, if you do save these VIs, then it’s hard to tell which VIs that you’ve saved have “real” changes and not just recompile changes.  And, if you commit all the changed VIs, then you might increase the likelihood of creating a conflict with other developers.

Here’s a good process you can follow to deal with this issue:

1. First, commit your real changes, separate from the recompile changes.  This will give you a specific svn revision (changeset) associated with your real changes.
2. Then, save all the recompiled VIs and commit them.  For your commit log message, use “Recompiled due to typedef changes” (or similar).  This will indicate to other developers that the changes can be ignored, in the event that this revision conflicts with their own changes.
3. Finally, Alert your team that you have committed a recompile of code (with no real changes).  They can then easily resolve any conflicts, because they know that the commit contains no real changes.

Now, if you know that other team members are actively working on the code and you don’t want to inconvenience them with having to deal with conflicts, you can defer the recompile until a later time or schedule a time for the recompile with your team.

Note: Even if you use a locking system (such as svn locks or a check-in/check-out SCC model) where files for which you don’t have the lock are read-only, you will still have the slow-down issue and will periodically want to do save all to recompile.

Have you had this issue?  What solution or process do you use?

This tool is the direct result of putting some of the best LabVIEW minds together for several years, tasked with the challenge of creating a LabVIEW architectural design pattern that would allow easy coding, readability, and maintenance.  As you might imagine the JKI team has created something truly special that we hope will have a significant impact on LabVIEW users everywhere.

This has been in the works for quite some time and we’re excited that the time has finally come to share this tool with you, now.

Please take this challenge:

1. Download and install the JKI State Machine.
2. Watch this great video tutorial.
3. Take a look at how we refactored the 3-button dialog (VI that ships with LabVIEW) using the JKI State Machine.
4. Tell us what you think.

For example, if you were a miner looking for precious minerals, you would wouldn’t roam the countryside digging random holes in the ground.  Rather, you would work smart — you would try to identify a geographic location with a very high natural concentration of precious minerals (based on a variety of clues).  Guess what?  This is exactly how you should mine for reusable code in your past projects.  But, where do you start looking and what are the clues that will lead you to those reuse gems?

Here’s the secret:

While writing code, when you identify that you are writing a VI that is generic and has the potential to be reused, save it inside a sub-folder of your project folder called “Reusable VIs”.

If you adhere to this strategy, it will be very easy for you to come back later and find your reuse gems.  And, before you know it, you will have what resembles a reuse library.  Best of all, you didn’t even have to get your hands too dirty.

Note: As your reuse library grows (which it will if you use the planning techniques described above), you’ll need to start thinking about how to utilize your reuse library on multiple projects and share these VIs with other developers.  Make sure you don’t get stuck in the pitfalls of a monolithic reuse library caused by copying your reuse library from project to project or by using the same version of your reuse library on each project.  Create a VI Package and install your reuse library in your palettes using VIPM — it’s easy and simple.

I’d love to hear your feedback, so please feel free to leave a comment.  For example:

• Do you have a folder in your project where you put new, reusable VIs?
• Do you think that this is a good idea, or do you have a better strategy?