LabVIEW Idea Exchange

I am currently struggling with the issue that the shown knob permanently triggers "Value change" event as long as the user has not finished adjusting it yet (left mouse button is still pressed). This may be an intended behavior, but it is not in my case.

For boolean elements, there is the configuration option of "Mechanical Action". For strings, there is the option "Update value while typing". However, there is currently no such option for numerical elements.

Therefore, I would like to suggest the following:
Add an option "Update while adjustment" - true by default, so it acts as it do currently. If this option is set to false, the "Value change" event would only be triggered after the input is completed by the user.

The situation:

There is a user interface that provides the user with an array control.

The array control provides the user only one or a limited number of elements.

The user must use the scroll bars or the index control to select the correct element that he wants to modify.

The problem:

The user can scroll to a position beyond the last available array element and enter data. This increases the size of the array as expected, but not as desired in the given situation.

After the user finishes entering, the program must check the size of the array and reduce it again.

The proposed solution:

There should be a "max. array index" property of the array control. It should prevent the user from scrolling to a position beyond this maximum element index and/or editing such a position. It should also prevent adding elements via the right-click menu when the maximum number of elements has already been reached.

Extensions:

There could also be a minimum property that prevents the user from deleting array elements so that the total number falls below the minimum.

Notes:
The proposed solution should only affect the user's input capabilities. It should not change the size of the array if it was specified programmatically.

Current it is very hard to reliably manipulate decorations using VI server.

LabVIEW need to be able to create explicit decoration references (like it is possible to do on other objects through right click Create>>Reference).

Note: Thanks to TonP for the idea.

Today, the enum data type in LabVIEW only allows having sequential numeric values (0, 1, 2, 3, etc.).

It would be very useful to have sparse enums, meaning enums which can have custom numeric values assigned to their strings, just like you can do today with rings.

If you want an example where this will be useful, think of error codes - this would allow you to use an enum on the diagram to select the error, or in a case structure.

Wouldn't it be nice if Probes window had a drag'n'drop reorder functionality, maybe even a Sort?

Often you (I) place a couple of probes, maybe add some in another VI and then go back and add one earlier in a block diagram. 

Is this a problem? Well, it's not breaking, but i'd like probe 1 to be the earliest executed probe and so on. Often execution order can easily be something like 13, 19, 3 and drag'n'drop #3 below the #19 would the shift them as 3, 13, 19. (Similar to how Reorder Case works)

It'd be nice if you could drag this probe in the probe window and it'd change numbers accordingly (switch/reorder within the VI).

Maybe even have Sort button that simply renumbers all as they're shown in the probe window.

It's somewhat similar, but different, to Altenbachs switcheroo idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Probe-switcheroo/idi-p/3126138

The web format wars are over, and the plug-ins have lost.  Microsoft has relented and will support HTML5 and SVG in IE9, and has admitted that Silverlight's role will change to that of a Windows phone development platform.  Silverlight support on iPhone/iPad/Andoid/Chrome OS will likely never be fully formed, and will wither on the vine. 

New javascript/ecmascript engines that are much faster, and make use of multicore environments have arrived and work well.  The addiition of WebSockets means your browser can now open a tcp/ip socket.  I have done this, as I am sure others have, as well.  Drop an old-fashioned tcp/ip listener into your diagram, return the WebSocket handshake, and presto: you can now stream data directly to/from your browser.  WebSockets provides an "onmessage" event handler function which you can define.  Combine this with the SVG DOM, and you can transform SVG elements until your heart is content.  Two-way streaming of data between your browser and plain-old tcp/ip?  Goodbye web services, we knew you well. Good riddance, plugins.

I have built my own SVG UI objects using Inkscape (free), and wrote a script (notepad/Inkscape script editor, also free) to handle WebSockets communication without a gateway.  I have a simple LV class built on the TCP/IP functions that will stream data to/from a browser which is pointing to an SVG "webpanel" that I also built using Inkscape.  So far I have a simple waveform graph, buttons, LED's, progress bars, etc.  I have tested my Inkscape webpanels in Firefox 4.0 Beta and Google Chrome 9 and it works like a champ, and is very fast.  The old-fashioned LV webserver will serve up SVG files with the addition of a mime type. 

An alternative to SVG is the HTML5 <canvas> tag, which allows the rendering of graphics drawn using java/ecma script.  There is a free-for-personal-use script library called RGraph Library that you can download with lots of example code.  Here is RGraph/LabVIEW in action in Chrome 9:

So what is my idea?  

0. Ditch Silverlight.

1. Convert all of the nice-looking UI panel objects in the Web UI Builder from Microsoft XAML to SVG and distribute them with the  LabVIEW professional development license.  I am programmer first, and I admit my web panel objects don't look too good.

2. Design a script library for handling WebSockets communcation (or add native support for WebSockets to the Shared Variable Engine) and manipulating/updating the SVG UI objects from streamed WebSockets data.  Make this library open source.

3. Create a standard open protocol for streaming LabVIEW data that sits on top of WebSockets and is free and open.

4. Publish documentation for the SVG UI elements so users and thrid parties can create new UI objects.  Make use of the creativity of the community at large!

5. Modernize the Web Publishing Tool so that it will optionally output an HTML5 and/or SVG document that accepts streaming I/O from WebSockets.  The user could choose from compatible SVG elements to use in place of front panel elements on the VI being published.

6. Create a Web UI SVG element exchange for registered NI users to upload/download elements for free.

7.  Work toward the long term goal of adding SVG Import/Export to the control editor (with better editing tools), or make the CTL format of custom controls SVG/XML.

The concept of fluent interfaces using method chaining applied to a LabVIEW block diagram would be awesome!

When calling .NET libraries from LabVIEW, block diagrams explode horizontally - the aspect ratio of the diagram can easily push 5:1 or worse (it's 10:1 in the example below). Some Method Chaining syntactical sugar would yield a more space-efficient-and-readable 4:3 to 16:9 or so.

Property Chaining is already well-established in LabVIEW - let's get us some Method Chaining!

See the first comment for footnotes...

 I believe the number and age of "New" ideas on this exchange renders the word meaningless. I just Kudoed an idea that was 13 years old and marked as "Status: New". This idea would be in middle school; that doesn't sound particularly new. Inaction on an idea after some amount of time should automatically trigger some other status. 

I can't count the number of times I've seen this dialog :

Of course I want to continue, that's why I right-clicked the structure and chose Remove [Structure]!  This dialog must be a holdover from pre-Undo days.  Do we pop-up a dialog when you select your whole diagram and press <Delete>?  What about when you press Ctrl-B?  These actions have the potential to remove just as much diagram content as Remove [Structure].

Please get rid of this dialog, and just let us Undo the operation if we need to, just like we do all the other potentially destructive diagram edit operations.

I really like the new arrow feature with block diagram comments.  But in many cases, I have a comment that applies to more than one BD object.  So, I would like the ability to link my comment to multiple objects instead of just one.

This would allow me to turn this:

into this:

Thanks!

-John

To "reduce friction" in creating subVIs from portions of code, I suggest adding "Create subVI from Selection" to the block diagram contextual menu- rather than only having it in the titlebar menu.