LabVIEW Idea Exchange

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

Hi,

 

i propose to add a "Key Focus" event for each control. We already have Mouse events (leaving, entering) - but when the user (or the programmer) prefers the keyboard (with proper tabbing setup) you have to poll each interesting control for it's "Key Focus" property to initiate a user event...

 

So please:

Add a "Got Focus" (and additionally a "Lost Focus") event to the event structure!

The idea is simple: if the label ends in a number (i.e. consecutive string of numeric characters), increment that number:

 

Control auto numbering.png

 

It seems like it only works if there is a space character. If there is a good reason for doing it that way, help me understand what it is.

 

I linked some similar ideas below. I like these discussions for the most part, but they tend to have broader scopes than what I'm suggesting.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-er-automatic-label-names-on-copy/idi-p/1873663

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Auto-increment-number-in-middle-of-control-name/idi-p/977710

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-skip-quot-1-quot-during-automatic-naming-of-copies/idi-p/977300#A2089

Show the Context Help for packed project library VI terminals. Without it, development suffers. For example, a wire conflict occurs but the nature of the source or sink type is not available for inspection.

pplhlp.bmp

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:

 

_carl_0-1614272545841.png

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.

LabVIEW could use a feature that's commonly used in C++, the "final" specifier for a class override method.  This would allow a child class to override a method from a parent class (or interface) and then prevent child classes of itself from overriding.  Currently, with large inheritance structures, it becomes difficult for developers to create child classes since so many of the methods can be inherited from.  The final specifier would allow you to create intermediate classes that define certain override functionality that does not need to be further overwritten and only pass on the ability to override methods that are important to child classes.

FInal Override.png

While debugging LabVIEW, we often have many VI windows open. It can sometimes be difficult to manage these windows, especially once the debugging session is over. I think we can improve this situation greatly with a minor change to the All Windows dialog. This dialog (launched from the 'Window' pull-down or by pressing Ctrl-Shift-W) currently shows a list of all LabVIEW windows that are currently open:

allw.png

There are several columns of information describing all the open windows, and the list is sortable by clicking a column header. You can multi-select in the list and click 'Close Window(s)' to close multiple windows at once.

 

Idea: If we add a "Time Opened" column that lists time stamps of when the windows were first opened, it would be easy to sort by that column, then close all the windows that were opened during a span of time, i.e. while debugging. 

 

While we're at it, there are several other usability enhancements that could be made to this dialog that seem to be low-hanging fruit:

  • Make the window a non-modal floater, with the list dynamically updating as windows open and close.
  • Add a 'Minimize Window(s)' button.
  • Give useful key navigation to the 'Close Window(s)' button (and any other buttons we may add).

I know there are other ideas about making debugging easier (don't show panels, etc.). I'm scoping this idea to improvements we can make specifically to the All Windows dialog to make debugging easier.

Right now, if you happen to use the right colors, LabVIEW will change the text color on a Boolean.  But, if you don't pick the right colors, LabVIEW keeps a single text color.

 

Boolean Text.png

 

 

This would probably be fine IF LabVIEW allowed you to have multiple text colors, but you can only choose one:

 

Boolean Properties.png

 

But, as you can see, LV only supports one text color.  I propose that LV support two text colors (ON and OFF).  Obviously LabVIEW has the ability to change the color already since it will do it in the right circumstances, but it would be nice if LV gave us control over it.

 

In my use case at the moment, I am trying to make a custom illuminated button which the text on the button should be grey went off, and yellow when on.

(note: this idea is similar to this one, but different enough that I thought it warranted a new post)

 

LabVIEW 2019 will include a Clean Up Front Panel feature that repositions front panel objects to match their positions on the (already wired) connector pane. I think we should also consider implementing the opposite behavior, where you can arrange your front panel the way you want your connector pane, then assign that arrangement to the (currently empty) connector pane:

cp.png

I envision the gesture used to employ this feature would be a Quick Drop Keyboard Shortcut, an entry in one of the drop-down menus, or a right-click on the Connector Pane.

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:

Multiple comment before.PNG

into this:

Multiple comment after.PNG

 

Thanks!

 

-John

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!

 

LabVIEW-Idex-Proposed-Fluent-Interface-with-Method-Chaining.png

 

See the first comment for footnotes...

Cluster Size as a Wired Input:

 

  • Easier to see
  • More implicit
  • Nearly impossible to forget to set it (if it were a required input).

 Cluster Size.gif

One of the most common operations performed on arrays is to determine whether an element is found inside the array or not.

 

There should be a function that is dedicated to this fundamental operation. My workaround is to use the "Search 1D Array" function followed by a "Greater Or Equal To 0?" function, as seen below. While it only takes a few seconds to drop the geqz function using Quick Drop, it's still slightly frustrating that this is necessary.

 

The set and map data types rightly have been given the "Element of Set?" and "Look In Map" functions. An equivalent should be provided for arrays.

Element of Array - edited.png

 

Thanks! 

Please let me opt out from this new feature, introduced in LabVIEW 2017, permanently in the setup dialog.

Using LabVIEW for a very long time (since LabVIEW 2.0), I never wished such a feature (it got only 27 Kudoes) - and - I am even using it's "anti feature", implemented up to now, constructively to detach objects (Pull control into a structure, connect it to the new target - and "Ctrl B").

This new feature, forced onto everybody, would be less annoying, if pressing "W" would reliably disable the feature. However,  at least in vritual windows machines (Parallels) on a Mac, it does not work 50% of the time.

 

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.

Menus.PNG

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 sometimes delete controls from the BD and realise some time (from milliseconds to minutes) that I have some broken local variables.

 

I get greeted by the hugely informative imagery as shown below:

 

BRoken local link.png

 

Yeah, good luck realising what exactly you deleted by mistake.  No name, no way of finding out what the local PREVIOUSLY linked to.

 

I suggest retaining at least the name of the Control / Indicator the local was linked to so that the poor programmer (me) has some fighting change of undoing the error.  Bear in mind there could be many changes made to a VI before this kind of thing is notices so a simply "undo" fix could end up being VERY awkward indeed.

 

An example of how this could look:

 

Broken Local hint.png

 

Here I at least know WHAT I have deleted by mistake.

I often use LabVIEW projects.  Projects may contain libraries, classes, etc.

 

Changing the contents of any component (such as a library) within a project causes the project file to change -- even though the project definition itself shouldn't have actually changed. For instance, if this is my project:

_carl_0-1656622304965.png

and I delete a VI that is inside an .lvlib, the project file itself claims to have had an attribute change:

_carl_2-1656622426038.png

_carl_3-1656622515498.png

In theory, this top-level project change isn't necessary -- since the project should just reference the library, and only the library should reflect a change.

 

These unnecessary file changes make it trickier to deal with source control, merging code, tracking changes, etc, along with adding one more file that you get prompted to save every time you close a project.

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. 

 

Screenshot_5.png

 

 

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:

 

 

Screenshot_7.png

 

 

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.

 

There is a strange asymmetry in the conversion pallet:

heel_1-1628866756838.png

 

I cant see any reason why it is not supported to use the type conversion on an array of FXP when it is on an element. It should be either none or both.

 

The proposal consists in being able to format the content of a string control, to allow to read more easily: INI, XML, HTML, ...

 

Code Formatter.PNG

 

Regards.

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).

 

Decoration Explicit Reference.png

 

Note: Thanks to TonP for the idea.