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.

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:

Swagger/OpenAPI  has become the default go to way to document and interact with rest API's.  It would be great that when you publish a LabVIEW webservice it generates the OpenAPI yml or json file (being able to generate both would be great).

Also having a right click in the lvproj webservice view that brings you to the swagger page for debugging would be helpful. 

It would be useful to have a node that could be fed any wire and return the size (in bytes) of the data on that wire. In other words, the node would return the number of bytes that the wire occupies in memory.

For example, the node would return a value of:

• 1 byte when fed a U8 wire
• 2 bytes when fed a U16
• 4 bytes when fed a I32
• 8 bytes when fed a DBL
• 800 bytes when fed a 1D array that contains 100 DBL elements
• 9 bytes when fed a cluster that contains a DBL and a U8
• 9 bytes when fed an object that contains a DBL and a U8
• 18 bytes when fed an object that contains two other objects that occupy 9 bytes each
• and so on

Notes

• The node would would enhance LabVIEW programmers' ability to monitor and audit memory usage.
• The node may serve as an additional tool to detect memory leaks (by repeatedly calling the VI on the same wire and checking whether the size is going up).
• The node would simply be interesting to programmers interested in performance and would enable programmers to learn more about LabVIEW internals.
• The node would be useful especially to query the size of complex data structures, such as objects that contains other objects that themselves contain objects, or clusters that contain arrays, or arrays that contain clusters, or objects that contain DVRs.
• I would be happy if the node had a second input named "Mode" (or similar). This input may be a typedef enum with items named "Shallow Measurement" and "Deep Measurement" (or similar). This input could be required, recommended, or optional.
  • When "Shallow Measurement" mode is selected, the node would return the size of all the by-value data fields in the main input wire, but would not add up the size of data referenced by DVRs or other references. For example, a wire that contains a cluster that contains a DBL, a U8, and a DVR would return perhaps 13 bytes (8 + 1 + presumably 4 bytes for the DVR reference itself). It would not add to the result the size of the data referenced by the DVR.
  • When "Deep Measurement" is selected, the node would recursively scan all data structures, including DVRs and other references.
• In both "Shallow Measurement" and "Deep Measurement" modes there should be no limit to the scanning depth. In other words, if a cluster contains a cluster that contains a cluster and so on, they should all be measured regardless of the nesting depth. Similarly, if "Deep Measurement" is selected, and a DVR contains a DVR that contains a DVR and so on, the data behind all these DVRs should be added to the total.
• When in "Deep Measurement" mode and fed a Queue reference wire, the node could perhaps return the size of all the data in the queue. In other words, the size of all the elements present in the queue.
• Perhaps the LabVIEW compiler already uses a "Get Data Size" function internally? If such a function already exists, perhaps it would be relatively straight forward to expose it as a node in the palettes?
• Perhaps the best location for this node would be in the Programming >> Application Control >> Memory Control palette.

Thanks!

On bigger projects, when creating a new class, I find it time-consuming to track down the parent class I'd like to inherit from.

It'd save me some pain if there was some kind of filter and/or search option for this on the New Class GUI:

Other thoughts on this:

- While the tree structure is useful, I usually know the name of the parent class I want to inherit from, but I don't necessarily know the full inheritance of it, meaning the tree structure isn't the most efficient way to find it.  (Even alphabetical by class name would be faster in these cases).

- I'd find the tree structure here easier to follow if the lines were visible.