LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

It's hard to believe that this is the first post to request something like this (pun intended), but I couldn't find it after a few queries.

The base idea would be that both the static and dynamic connectors used to connect the methods to the owning class shall be defaulting to the owner class, a.k.a. this object in text based languages. The main problem is the use case for refactoring. When moving around methods the class controls and indicators have to be replaced every time. It doesn't matter if I'm moving methods between classes or to interfaces it is the same pain: replace the connectors (with QuickDrop), then change the names to class names, then update the icon, finally move the VI to the new location.

I know that this could and maybe is already solved with scripting, but I think the development environment shall grant the option to change the control and indicator to this object that will always default to the owning class, without manual updates. Even the labels could be This in and This out, and replaced in real time with the actual class implementation on the block diagram of the calling VIs.

The proposed solution would also get rid of the error telling about the dynamic dispatch controls shall reference the owning class, since it would happen automatically.

View All (2)

For anyone that has used CAD software, you know how much of a timesaver this feature is. It is very similar to quick drop but relies more on graphical selection than keyboard input (although, these shortcuts often allow text entry as well and have a configurable menu).

For example, pressing the "S" key in SolidWorks pops up a contextual, configurable menu at the current cursor position that allows you to rapidly click on common operations as well as customized shortcuts.

I have my own janky extension to quickdrop that makes a graphical menu present after pressing multiple buttons (ctrl+space, ctrl+q, then one of WASD or a mouse click on the popup .vi front panel), but it would be nice if I didn't have to go through multiple shortcut selections to hit my toolbar-of-target. Said another way, a more extensible quickdrop-like shortcut bar would be nice. Something like the right click and shortcut keypresses for Autodesk Fusion and Solidworks are the inspiration.

A very common task when operating with 2D pictures are mouse down/move events where we are interested which pixel was just clicked. While there is an event data node for the clicked coordinates these are relative to the front panel and translating them into image pixel coordinates is a chore and requires ~~jumping through flaming hoops~~ tweaks. (i.e. label yes/no? zoom factor? etc.)

However, there is a "Mouse" property for 2D images that has all the information directly in pixel coordinates and mouse button states. Currently, we need to read that property inside the mouse event to easily get the information we always (always!!!) want in such an event!

It would be cleaner if mouse events on pictures would output these mouse properties directly as an additional event data node.

Two clear advantages:

Cleaner code for those who know how to work with this property.
Stop sending newbies on a snipe hunt trying to figure out how to translate the current "coords" event data node into something useful for the intended task.

Here is an example where this idea would have helped

Here's a picture for the graphical thinkers!

Thanks for voting!

For string controls and indicators please add a vertical alignment option. We have applications where we will programmatically change the font size, which requires a string control/indicator to be sized for the largest option. Since there isn't a vertical alignment option, the string is always aligned to the top and it can make the front panel layout look strange.

Other applications have long strings that may be a single line or may be a variable number of multiple lines, but we'd like to be able to center the text vertically. Again, this requires the control/indicator to be sized for the largest option, but all the text is always vertically aligned to the top of the front panel object.

View All (2)

Integrating markdown, asciidoc, whatever. This would help eliminate a step for most of us lowly third parties making docs for our software. A built-in browser would be nice, or just opening the doc straight away in a compatible viewer would be fine.

Loading the NI website's page for the help doc takes ages. This could also be a way to locally host vi docs and have a built-in browser-like display of help files.

I frequently find the context help information not detailed enough and get frustrated waiting for the website to load. If it was a one-stop shop markup-based doc, that's meaningful time saved.

It's always a pleasure to uncover shared memory problems when working with base vi.lib methods that *should* work as preallocated clones and have uninitialized shift registers and then having to establish a chain of vi references to safely call those methods in an application with distributed/parallel threads. It feels like extra work but does fix the problem. It's a major unknown gotcha unless you're already familiar with the vi you are calling.

My most recent hiccup: the NI PID library. I needed two closed loop controllers in actor framework, and was getting very strange timing, setpoint, process variable, and control output crossovers until I realized the stock .vi's had shared memory in the form of uninitialized shift registers (despite being in the context of a pre-allocated actor). Creating references of the vi's I needed and storing them in the actor at launch fixed the problem, but at that point the effort in writing my own PID .vi starts to be a favorable time tradeoff. At least I am able to peek under the hood of the PID library, other aspects of vi.lib... not so much.

Or maybe this is a teaching problem. I haven't come across ways of navigating this issue from official NI documentation, in fact the way I learned I needed to call the PID.vi by-reference was from the forum and rather matter-of-factly. There are a couple of great blogs that cover this issue in detail, so I don't feel alone in my ignorance. Maintaining State Information in LabVIEW Applications, Part 5 - LabVIEW Field Journal Archives | LabVIEW Field Journal Archives

Providing additional Context Help information on Controls that contains information as to their "type" (Classic, System, Silver, etc.) as well as their font, font-size, and control-type (indicator, ring, enum, etc.) would be useful. The utility of this is obvious if you have ever had to modify/update an existing GUI and want to maintain the look and feel when adding new controls -- this would allow you to easily see what was previously used for the existing controls on a GUI. This "verbose" information could possibly be turned on/off as a Tools->Options->Front Panel setting.

View All (2)

If we want a ring of a string type we can use a combo box and if undefined items are not to be allowed it *could* behave as a regular ring (integer type) with no text editing/input, but that is not an option in LabVIEW now. Having such an option would allow us the keep the behaviour of multiple ring controls identical (and hence more intuitive to the users) although their types behind the scene for programmatic convenience are different.

If you want to keep the ring as a string (to not have to deal with it indirectly though the ring/enum string array property, which would be the current workaround...) you are currently forced to accept that the this ring will behave differently than other ring controls or enums:

In Microsoft applications the suggested feature is available by setting the style of the combo box to DropDropDownList.

I like compile time type safety checks. I dislike using variants. Occasionally, and increasingly more often, I find myself going to great lengths to provide compile time type safety. At a point, the type check gets lost in the inheritance hierarchy and I am back to depending on runtime checks for errors. It's not uncommon for me to have a class method that needs to "just work" across the bulk of the base types, but it sure is a pain to make wrapper classes, static inlined methods, and a nasty polymorphic .vi to mimic this behavior. Perhaps I am ignorant to some features of LV (do malleable vi's fit in here somewhere?), but multiple dispatch/function overloading sure seems like the silver bullet for this issue without messy inheritance trees.

I'm open to discussion on alternatives. This "problem" has come up in a couple of recent projects of mine, and I always feel dirty using a variant or making a static API for a class that ought to be extensible.

A "This subVI" reference

Using property nodes, it's possible to retrieve a list of subVI references within a VI's block diagram. However, there's currently no way to link each reference to its specific subVI instance.

For example, if you place three instances of subVI "A" in a diagram, you can obtain three references to these subVIs, but there is no way to determine which reference corresponds to which instance.

The proposed idea is to introduce a "This SubVI" reference — a property or node that would return the reference of the current subVI instance (the one hosting the object or node). This enhancement would significantly improve scripting capabilities, support tool development, and aid in debugging tools.

View All (2)

right-click -> Find In Project

Improved Comment entry

When I add block diagram comments inside a structure, they are often long enough to require several lines. Since auto-grow is on, I need to stop typing before the comment reaches the edge of the structure, resize the comment to be multi-line, select inside the comment again, and re-start typing. From then on, the comment word wraps at my sized width. Could you make a special character like ctrl-, alt-, or Shift-comment move me to the next line and make the comment that wide, so it word wraps at that width from then on? While you're at it, could a word-wrapping comment autogrow in height to fit the comment, like a one-line comment auto-grows in width? Subdiagram comments could use that feature, too.

I couldn't find this explicitly mentioned here, but it seems related to:

Block diagram references should be 16 pixels tall (currently 19 pixels) - NI Community

Same Height of Unbundle by Name / Terminal / Local Variable - NI Community

Although making changes like this could hurt legacy code, earlier implementation is preferable. Local variables are already the same size as bundles and property nodes, but constants are not. My suggestion is to increase the size of bundle/unbundle elements by one pixel and decrease the size of constants by two pixels by reducing their border thickness. Since numerics require a type indicator, a 1 px border wouldn't compromise recognition. Numeric constant type visualization - NI Community

Reduced inteface size

View All (3)

LabVIEW Idea Exchange

Class controls and indicators shall default to "this" class

Graphical context menu at mouse pointer, super-duper quick drop

Mouse events on 2D pictures should have an event data node for mouse information

The properties page of "boolean array to number" must include the "sign extension mode" setting.

Add vertical alignment property for string controls

Extensible markup supported in VI documentation and help files. Locally hosting vi.lib help docs.

Eliminate uninitialized shift registers from vi.lib

Front Panel Control Context Help: Show Control Type

Add dropdownlist style option to LabVIEW combo boxes

Multiple dispatch / Function overloading

A "This subVI" reference

Abortable recompile when closing project

right-click -> Find In Project

Allow file renaming to record changes to capitalization only in Windows

Improved Comment entry

Match Property Node height to constants

Reduced inteface size

Reversion of custom images of Boolean Control states to the NI default in Control Editor

Add "Scale Legend Change" as an event for graphs

LabVIEW for ARM processors