LabVIEW Idea Exchange

After building an application:

Show path to my built application folder but also provide a clickable link to open the folder quickly in Explorer so that I may test my application.

When working with Events, the inability to resize the window for choosing new events and editing existing events is really annoying.

Every single time I need to create a "Value Change" Event, I need to scroll down.  I invested in a 24" monitor so that I wouldn't need to scroll as much.

Please please let us resize this window......

Shane.

This idea is about a new LabVIEW feature, the Packed Project Library.

To statically use a packed library as a dependency, you need to add the library to the LabVIEW project.  After that's done, all the callers link to the packed library.  If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.

But what happens if you're a packed library user and developer of the same library.  You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.

If you're a user and developer, it makes sense (to me) to maintain two separate projects.  One manages the packed library resource, one manages the application.

What if there were a way to revert the packed library to the LabVIEW library from the same project?  You could use the spiral development model and simply switch between the two types of libraries during development.  You could also (and this IMHO is the most important part) incrementally deploy and test the project.  If you're strictly a packed library developer, hopefully you're incrementally testing anyway.

My final pain point with the packed library is with respect to upgrading the application.  Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade.  If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp.  Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself.  I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).

This leads me to a best-practice for lvlibp: always use them as dynamic dependencies.  That way, you can maintain and develop the packed library in the same project that uses the packed library.  You'll simply reference the resources differently.

Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.

Thanks!

Steve