LabVIEW Idea Exchange

Currently there is a method for setting the control value of another VI via the Control Value Set Method. But there is no set with signaling method which allows control of VI's which react to changes on front panel controls. This makes it hard to automate VI's that are using front panel control events. There is a tedious work around to get references to control on the front panel and then use value signaling method . It would be very useful to just have one additonal method that does the signaling in additon to setting the value of the control.

Currently, the only object that we have access to in an Event Structure it the control itself:

This is not what I am interested in, most of the case, when I am working on the BD.

Rather, I'd like to either find the terminal, or local variables, references, etc.

Moreover, going to the control using the above shortcut may result in a messed up FP, not mentioning cases like this:

where the control may be hidden or invisible because it is in another tab than the one currently selected.

Now, I know that some will argue that the control terminal is most of the time in the event structure (see for instance this thread)...

But read the thread's comments for counter arguments: we would be talking about the Value Change event, but this is not what I am talking aboutin general: any event for that control should give access to the control's terminal (and BTW, it could very well be an indicator) and, as for a terminal, to this list of related objects:

(The last one courtesy of this shortcut plugin)

Add a Visible Item to the cluster container to enable the display of the currently selected AutoSizing style

Similar to the other Visible Items (enabled above on "source" string & "code" integer) like

• "Radix" for a numeric integer (d-Decimal, o-Octal, x-Hex, b-Binary, p-SI Display)
• "Display Style" for a string (n-Normal, \-\ codes, x-Hexadecimal, p-Password)

For consistency with others similar above:

• also available on Block Diagram cluster constants
• Visibility only selectable in edit mode
• If Style is visible, it is changable in BOTH edit AND run modes

When the abort button is pressed, and the development environment is present, the block diagram should be shown and the portion of code that was currently executing should be hilited.

I've been wondering for years now why the LV Save (& Save All) dialog is quite unusual in terms of its layout & usability.

Redesign the "Save Changes?" dialogin accordance with the standard dialog design criteria as follows.

• Resize the dialog to be somewhat bigger than now.
• Place the Apply same action checkbox & the Affected items list at the top half of the dialog. Remove these items from the tabbing list, so the user can easily tab among the other 3 buttons, with Save highlighted by default.
• The Affected items list is not sorted properly, but in the Explain Changes dialog, it seems the VI List is alphabatically sorted. So when you select a VI in  the Affected Items list & click the "List unsaved changes..." hyperlink-like text, the selections are confusing to the user. PFB snapshot.

• Additionally, the selection in the Affected Items list is not actually a selection, but looks like only a marquee. It gives a false impression that the selected item can be edited. Fix this.
• Make the Affected Items list to be vertically scrollable, instead of the current horizontally scrollable style, which is highly cumbersome.
• Change the "List unsaved changes..." hyperlink-like text into a button that is prominently visible. New users think that this would open a web browser.
• Place the Save (All), Defer Decision / Don't Save (All) & Cancel buttons at the bottm right of the dialog in a horizontal fashion.
• Add the Help button, like in many other dialogs in LV.
• Keep the name of the dialog to be consistent - "Save changes before closing?", instead of like "Save changes? (Close Project)" - The Close Project text is misleading.