In VIPM, after packages are installed, we want to perform a couple of tasks:

1. The first task is the new feature, so I can’t talk about it yet.  Let’s pretend it’s called Fragmenting Whetstones.
2. The second task is to refresh the LabVIEW palettes.

The order of these operations is important, and we want to refresh the palettes even if whetstone fragmentation produces an error.  But the “default” way of chaining errors in LabVIEW doesn’t produce this behavior.

The Problem: Chaining errors prevents execution when errors occur

In LabVIEW, we typically “chain” the error clusters of a sequence of calls to functions or subVIs. This is generally good practice for a couple of reasons:

1. It makes the dataflow order of execution clear, enhancing readability.
2. Downstream operations don’t execute if an upstream error occurs, which is typically what we want.

In this case, however, we want the tasks to execute in order but we also want Critical Task B (Refresh Palettes) to always execute.  And above all, we want to make sure that if an error does occur, we don’t lose that error out information.

The Solution: Clear and merge errors so that all nodes execute and all errors are captured

The solution is to use Clear Errors to make sure that there is no error flowing into any task.  Then, we call Merge Errors to merge each of the tasks’ errors, giving priority to the upstream error and upstream tasks (Merge Errors gives priority to errors on its inputs from top to bottom).

Hopefully, in VIPM 2010 you won’t actually see the results of this tip (an error dialog) — I’m going to work hard to make sure we get all the bugs out of the new Whetstone Fragmenter before any customers see it .

Sometimes, you might want to keep the resize window handle, such as cases where you use panes to create a status bar at the bottom of the window, as we do with VIPM (shown below).

While there’s no obvious way to do this in LabVIEW, you can use an image decoration (an image of the resize window handle) to achieve the effect.

To see an example, download this VI (LabVIEW 8.2 or greater): Show Resize Window.vi (zipped)

The engineers at Endevo have put together a great video that shows how to use their UML Modeller with the JKI State Machine:

Click here to watch it.

And don’t forget, the JKI State Machine is a free tool from JKI Software.  You can always learn more about it at jkisoft.com, or install it in just a few clicks using VI Package Manager™.

That’s why I create a one-click build VI for every project.

The idea of a one-click build VI is that anyone should be able to check my code out of SVN, open build.vi, hit Run, and build the application (or the VI Package, or whatever).

Example One-Click Build VI (Front Panel)

Some smart people whose work I respect are big on this, and a one-click build VI offers several immediate advantages as soon as you start using it:

1. It helps you document your build process,
2. It makes it easy to build early and build often, and
3. It lays the foundation for other good software engineering techniques.

I’m going to elaborate on each of these items, and then at the end I’ll show you how easy it is to get started with your own one-click build VI.

1) It helps you document your build process

For complicated applications that have multiple, separate pieces, an automated build is essential.  But even for small projects, the cycle of releasing an application can be surprisingly long:

1. Build the EXE.  …and wait for it to finish.
2. Build the Installer.   …and wait for it to finish.
3. Find the installer on disk and zip it up.  What’s the convention I use for naming the ZIP?  Oh, yeah, I remember.
4. Upload the installer to the FTP site.  What directory does it go in?  Oh, there it is.
5. Copy the installer ZIP to the archives. Where are those archives again?
6. Commit the project file to SVN, because the build process modified it.  Did I do that already?  Maybe after #2?  I don’t remember.  Oh, OK, I already did that.
   

The point is that even for simple applications, this process is long and error-prone, and you should write it down so you do it exactly the same way every time (because you’re a good engineer, and you care about repeatability).  So if you need to write it down anyway, why not write it in code?  Then, those 6 steps above collapse to

1. Open build.vi and click Run.

That makes it easy for you to build your app whenever you feel like it.  How about over lunch?  Or when you leave your desk every night?  Or during that otherwise time-wasting meeting with your boss?

Not only that, when you use a one-click build VI, anyone can build your app exactly the same way.  It decreases the amount of tribal knowledge in your organization, because the build process is captured in the code, even if code itself is terrible (have you considered the JKI State Machine?).  Decreasing tribal knowledge is important because you might get hit by a bus.  Don’t laugh, it happens.

Example One-Click Build VI (Block Diagram)

2) It makes it easy to build early and build often

If your build process is easy, you’ll want to build your application.  Or looking at it another way, if your build process isn’t easy, you won’t want to build your application.  We already know that it’s a good habit to build your EXE on day one, and keep it working.  But building is a mental context switch, and it takes you away from whatever other really important stuff you’re doing.  That’s why the act of building your EXE should be so trivial that it’s kind of fun.  Opening build.vi and clicking Run is pretty fun, as far as crummy, repetitive tasks go.

3) It lays the foundation for other good software engineering techniques

A one-click build VI is a type of automated build.  And an automated build is a core piece of a successful continuous integration system.  But continuous integration isn’t just for big companies with big products.  Imagine if you had a one-click build VI for your project, and you set it up to run every night at midnight.  Then you could come to work every morning, and a shiny, brand-new build of your current app would be waiting for you to test.  Or, if the build is broken, you’d know it immediately.  This allows you to have trust in your system, and in your software, throughout the development cycle.

OK, so how do I make a one-click build VI for myself?

The VI you see above is a typical one-click build VI for a project with an EXE and installer, built using NI’s application builder in LabVIEW.  It also includes some ancillary features, like zipping up the installer, making some changes to the project file XML, and committing the modified project file to SVN.  It incorporates some switches so I can enable & disable some of these features as required.

But you don’t have to go to that level of detail to get started with a one-click build.  NI gives you everything you need:

BuildTargetBuildSpecification.vi from vi.lib

The VI highlighted above is located on your system at <LabVIEW>\vi.lib\AppBuilder\BuildTargetBuildSpecification.vi.  NI has a couple of reference pages on the topic here and here.  You pass it your EXE and/or installer build scripts as shown, and in seconds you’ll be on your way to forgetting everything about how to build your customers’ applications, just like I have.

In the future, I’m going to talk more about specific ways you can use a one-click build VI in your projects.  In fact, I’ll probably write those articles while a one-click build is running in the background!

Very soon, you’ll be able to access VI Tester directly from the LabVIEW project toolbar.

By clicking on toolbar buttons you’ll be able to run all your project’s unit tests, as well as add new Test Cases and Test Suites without leaving the project window.

Here’s a short video showing a development version of the VI Tester’s LabVIEW Project Explorer toolbar in action:

All this is made possible by NI’s growing openness to providing LabVIEW developers with ways to plug into and extend LabVIEW.  We are very excited about this trend and are learning more every day about new ways to plug into LabVIEW.  Expect to see better integration with LabVIEW for more JKI tools, such as VIPM, in the near future.

Note: this would be similar to how we can refresh the palette menus programmatically by invoking the Application:Refresh Palettes method (shown below).

I bring this up, because one feature that I’d love to see added to VIPM (some day) is an easier way to build menu-launch tools into VI Packages, and I’m sure more people would be asking us why their add-on doesn’t show up in LabVIEW after it’s installed.

Hopefully, we can help NI get this feature onto the LabVIEW roadmap by convincing them that it’s worthwhile.