LabVIEW Idea Exchange

Sometimes you want your front panel fixed to a particular size. Sometimes you also want to access the “Tools,” “Window,” or “Help” menus.

When you have intentionally re-sized your front panel to a specific (small) size, it’s a pain to have to resize the window or switch to a different window every time you want to access something under “Tools” or any of the other menus that are not visible. 

(Sure, I could switch to the block diagram and get to the menus from there. But if I can’t remember the keyboard shortcut to open the block diagram, I have to resize the window to get to the “Window” menu to open the block diagram.)

For example, when you make an XControl, you want to re-size the facade to fit the controls that you put on it. And then you want to keep it at that size. On the built-in Simple Dual-Mode Thermometer example, you can’t see any of the menus past “Edit” on the Facade without re-sizing the XControl.

It would be nice if an arrow or something appeared on the menu bar when the window is sized too small that I could then click on and expand to get to the menus that are not visible.

As mentioned at the end of my comment here, editing text is a bit clumsy. There should be a text toobar that is similar to what we can find in any other application.

Maybe it could be dynamic so it only appears when editing text.

Here's the quote from the other thread:

One thing that should be improved is the font pulldown which feels so early 1990's. When working with text, we want a text toolbar like anywhere else, (even in the post editor here in the forum!) with a bold, italic, etc. buttons, font and size rings, etc. You know what I mean!

Simply put, you should be able to put a URL hyperlink in a floating comment to link out to some site.

Imagine being able to add a hyperlink to the mathematical description of a VI that you used. Perhaps you have an internal server of IP Documentation. You could add a hyperlink to that in depth information directly in your VI. Perhaps you want to put your logo along with a link to your website at the top level of your source code. Whatever the reason, you need to be able to add a normal comment to the block diagram and populate that comment with text and hyperlinks.

As a extension, this new comment field could even take simple html tags for more formatting, embedding images, or maybe even an embedded video.

I am probably not alone in my trepidation in using the Block Diagram Cleanup tool, but I can not help but recognize its power to be a tremendous help.   We already have tools (Grids, Align and Distribute, Ctrl-T QD shortcut, etc.) to get Nodes and terminals positioned nicely.  Even with this idea in Beta, wiring can still be a tedious chore.  The BDCT does a reasonable job routing wires, but also moves things around including control/indicator labels, and is often unsatisfying.

What I want is to be able to lay out the BD, wire things while only worrying about beginning and end, and then have the BDCT only adjust the wire routing.

Despite numerous RCF shortcuts and new behavior in LV10, this is not the same as cleaning wires.  The solution is not to methodically select only wires and Ctrl+U.  The reason:  the process should be a global optimization, not a serial process where each wire route is chosen based on the current state of the BD.  The BDCT uses a global optimization, 'Cleaning wires' does not.  What I want is the optimization of the BDCT limited to only wires, leave my nodes and terminals and labels alone!

For example see the following:

LabVIEW 2020 32bit (English), installed on Windows 10 (French).

I have noticed some small inconsistencies in the localization and formatting of the "File Dialog" and its subdialogs.

Let's say you have a "File Dialog" express VI configured in mode "File, Existing".

The main dialog and the "non-existing file" subdialog look like this:

Here I've put the parameters in [square brackets], of course it is the developer's duty to localize them.

For the rest, except for the "All Files" pattern label (which should be "Tous les fichiers" in my case), everything is correctly localized and satisfyingly formatted.

Now let's compare with a "File Dialog" express VI configured in mode "File, New".

The main dialog and the "replace existing file" subdialog look like this:

The "replace existing file" subdialog is not localized and its format is not consistent with the "non-existing file" subdialog.

For the subdialog's title, it should be the [Prompt] as well.

For the file name, it should be the short file name (and not the full path). This one is my personal preference but both subdialogs could display the full path as well, as long as it is consistent.

Regards,

Raphaël.

I find often the need of creating array indicators with many elements, and of labelling them is a way which allows easy identification of the element index.

Normally the labels of the elements can be made visible, like in the left example shown:

One way of doing it, if the array has a fixed size, and all of the array is shown at once, is to juxtapose a set of text labels identifying the elements. Tedious to build.

If the array changes size, if it is larger than shown, if it is supposed to be scrolled on the FP, static labels are useless. Currently the label of the element can be made visible, but all elements share the same label. The index display of the array can be shown, but it relates to a single element, which makes cumbersome to identify elements of long arrays.

I usually resort to more sophisticate contraptions, like arrays of clusters, each composed of the element in question and of a numeric indicator; or to two parallel array indicators, one for the elements itself and one for the indices. Both solutions are more cumbersome to build and to size and align equally; the index content has to be prefilled and maintained in sync when array elements are added or deleted (programmatically or via contextual menu); in the second case, a lot of events have to be trapped programmatically, for instance to maintain synchronism when the main array is scrolled.

What I would like to have is an additional label natively visible, showing the element index, like on the right.

The labels could be made optionally visible with a contextual menu ---- left click->visible items->index label.

Options (perhaps properties) in order to set the value of the first element (e.g. 0 or 1 or any other value) and the step value if different than 1 would also be useful. Standard options about location and orientation of the label with respect to the array element would apply.

Why dont wires have an optional label associated with them.  Style guides have use label long wires but wires have to be moved often during development, and the labels are not fixed to the wire.  This should be maintained for us.  Right click on wire and add label, with ability to lock label to wire source, wire midpoint or wire destination.