The latest post from NI News promotes the use of the quick drop feature in LabVIEW. I’m not a big user of quick drop since I loathe switching between two-handed typing and one-handed typing/mousing positions (and yes I realize I could set up one-handed short-cuts, but I’m really not that fast anyway). There is one use, however, that I find invaluable when working on projects that include dozens or hundreds (or thousands) of VIs. The quick drop search includes more than just what’s in vi.lib, VIs that are included in your project explicitly as well as those that appear as a dependency are returned as well. This significantly reduces the amount of time I spend searching through the project for a specific type def or FGV call. And now you know!
I’m excited to announce that I’ll be teaching ELEC 460/860 (LabVIEW Programming) at the University of Nebraska in the fall term of 2014. It’s been a while since I last taught in a university setting, but I’m eager to work with engineering students again.
Maybe this has happened to you: you’ve created several LabVIEW classes, monkeyed around with the class properties (inheritance, perhaps), and then, seemingly out of nowhere, one of your classes is now locked. LabVIEW will claim:
The library is locked for the following reason(s): This LabVIEW class is loaded in multiple application instances. Classes must be in only a single application instance to be edited.
Nonsense. You’ve never used this class anywhere else! Before you start wondering if you suffer from multiple personality disorder, try this little trick:
- Open up the relevant LabVIEW project and navigate to the class in question. Notice the key icon beside the class name.
- In Windows Explorer, navigate to the offending .lvclass file.
- Open the .lvclass file.
- Save everything.
- Notice how the key went away? Good.