LabVIEW Idea Exchange

My software is used in microscopy, and the screen brightness can be annoying for people looking into the microscope. Nowadays, all microscopy has a range of dark colour schemes, to suit the user, to either work in complete darkness, or just low-light situations.      

I want to be able to do the same, i.e. make custom color schemes.   The system color schemes don't quite satisfy, so I really want to do this programmatically.

For most controls, i can nicely change all colors using the property nodes.  But strangely enough, some controls simply don't give the option, even though you can do it manually.  The color options seem to be very inconsistent in this respect...

For example, the numeric Knob or Dial are perfect.  You can set the color of the knob, as well as the color of the ticks, the text, etc.   Similar for a slider, where every little detail can be set.

But strangely enough, the normal numeric (digital) lacks the option to set the color of increment/decrement button.  However, can set those colors manually.   The menu ring however, doesn't seem to have any way to change the color.

That doesn't make senso to me....   Why give the option to set all the colors of some controls, and then not have that option available on other controls?  

My request is to make sure that ALL controls have the color properties you need to color them programmatically.  The Knob and Slider are nice examples where it is done very well. 

Although it appears that the 2020 version of the Block Diagram Cleanup Tool (BDCT) does do a better job than its predecessors, I would still say that the BDCT’s results are still less than optimal. Most LabVIEW Idea Exchange posts concerning the BDCT talk about label positioning and alignment.  Here I would like to focus on the issue of horizontal expansion of the block diagram and a holistic view of what LabVIEW features contribute to that effect.

Like most programmers, when developing a VI block diagram, I try to keep the diagram no more than one screen wide.  I have learned a few tricks over the years that help manage horizontal expansion, such as resizing an object’s label so that the words appear on multiple lines before running the BDCT. This allows for some compression horizontally and allows for some growth vertically to compensate. Horizontal expansion of the block diagram is certainly expected to some extent because data flow happens left to right, of course; but it would seem logical to incorporate that knowledge into the BDCT algorithm to compensate and find ways to adjust the spacing so that the rearrangement creates more a bit more vertical expansion and less horizontal expansion—while still satisfying usual criteria such as no backwards-running wires.

Because data flow is horizontal, to help the BDCT work better, NI may want to think about what visual features—other than left-to-right data flow—contribute to a unnecessarily wide block diagram. I seldom have an issue with a block diagram becoming too tall.  Admittedly, poor programming technique can result in too-wide block diagrams, but let’s look at a few other things. What elements of LabVIEW’s block diagram unnecessarily consume width? Here’s a few that I could think of:

1. Long names in bundle/unbundle cluster objects, property/invoke nodes, Enum/ring constants, local variables, formula nodes, etc. – Most LabVIEW-supported languages are left-to-right horizontal. Long names, especially when using nested clusters, take up horizontal space. I like being able to use long names; it helps the code to be more self-documenting. If those type of objects supported word-wrap, that would help conserve width.
2. Expression nodes and multi-digit constants – no word-wrap available here either.
3. Named terminals of timing and event structures – They are what they are, and you cannot remove all of the ones you don’t use, and so they take up space horizontally.
4. Some native functions – There are some LabVIEW native function icons that are wider than they are tall. Some examples: In-Range/Coerce and Initialize Array.
5. Shift registers – It has a subtle effect, but shift registers are wider than they are tall. Do they have to be that way?

To fully tackle this issue, I believe you have to look at things holistically and not just as potential improvements that could be made in the BDCT.  Recognize that data flow is left-to-right horizontal and you will have long text names; you can’t really do anything about that. However, there are other things that could be done in LabVIEW feature-wise to help compensate for width-wise block diagram growth.

I would like to be able to target an entire sub-palette for searching, rather than just a single vi.

That way, for example, if I want to find every vi that contains any of the Queue functions, I could get them all in a single search, rather than having to search for each vi in that palette.