LabVIEW Idea Exchange

When using the Rearrange Cases window with a Type Specialization Structure, the case list only shows either Declined, Accepted or Ignored. This makes it difficult to know what cases are being reordered. Similar situations occur with a numeric case selector (just a list of numbers) and event cases (dynamic events with the duplicate default wire labels).

This idea is to add the subdiagram label of a case next to each entry in the case list. This would add some context to each item, and make rearranging cases quicker and less error prone.

Alternately (or in addition to the above) would be the ability to preview the contents of the selected case / subdiagram, much like the preview when selecting a dynamic dispatch VI in a class hierarchy. This would be useful for cases with no subdiagram label, or in the case of the type specialization structure, allow visual comparisons of which case should be evaluated in which order.

History probes are a very useful tool in LabVIEW. However, one improvement can be made to them when working with enums. Currently, the values in enum history probes are returned as numbers, as shown in the picture below:

It would even be more useful if enum history probes returned values in terms of the enum item names rather than the numeric values associated with them, as shown in the picture below.

The problem that height of local variable is 17 pix, and terminal - 16 pix, but distance between terminals in unbundle function is 15 pix.

As result - aligning to vertical compress caused steps in wires:

Right nowterminals/local variables should be slighly overlapped for "step edge free" wiring.

Please synchronize size of these icons with distance between terminals (to 16 pixels - seems to be ideal size)

Not sure if it was already in Idea Exchange or not.

Andrey.

Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:

AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!

We need this:

 Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.

 As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

Currently the fastest way to insert a Bundle By Name node into an existing cluster wire is to use the QuickDrop Ctrl + I shortcut.

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing cluster wire would be even quicker.

Notes

• Inserting BBN nodes is a common, repetitive action when working with clusters. For example, when working inside the Message Handling Loop of a DQMH module.
• The gesture should work for class wires too, but only if access scope rules allow it.
• This idea is very much related to the "New gesture to create Unbundle By Name node (Ctrl + double-click when creating a cluster wire branch)". The difference is that this idea addresses inserting BBN nodes into existing wires. That idea addresses more easily terminating a new wire branch with a UBN or BBN node.

Thanks

Currently the fastest way to open the Properties page of a front panel element (control, indicator, decoration) is right-click >> Properties.

Holding down a modifier key (Alt, Ctrl, Shift, or a combination of these) while double-clicking on the front panel element would be quicker.

Notes

• Opening the properties page of front panel elements is a common, repetitive task, especially when creating complex UIs where the size, colours, display format, data entry limits need to be changed.
• Ideally the gesture would work on block diagram terminals too.
• This idea is very similar to New keyboard shortcut: Alt + double-click to open Properties in Project Explorer. The difference is that this idea addresses opening the Properties page of front panel elements, whereas that idea addresses project items.

I don't use conditional disable structures very often...but when I do, I've always found it a bit annoying that I need to pull up the documentation in order to check what the available options are, and expected string formatting. For symbols with a defined list, why not expose these options through drop-downs?