Leaderboard

Hi all, I'd like to introduce LQ Widgets, a library to bring advanced GUI features to LabVIEW. It is powered by the Qt toolkit plus the Qwt library (Qt Widgets for Technical Applications). This library consists of two major subcomponents that might interest LabVIEW users: A GUI framework that is powerful, flexible, and comprehensive (see demos below). A event-driven, intra-process communications framework. You can establish connections using (i) LabVIEW user events, (ii) callback VIs, or (iii) string specifications. Here it is in action: Why a GUI library? The Idea Exchange has many, many posts about improving LabVIEW's GUI capabilities. However, we likely have to wait several years at least before these wishes are granted (see AristosQueue's post at http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-updating-the-GUI-a-priority-in-a-near-term-LabVIEW-release/idc-p/2710511#M26394). The required technologies are actually available right now. In fact, they have been available for many years. All we need is a way to access them easily from LabVIEW. LQ Widgets aims to provide this access. Why yet another communications framework? Providing a comms library wasn't part of my original goal. Nonetheless, the system used by the GUI components can also be used for non-GUI purposes, so it's here for you to try. Where to get it? Downloadable packages: Package for LabVIEW 2014 (recommended; take advantage of the the new web-based documentation) Package for LabVIEW 2013 Quick start guide at https://github.com/JKSH/LQWidgets#usage. The C++ source code is also easily accessible from here, if you're interested. EDIT: Most importantly, you must either extract the package to C:\LQWidgets\, or modify the output of src\LabVIEW\LQ Core\_Internal\Library Path.vi (thanks, mwebster!) Project roadmap See http://github.com/JKSH/LQWidgets/wiki/Roadmap Known Issues This is a pre-alpha release, which means (i) the API will likely change in the near future, (ii) the library is far from feature-complete, (iii) performance is not optimized, and (iv) you might experience crashes. Other issues include: You currently can't free any resources or disconnect signals, except by calling LQCoreEngine.lvclass:Stop Engine.vi QWinThumbnailToolButton cannot be applied to non-Qt windows, such as LabVIEW front panels After you start and stop the engine, QWinThumbnailToolButton no longer emits any signals when you click on it Workaround: Restart LabVIEW There are a few small memory leaks, which will persist until you close LabVIEW. Request for feedback What do you think of the GUI-related API? What do you think of the communications-related API? What is the single most promising aspect of this library? What is the single most frustrating aspect of this library? All comments and critique are most welcome. Thanks for your time!

Hi, I figured people here may be more interested in this project. I have some cool graph extensions I'm building in an open source project, which make some nice graphical overlays for XY graphs and waveform graphs in LabVIEW. I've got a github page where you can grab the code, support the project or just have a look at some of the same screenshots. Everything updates live in the graph, so you really need to see it, to get how it all works, so here you go: https://github.com/unipsycho/Graph-Extensions-LabVIEW Please star follow the project if you want to see this developed and I'd appreciate any feedback or ideas to extend it further. The markers are very much IN development right now, so no where near finished, but the tools can still be seen working. THANKS!

I do this slightly differently (in Project Probe). Yours might be faster if you only look at link info from the file rather than loading the hierarchy but I have to look at lots of other VI stuff that require opening the VI anyway too (like re-entrancy, debugging enabled, icon, description etc). I also use it to sort VI refnums when force compiling hierarchies. I create the file list similarly to you then I open each VI and check if it has dependencies (Get VI Dependencies Method Node). The VI opened and its dependencies are added to a [found] list. If a VI in the file list is already in the list or in memory then it doesn't need to be opened and could be considered already processed (it has a parent that was previously opened). If a VI has no parent and has no dependencies then it is an orphan. It can also find VIs in conditional disables. So I deduce if it is an orphan from the dependencies of all the VIs

Some more progress on this project I wanted to share. You can now drag out range based markers to overlay them on a graph. point and line markers are all supported as well.