LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

When you create a class, it gets assigned a "random" color.  But there are only 6 (or so) colors that are randomly chosen from. I do a lot of LVOOP, and generate a lot of classes. But because there's such a small selection of colors, I'll often drop class methods with the same color banner next to each other (and yes, with text), and it can sometimes be a bit misleading.

 

Why not have, say, 64 colors that are used to randomly assign class colors?  Or better yet, just use a randomly generated color within a range of shades?  It's such a simple change yet it would have a meaningful impact on the developer experience (well, at least mine).

 

_carl_0-1721943387831.png

 

The one button dialog is a great tool when debugging code. It's very convenient to wire a string to the dialog to probe data when regular debugging techniques are not available. There are times when it would be handy to wire a non-string data type and not have to either convert a number or a boolean to a string. Formatting should be limited (for simplicity) such that data types like arrays and clusters would need to be handled by the user.

 

onebutton.jpg

A tool option on the  block diagram's toolbar, for creating 'VI Snippet' is very much desired. This is very similar to the 'snapshot' tool available in Adobe Reader software.

 

Provide option to create snippet on the tool bar

In LV 2011, an asynchronous Call By Reference feature was added to LV. This feature added a new node called the Wait on Asynchronous Call node. This new node has a timeout that is configured way way of a right click menu option.

 

It would be nice if the timeout was specified by way of a normal input that can be wired. This has several advantages:

    • The timeout can be specified at run time
    • The timeout value can be visible on the diagram without right clicking and showing a dialog
    • The timeout would be more discoverable by users

Format Into String can become very complicated when you have multiple inputs. I think implementing it in a way similar to the Formula Node could make it much better.

Ideally,

  1. naming of the inputs should be allowed
  2. the input fields in the string should be color highlighted
  3. when hovering or clicking over any of the input or the format string fields, the matching ones should be highlighted in bold or with different background for example.

FJR0_0-1697721252785.png

As a side note, the Formula Node itself could also benefit from the same color and hover highlighting.

 

There are cases where a variant constant / control needs to have a data value. This can be done by right-clicking a control / constant, selecting Data Operations -> Copy Data, then right-clicking the variant and selecting Data Operations -> Paste Data. This can be time consuming for many variants.

 

variant_drag_1.png

 

The idea is to allow dragging and dropping of a control or constant onto a variant, and have the data copied to the variant:

variant_drag_2.png

Often when using tables (and multicolumn listboxes), the content of the table column or row header is longer than the desired width of the cell.  It would be nice if there was an option to make the contents of the cell wrap to the next line, similar to how tables work in Excel or Word.

 

Also, adding vertical justification options such as Top, Center, Bottom to the Active Cell property subset would be nice.

 

Here's a crude illustration of what I'm talking about.

 

new Table options.PNG

 

The title says it all, for the reference this discussion on LAVA that explains how to do it using .NET :http://lavag.org/topic/9216-deletion-of-folders-and-files/

 

Please give us a native way to do that in LabVIEW.

If I am on Mac or Linux and I try to open a VI that calls a DLL inside of a Disabled Structure, then LabVIEW searches for the missing DLL.

 

This is really a waste of time and effort, since it will never find or be able to load the DLL on Mac.

 

LabVEIW should be smart enough to know that it's not going to file a *.dll (Windows dynamic linked library) or a *.so (Linux shared object) on a Mac -- Mac uses .framework as it's shared library files.

 

So, I would extend this a little further and say that LabVIEW should only search for shared libraries of the type for that platform (.framework on Mac, .dll on Windows, .so on Linux).

 

Note: if a Call Library Function is configured for cross-platform (meaning it's configured for with a "*" file extension like mylibrary.* so that it will find the correct extension on the target platform) then go ahead and search for it.

 

2020-12-11_11-59-02.png

 

 

 

Currently, the Panel method "Convert panel to screen coordinates" works fine normally, but if the panel is inside a subpanel then it just fails without throwing an error

 

The idea is to either update this function to work properly in a subpanel, update the documentation to mention it doesn't work within a subpanel, or throw an error to indicate failure.

 

A few similar ideas have popped up, for example:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/VI-property-subpanel-ref/idc-p/4061150#M42444

 

but that one was more generic to get the a subpanel reference from within the subpanel.

 

(My specific use-case is to create a fancy menu popup relative to the clicked item within the subpanel- basically, I need screen coordinates of the "thing" inside the subpanel, which I cannot get without coupling the subpanel VI to the main VI by providing an upstream VI reference, which I don't want to do.)

For everybody who deals with a lot of different LabVIEW versions it is difficult to handle the versions.

If you forget to select [save for previous], the code will be recompiled to the newest version.

 

There is a new feature to select the expected version in the project manager (started with LV2024). 

But there is no possibility to select a specific version for the development environment itself (eg in the menue [Tools] - [Options] - ...

Something that bugs me is when I right click on a terminal to create a Indicator, for instance, and the frames around it expands to fit the new Indicator and it's label default. This is much worse in complex diagrams with many nested frames.

I propose that the frame expansion should be done only after the text validation in order to increase the minimum necessary, as shown below:

 

Did you know you can make property nodes and invoke nodes smaller by not showing the names?

 

18885i5C350C6F75475F32

 

Well, forget you know, it's a terrible idea to hide that information! You lose the self-documentating nature of LabVIEW. I use this as a comparison for Call Library Function Nodes (CLFN) - by default, these are dropped on the block diagram without showing names. I propose that the default is to show names for CLFNs for the sake of documentation, and so you don't have to hover over each terminal to find the one you're looking for. The biggest perk is simply the name of the function on the banner of the node. YES, there is a tradeoff between BD real estate and documentation, but I think "Names" trumps space virtually all the time.

 

18887iBEE93A577FAAFAA3

Consider how CTRL+E toggles between the BD and FP, back and forth. Likewise, it would be nice if CTRL+Shift+E toggled between the VI and its corresponding Project Item.

 

Currently, when viewing a VI window, CTRL+Shift+E will highlight the Project Item -- but this action is unidirectional -- pressing the same key combo again does not take you back to the VI (it just does nothing).

 

Oh, and, Reflexive... is that the right word? Bidirectionality? You get the drift. Here's an illustration:

 

CTRL-SHIFT-E-Reflexive.gif

I like to have my project window open, nice and skinny, on the left of my screen.  I have some extra stuff installed into my environment, which means more buttons, and that means that I can't see all the buttons unless I expand it out a lot:

 

Good.jpg

 

I'd prefer to be able to have more than just one row of buttons:

 

Better.jpg

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.

When a complex application uses deeply nested clusters to organize their application data, it can be difficult for others trying to extend/maintain that code if they are not intimitely familiar with the names and the datatypes of the elements within the data structure.  Is that element a integer, enum, string, path, array, cluster, object?

 

The context help provided when hovering over wires and the color and texture of the wire on the diagram is very useful, but neither of these are available when you are attempting to select the correct element from the bundle/unbundle nodes.

 

I propose that the same datatype glyphs shown in the context help when hovering over wires should also be visible when attempting to select the correct element in the bundle/unbundle nodes.

 

Enhanced Bundle Element Selector, no context help.JPG

Dear LabVIEW Team,

I hope this message reaches you in high spirits and with a cup of tea in hand, because I am about to share a groundbreaking idea with you.

After years of fascinating work with LabVIEW, I would like to express my sincere admiration for the breathtaking number of windows that make your development environment so unique. While other programming environments like Visual Studio try to structure the development process in a boring way, you clearly rely on the "more is more" principle.

It is simply fascinating to see how each VI always has two independent windows. It makes me feel like I'm exploring a virtual windowscape - a journey into the unknown where each window is an adventure in itself. I can't remember the last time I had this much fun developing.

But why settle for just a few windows when we could take inefficiency to a whole new level? So I propose: Let's keep increasing the number of windows! Why not give every single structure in the code its own window? That would really be the pinnacle of chaos efficiency.

 

I imagine it like this: When I create a loop, a new window opens in which I can program the code for the loop. For each case of a case structure - another window. The possibilities are endless! An endless labyrinth of windows that turns my screen into a colorful kaleidoscope. That would be the pinnacle of innovation, wouldn't it?

I hope my ironic enthusiasm for the distinctive LabVIEW window concept has been well received. I am certainly available to discuss this idea further and am willing to contribute to the creation of an even more chaotic, but undoubtedly entertaining, development environment.

With sarcastic regards,

An enthusiastically chaotic LabVIEW developer

 


Sehr geehrtes LabVIEW-Team,

 

ich hoffe, diese Nachricht erreicht Sie in bester Laune und mit einer Tasse Tee in der Hand, denn ich stehe kurz davor, eine bahnbrechende Idee mit Ihnen zu teilen.

 

Nach Jahren der faszinierenden Arbeit mit LabVIEW, möchte ich Ihnen meine aufrichtige Bewunderung für die atemberaubende Anzahl von Fenstern aussprechen, die Ihre Entwicklungsumgebung so einzigartig machen. Während andere Programmierumgebungen wie Visual Studio auf langweilige Weise versuchen, den Entwicklungsprozess zu strukturieren, setzen Sie eindeutig auf das Prinzip "Mehr ist mehr".

 

Es ist einfach faszinierend zu sehen, wie jedes VI immer zwei unabhängige Fenster hat. Das gibt mir das Gefühl, als würde ich eine virtuelle Fensterlandschaft erkunden – eine Reise ins Ungewisse, wo jedes Fenster ein Abenteuer für sich ist. Ich kann mich nicht erinnern, wann ich das letzte Mal so viel Spaß beim Entwickeln hatte.

 

Aber warum sich mit nur ein paar Fenstern begnügen, wenn wir die Ineffizienz auf ein völlig neues Level heben könnten? Daher schlage ich vor: Lasst uns die Anzahl der Fenster weiter erhöhen! Warum nicht jeder einzelnen Struktur im Code sein eigenes Fenster zuweisen? Das wäre wirklich die Krönung der Chaos-Effizienz.

 

Ich stelle mir das so vor: Wenn ich eine Schleife erstelle, öffnet sich ein neues Fenster, in der ich den Code für die Schleife programmieren kann. Für jeden Case einer Case-Struktur – ein weiteres Fenster. Die Möglichkeiten sind endlos! Ein endloses Labyrinth von Fenstern, das meinen Bildschirm in ein kunterbuntes Kaleidoskop verwandelt. Das wäre doch der Gipfel der Innovation, oder?

 

Ich hoffe, meine ironische Begeisterung für das unverwechselbare LabVIEW-Fensterkonzept ist angekommen. Ich stehe Ihnen selbstverständlich zur Verfügung, um diese Idee weiter zu diskutieren und bin bereit, meinen Beitrag zur Erschaffung einer noch chaotischeren, aber zweifellos unterhaltsamen Entwicklungsumgebung zu leisten.

 

Mit sarkastischen Grüßen,

 

Ein begeistert chaotischer LabVIEW-Entwickler

 

There have been numerous ideas on how to improve the for loop. Some people want more information. Some people want the option to have less. Some people want to be able to move the terminals or hide them altogether.

 

This suggestion should take care of some of these issues, and open the for loop for future expansion: Let the for loop data be exposed through a terminal block, similar to what event structures have:

 

FL Node.png

 

 

This would be resizable in the same way that the event structure node is and would allow you to change the order of terminals. This would also allow NI to add additional loop data without worrying about cluttering the loop for those who don't want it.

 

Additionally, if NI implemented this idea, then we would also be able to hide this node entirely, which is useful in some cases.

 

 

Here are some relevant ideas which would be helped by this idea:

 

  1. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Option-to-Show-Hide-the-Iteration-and-Count-Terminals-on-For/idi-p/1057793
  2. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Option-to-quot-Dock-quot-the-Iteration-Terminal/idi-p/1087200
  3. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Sliding-N-Terminal-on-FOR-Loop-and-or-Progress-Terminal/idi-p/1238178
  4. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Reverse-Iteration-Terminal-in-For-Loop/idi-p/1174449
  5. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Progress-Terminal-for-FOR-Loop/idi-p/1236224
  6. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Diagram-Cleanup-should-not-move-loop-terminals-option/idi-p/974415

Hi

I don't know if this idea posted before.

When I want to customize a Boolean button by adding picture to it I have only three options which are import picture to True, False and decal. My suggestion is to add more options from which the user can add true and false picture on the Boolean button without changing its original shape. Here an example:

 

Let us say that I want to customize the Start Test/Stop Test button by adding a picture on the button that represents the start state and another picture to represents the stop state. In order to do this I have to import the true picture as decal then take a print screen for the control, also I have to import the false picture as decal then take a print screen, then I have to import the two print screens for true and false state

 

It will be nice if it is possible to have an option to add multiple picture same as the multiple test option

 

Untitled.png   Untitled1.png