LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Numeric constant type visualization

Edited Image 1.png

Notes

Replacing a node via Right-click >> Replace >> selecting item from palette results in the same outcome as replacing via QuickDrop. This idea should apply to both replacement methods.
Replacing a VI via either QuickDrop or right-click behaves correctly. The new VI label is visible only if the old VI's label was visible. In effect, the new VI retains the "Label >> Visible" setting of the VI that was replaced, which is desirable.
This idea is somewhat related to the following idea: "Show node names when dropped" option

View All (2)

Showing Mouse Coordinates on FP

Since most (if not all) controls and indicators can be moved around with "position" property node programatically, the X and Y coordinates on the front panel are useful information to have.

As of right now, users have to adjust the position values by trial and error to know what values suit the UI, or maybe make a program to capture the mouse position programatically.

So I've been getting feedbacks from customer about a function where one can view the coordinates of the mouse all of the time. (meaning no programming is necessary)

I was thinking about two methods (see attached)

1. Show coordinates along with the mouse

2. Show coordinates at the bottom of the pane

Thanks,

View All (1)

View All (4)

Currently (in LabVIEW 2010), you can add labels to wires. Hurray!!

But it's painful. Boooo!

Curently => Right-Click wire, navigate to sub-menu of Show>>Label

It should be as easy as adding free text to block diagrams or front panels. For example: If your auto-tool is on then just double-click on freespace to add text.

So we should make it just as easy to add labels to wires:

Step 1: Single-Select Wire
Step 2: Start Typing
Step 3: Profits!

We don't need no stinkin' right-click menus.

PS: I am proposing a single click on the wire instead of double-click because that performs a different action.

View All (1)

Make Edit Values table longer

Currently, the TDMS File api does not offer a way to get the TDMS file size.

Our use case is that we'd like to limit the size of the TDMS files and span them accross multiple individual files (and I've posted an idea suggestion for adding that as a native feature, too). To do this, we need to be able to monitor the TDMS file size, so that we can save/close the current file and then create the next file in the span for continued use (until we hit the size limit again).

View All (1)

The Project Explorer Files view already contains the useful "Move on Disk..." option. It would be useful if, when a VI or CTL is owned by a lvclass or lvlib, an option named "Move to Owner Folder" (or similar) existed. This option would move the selected file to the folder that contains the lvclass or lvlib that owns that file. This action would be equivalent to using the "Move on Disk..." option, but would save the user from navigating the (potentially large) folder structure to find the right folder. In short, it would save a few seconds and would help ensure consistency. It would also encourage the best practice of storing owned VIs and CTLs in the same folder as their owner lvlib or lvclass (actions that are easy to do are performed more often).

For example

Screenshot 1: A project that contains two libraries

Screenshot 2: In the Items view, the mouse was used to drag C.vi from Library 1.lvlib to Library 2.lvlib

2 (edited).png

Screenshot 3: Typically, I would now press Ctrl + E to switch to the Files view, right-click the file, and select "Move on Disk...".

3 (edited).png

Notes

It would be great if the "Move to Owner Folder" menu item was also available when multiple items that are owned by the same owner are selected.
A related idea: It would be useful if, when using the Items view to move an item from an owner to another, LabVIEW would pop up a dialogue message similar to the following "Would you also like to move the file on disk to folder <insert here the folder path of the new owner>?". The dialogue would contain Yes and No buttons. This would save the user from having to switch to the Files view altogether.

Thanks!

View All (1)

Classes? OOP? ... Huh?

Even if you don't (yet) work with LV classes, you may have noticed that they are starting to become increasingly widespread in the LV world. In fact, the excellent new Actor Framework that ships with LV2012 relies heavily on classes. LV classes are great but they can impact on your performance as a developer as your application becomes larger. I'd encourage everyone to click the magic KUDOS button for this idea, since classes will likely affect us all sooner or later!

The problem:

Most class-based architectures contain some degree of linking. One form of linking is inheritance where parent-child relationships are implicitly defined, and another form of linking arises from nesting libraries where classes (e.g.) are placed inside other libraries.

Unfortunately as the linking increases in a project, the IDE starts to become very sluggish! Those who have worked on mid-sized class-based applications know the symptoms:

Opening the "class properties" window takes 10 seconds or more
Renaming a class brings the editor to a standstill

For many projects these symptoms are a minor annoyance, but as your project grows they can become a serious impediment to productivity. Why should it take over 30 seconds to modify a class's inheritance?!

Obviously careful design can reduce linking to some extent, but that just postpones the pain. The reality is that all class-based projects start to suffer from these symptoms once they reach a "resonable" size.

The idea:

Improve the responsiveness of the LV editor when working with classes.

Highly repetitive tasks such as editing a class library's icon deserve a snappy response from the IDE, regardless of how many classes I have loaded!
Modifying inheritance is a fundamental operation. It should be quick and easy! (See this related idea)
Placing classes in libraries promotes good project organisation. It should *not* bring the editor to a grinding halt!

Credits:

Others have written about this topic well before me. Here are a few relevant discussions:

Feel free to link more!

View All (7)

Idea: The In Range and Coerce Include upper limit option should be selected by default.

1 (annotated).png

Maybe it's just me, but when using the In Range and Coerce node I virtually always need to have both the Include lower limit and Include upper limit options selected. In approximately ten years of using the node I think I used a different configuration less than five times. It has entered my muscle memory that the first thing I do after dropping the In Range and Coerce node is to right-click it and select Include upper limit.

In my experience this point of view is supported by anecdotal evidence. For example, I have recently seen a large codebase that was rightfully using lots of In Range and Coerce instances. All of the nodes had been left in their default configuration (Include lower limit selected, Include upper limit unselected). However, after inspecting the code carefully I came to the conclusion that the intention was for all of the nodes to perform an inclusive comparison on both sides. This was confirmed by a conversation with the original code author. The author had simply been unaware of the true behaviour of the node (he had assumed it performs inclusive comparison on both ends) and was unaware of the right-click options!

Excel displays the number of selected cells.

1 (edited).png

VS Code displays the number of selected characters.

5 (edited).png

LabVIEW should display the number of selected items in the Project Explorer.

2 (edited).png

LabVIEW should also display the number of selected items on the block diagram and the front panel.

4 (edited).png

Notes

In the Project Explorer the functionality would be useful to count/monitor/audit the number of VIs and CTLs in a lvclass, lvlib, or in a virtual folder of these owners, etc. It would be nice to know at a glance "oh, there are 12 public VIs in this class".
The block diagram count functionality can become more useful in large projects and VIs. For example, I recently edited the block diagram of a VI in a DQMH-based project. The project contains 16 DQMH modules at the moment (more to be added). I wanted to check that the VI I was editing was calling the Start Module.vi public VI of each of the 16 modules (wanted to check that the VI would launch all DQMH modules). The only way to do this was to "manually" count the VIs on the block diagram. Selecting them and LabVIEW displaying "Count: 16" would have been easier.
In the block diagram the information displayed by LabVIEW could be more nuanced. For example, it could display the total number of items selected (subVIs, nodes, property nodes, etc), but also a breakdown based on item type: number of VIs, number of nodes, number of property nodes, etc. All these selection stats may occupy too much space for all to be displayed at once. Perhaps they could be displayed in an element that, when clicked, expands to present all the information.
The block diagram and front panel count functionality would enable programmers to quickly estimate the complexity of a VI. Pressing Ctrl + A on a block diagram to select all items, then looking at the selection stats would reveal the relative complexity of that VI.
If a whole structure is selected on the block diagram, then the count should return the count of all items contained in the diagram, not just the items displayed to the user. For example, if a case structure is selected, the number of items contained in all cases should be displayed.

Thanks

View All (3)

Currently VI's show up in whatever taskbar's monitor they first showed up in and don't follow if they are moved to a different monitor.

This makes my workflow very difficult as I can end up with 18 VI icons (1 each block diagram and front panel) on Monitor 2 and 0 VI icons on Monitor 1. This despite the fact that might have moved have of the VI representations to Monitor 1. The only way to distribute them among the taskbars is to restart windows explorer. This is annoying to have to do even though I have a script to do it (thanks to the hero that posted that process!).

Relatedly, I don't always want all VIs to pop up when I want one to show up. I should be able to bring a block diagram up without having every other VI front panel and block diagram also pop up. Then I have to go and minimize each window individually so I can look at a document or spreadsheet at the same time.

View All (2)

I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes). This one item would expand the UI possibilities. It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets. Below are some industry examples:

Adobe Splash Screen (No border, has shadow, not square)

Microsoft Word 2010 Splash Screen (No border, rounded corners)

Resource Meter Windows Gadget (No border, specialized graphic)

Windows Media Center Gadget (Empty-transparent space between two UI elements)

View All (2)

LabVIEW Idea Exchange

Back Propagation of 'Create User Event' Datatype

Numeric constant type visualization

Add boolean text specifier in format into string

When a node is replaced, the new node label should be visible if the initial node label was visible

Showing Mouse Coordinates on FP

Detailed Error Info at a Glance in Context Help

Make adding label wires super easy (Step 1: Select Wire, Step 2: Start Typing, Step 3: Profits!)

Make Edit Values table longer

Need a way to get TDMS File Size from a TDMS File Reference

Project Explorer "Move to Owner Folder" option in Files view

Expanding a block diagram should only affect the case that is shown

Improve IDE performance when working with lots of classes

Skip dividers in listbox when navigating with the keyboard

Bundle to automatically name Static VI Reference element as for other references

The In Range and Coerce "Include upper limit" option should be selected by default

Double-clicking column header separators in tables, trees, and multicolumn listboxes should automatically resize the columns based on their contents.

Support Python node on Linux compactRIO targets

LabVIEW should display the number of selected items in Project Explorer, block diagram, and front panel

Make VIs show up in correct monitor's taskbar and be independent of others

Allow Panel Background Color to be Transparent