There are numerous ideas floating around about where the color box constant and control should be located in the palettes. How about if there wasn't a distinction between a color box and its numeric representation? Like the "View As Icon" option on terminals and clusters, I suggest a "View As Color Box" on numeric constants and controls/indicators:
I'm undecided on if this options should be available for all numeric data types, integers only, or U32 only, and what should happen to the Representation options when the numeric is a color box. I see at least these options (ordered after my preference - I prefer 1) the most):
1) The "View As Color Box" option is available for all numeric data types, but when selected the data type changes into U32. If you change Representation to anything else but U32, the "View As Color Box" option is automatically deselected.
2) The "View As Color Box" option is available only when the numeric is U32.
3) The "View As Color Box" option is available for all numeric data types, and coercion happens between the selected "color value" (U32) and the true Representation of the numeric.
Sometimes you might have a cluster constant, indicator or control on the block diagram or front panel without the labels shown. When you have a large cluster it's not immediately obvious which element you're editing/changing.
When you hover over a SubVI, the connector flashes on the Context Help window and eventually a tooltip appears on the block diagram under the mouse cursor as shown below:
I propose that, just like when you hover over an input/output of a SubVI it does the same to show the element name on clusters on the front panel / block diagram, as follows:
I know it's not the most exciting of suggestions but I think it would be good for usability.
I'm using 2012 version, so I don't know if it's the same for 2013 and 2014 versions.
I don't use color boxes very often but when I do I always have the same problem when looking for them in the tools palette.
When in the front panel the Color Box control is situated in the Numeric folder
But when in the diagram the Color box constant is a little more hidden...
I know there is the "Search" option, which works very well. Also I can choose the color box control in the Front Panel and change it to a constant, but I worked for a lot of years with version 6.0 to 7.1 and it was very intuitive to find the constant where it was, i.e. here:
So why don't leave the color box constant with the other numeric constants?
By the way, thank you for reading, I always wanted to comment this
This idea is somewhat similar to Shrink-Wrap-Structures but for comments and strings
The idea is to resize a comment or string to the text by double clicking one of the resize indicators around the box.
This would happen without changing the number of lines or words on each line.
The process would be resize the horizontal direction of the box until the line layout looks nice (and fits!) then double click the corner to remove the unwanted space.
There could be different resize processes depending on the corner or edge you click eg. double clicking bottom middle resizes to only remove vertical space, top left would resize and shift the text down and right so the bottom right corner remains anchored.
There are some other ideas about resizing multi line comment boxes but none were quite as straight forward as this so I made a new post for it.
This mechanism is similar to other programs for resizing boxes so it seems like a sensible thing to implement.
I like to collapse long string and path constants to consolidate diagrams. Showing the string or path value in the tip strip is useful but tedious to update.
I suggest an appearance property that would automatically display the current value in a tip strip for string and path constants.
This property would be most useful if the Block Diagram Options page was also modified to allow a global setting.
Here's an idea to make better use of front panel pixels and printer paper.
1) Too much data to show on one screen using regular controls, instead of tabs, Show at-a-glace highlightable data in a configurable cluster format. Before LabVIEW 2014 the typedef table inside a typedef cluster would do thes fairly well.
2) Use same panel as print format since it is at-a-glance and one panel, WYSiWYG printing made easy
3) LabVIEW2014 crashes when table typedef is nested in a cluster typedef - this suggestion is improvement, not just workaround.
Suggestion: Bring back super space efficient (flat plain) controls and indicators, so I don’t need to worry about NI dropping support for the classic plain text one. This will allow me to make my own table like displays using individual fields in a typdef cluster. I could just format a big string control and write code to fill it in by row-column position, but that looks so DOS. How about marketing it as a report builder cluster like panel builders available in many text based languages?
1) Add space efficient flat controlls and indicators to current palette, similar to flat string control in classic palette.
2) Allow these to be placed into a flat cluster that can be typedef
3) Provide a fast way to lookup controls contained in this cluster by name, similar to get array of references and loop through for name match.
4) If desired make an Express VI to build a GUI / Report cluster similar to the way text baased programs do it.
5) Provide for setting printable paramters - shape designed for portrait or landscape and with about the right number of pixels so it fits easily into the printer (no extreme zoom in or out to fit, no half of the printed page left blank, etc..), using this shape as a starting point, nice printable panels will be easier to make.
One of the things that sometimes bugs me when using LabVIEW is that if you have a front panel or block diagram in a small window, many of the menu options and toolbar options are inaccessible without having to resize the window first. You have to have a minimum window size to be able to access all of the toolbar functions.
Still don't get it?
This is how big I want my SubVI window to be:
Problems with the above:
To be able to access the entire toolbar, the windows has to be at least one of the following wide:
Why is this a problem?
Please make it so that the menu and toolbar are accessible regardless of window size. One solution would be to have a button that allows you to 'scroll' the toolbar or have a pop-up dialogue that shows the missing toolbar buttons as per the image below.
MS Paint skills (icon lifted from Chrome's bookmarks bar):
As an aside, MS Word manages it fairly well (even though it isn't that readable), and it has a LOT of toolbar buttons:
Please consider my idea (or Kudos it) for future versions of LabVIEW - it will improve usability of the IDE.
When dragging a control / indicator label or caption, if you move within a certain distance from the owning terminal the label will snap to one of a set of given positions (top-left, top-middle etc). Outside this distance (or if the user presses the spacebar to toggle this behaviour), the label can be freely positioned.
The selector terminal for a polymorphic VI should display the same behaviour with regard to the owning VI icon. A polymorphic selector is currently always free-floating.
PS : Many thanks to Intaris and TiTou for their help to formulate this idea.
When tabbing between strings, you can type in each box.
When using Rings and Enums, you can select items by typing after the control has been clicked on; for example, if "Lead" is in the list, you can click on the Ring/Enum and type "L" and the control highlights the first element with "L" in it. You can then hit "enter" to choose that element in the list.
It would make much more sense from a user's standpoint if they could tab to a Ring/Enum, and start typing to choose an element.
I propose that when a user tabs to a Ring/Enum control, that if the user starts typing, that the Ring/Enum selects an element similar to if the user had clicked on the control.
Clusters can be a useful tool for the programmer. Its role is on the block diagram. On the front panel the cluster's only useful feature is better served by grouping and decorations.
-Clusters force you to have all the controls within it bundled together within a box on the front panel. A box that even interferes with keyboard navigation. If you want one of the controls to be located elsewhere, you have to choose between the usefulness on the block diagram, and the best design of your user interface. The link is just unnatural.
I can understand the philosophy behind the current solution. It maintains a coupling between the block diagram and the front panel that is consistent with much of how other parts of the IDE works.
However, once you have established that clusters only exist on the block diagram, the need for a front panel representation of it quickly vanishes. There should be a way to get an indication on the front panel of the controls that are bundled together. It should be obvious to the programmer that deleting a control that is defined as part of a cluster will affect the cluster on the block diagram etc., but not much is needed to achieve this really.
Breaking artificial couplings are always good, but never pain free. They break old habits. But the end result would be a more flexible and intuitive solution for both programmers and end (application) users.
Say I've dropped two 2D array controls on my block diagram, and would like to change both of their appearances in the same way. I can select each one at a time, right click and head to Visible Items > Index Display. However, it would be nice to be able to select multiple items of the same type and have the option of applying the same change to all of them.
Currently, selecting both and right clicking lets me change the following:
It would be nice if LV could recognise that I've selected two identical controls and offer me the option of changing the display settings for each of them:
Expanding this, you could use the same approach for BD constants, such as setting multiple string constants to '\' code display, or disabling size to text.
Probes are useful for seeing when a piece of code has executed for the first time after clicking 'run' as well as to see real-time values on wires.
Currently probes retain their values when the top VI stops, which is useful, but less usefully, keep their values indefinitely, even when the VI is restarted.
I'd like them to reset to 'Not Executed' when you click 'Run' again, otherwise I have to delete and recreate each probe in order so that I can tell when they have executed for the first time (unlike the lightbulb which slows everything down, breakpoints which pause the code or adding indicators which may not be convenient on a front panel (and require initialisation code)).
If this could be implemented (or could be an option for all probes or for any individually by right-clicking on them) I would find it really useful!
I like to compare two build specifications of two different projects.
To do this it would be very helpful, that the build specification dialog box is not modal and that i can open each build spezification of each project at the same time. Resizeable would be also nice.
If we select some code and try to copy it to the front panel, nothing happens of course because the code has no meaning on the front panel.
However, we can paste that same code into many other applications (e.g. MS Paint) and it turns into an image. We can immediately copy that image and paste it to the front panel. I often use this for forum examples, e.g. here.
Why can't we eliminate the middleman????
We should be able to paste code directly to the front panel and it will simply turn into an image of the code!
We should even be able to simply drag code from the BD to the FP for the same effect.
This could even be useful during code reworking. We could temporarily paste a picture of the old code to the FP so we can better remember what was connected where while we make modifications.
(It could even turn into a snippet so we can drag it back and it turns into code, but a plain image is probably sufficient)
I would like to see an option added to the Project Library Properties: Protection to propagate the protection setting (and password) to all vi's owned by the library.
Currently if you lock a lvlib it only prevents adding or removing vi's from the library. To lock the vi's from editing you would need to open and change the properties of each vi.