LabVIEW Idea Exchange

I started using LabVIEW when it was at version 6 and have used all the interim versions. I have always found the implementation of the Alt-Tab keystroke to be irritatingly inconsistent with other Windows applications.

If we have multiple LabVIEW wnidows open, for example, Alt-Tabbing to one of them means I have Alt-Tab through ALL of them to get to the first non-LabVIEW window. This is a real menace. If we have, for example, 8 LabVIEW windows open and the Calculator, we just want to Alt-Tab between LabVIEW and Calculator: we have to tab 8 times to get to the calculator but once will get us back to LabVIEW.

This makes little sense, since Ctrl-Tab has historically been for tabbing between multiple instances of the same application. Alt-Tab should be reserved for tabbing between applications.

By contrast, if we have multiple Microsoft Word documents open, they are mixed in with the other applications on the Alt-Tab popup, so if there's one which hasn't been topmost for a long time, it gets shoved to its rightful place at the end of the list.

Looks like this has been a hot topic for a while. Still with no concusion. Does this exclude it from the product ideas forum?

Why not make Alt-Tab behave the same way as all other Windows applications, since we'll always have the Ctrl-Tab to toggle between those self-important LabVIEW windows?

Custom probes are great, however unlike the default probes you do not always have them with you...so why not just make the default probes just a tad smarter? 

- The array probe e.g. should not just show a single cell - it should by default show at least some of them (1*10 for 1D, 10*10 if 2D etc. e.g.), have it's scrollbars visible and be resizable?

 You could add some core information about the array, like it's size e.g. in an indicator on the top as well....and perhaps have a pull-down menu for the display format. Keep it general and simple of course, but a bit more convenient than today's probe.

- The string probe should also be resizable and have a control that let's you switch the display format.

- etc.

It's got to be a duplicate, but I could not find it...

A significant number of vi.lib VIs are still outputing error codes (I32) instead of an error cluster.

For instance, the famous Ramp.vi:

returns an error -20006 if you ask for zero samples. Type in this value in the "Explain Error..." window of the Help menu and you get:

So it's not that the error code is mysterious and cannot be interpreted (I must say I was a bit puzzled by this discussion on error codes).

NI has to fight with this problem themselves. For instance, here is the code you find in the NI_AALPro.lvlib:AAL Resample Filter Prototype Design.vi:

What is that "?!+Magnifier" VI , you'll ask (AAL Error Information.vi, in the same library mentioned above)? I am probably supposed not to post it, but I will nonetheless, considering what it REALLY does:

Yep, it simply returns the same numeric error code value (again) and the call chain for the VI generating the error (but it won't tell you that the real source is the DLL called in the "Kaiser" VI above). I assume (but I can't prove) that the codes returned by the analysis library are among those recognized by the Explain Error VI.

It is not only an annoyance to not be able simply connect VIs using an error cluster wire, it does not make error handling particularly easy (basically, the way I read the answers of Aristos Queue and Norbert_B in the thread I quoted above is: "reverse engineer our VIs if you really want to 1) get the complete list of error codes it can output, 2) understand their cause").

My suggestion: Hire a couple of interns to sift through NI's VI librairies and change error code outputs into error cluster outputs with proper messages.

Obviously, for compatibility reasons, open previous code with an added unbundle primitive which will return the old error code (with a list of warning after the first compilation). You've done that before and we have survived.

I have a large library of general purpose functions and I do a lot of OOP in LabVIEW, and as a result my preferred workflow involves dragging a lot of functions from the project explorer window onto the block diagram. This workflow is slowed down, however by the fact that the project explorer window is regularly hidden by other windows when I click on them.

What I would like to see is something like most development IDEs have, e.g. Visual Studio, where I can have the project explorer always visible in a fixed position on the screen. I suggest this would be an option, so would not affect those who like things the way they currently are.

It is currently possible to add space to the block diagram by drawing an area or line with the cursor while holding down Ctrl+Shift.

I often wish there was an equivalent opposite shortcut;  where you could draw how much you want the diagram to contract instead...