LabVIEW Idea Exchange

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

I tend to use malleable VIs more often than half of the items in the "New" context menu list when you right-click within a project, however, it's not an option:

_carl_0-1635193396358.png

Instead, I either need to:

- Create a new VI and then make several property modifications, and save it as a ".vim".

- Create it through the file menu and then remember that I need to move it to the appropriate place in my project, because it gets created at the top-level.

 

Why not include this in the context menu?  (Bonus points if Polymorphic VIs get added too!)

 

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.

 

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

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

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.

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

 

remove.png

 

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 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 just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.

 

The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.

 

I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections

-OR-

Be able to select multiple cases from the "Rearrange cases" window and select "Delete".

Similar to 'Insert' and 'Delete' methods, please include 'Transpose Array' method as shown below:

 

Method to transpose the array

 

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.

As mentioned at the end of my comment here, editing text is a bit clumsy. There should be a text toobar that is similar to what we can find in any other application.

 

Maybe it could be dynamic so it only appears when editing text.

 

Here's the quote from the other thread:

 

One thing that should be improved is the font pulldown which feels so early 1990's. When working with text, we want a text toolbar like anywhere else, (even in the post editor here in the forum!) with a bold, italic, etc. buttons, font and size rings, etc. You know what I mean!

Simply put, you should be able to put a URL hyperlink in a floating comment to link out to some site.

 

Imagine being able to add a hyperlink to the mathematical description of a VI that you used. Perhaps you have an internal server of IP Documentation. You could add a hyperlink to that in depth information directly in your VI. Perhaps you want to put your logo along with a link to your website at the top level of your source code. Whatever the reason, you need to be able to add a normal comment to the block diagram and populate that comment with text and hyperlinks.

 

As a extension, this new comment field could even take simple html tags for more formatting, embedding images, or maybe even an embedded video.

 

 

Comment_with_hyperlink.png

Message Edited by Rick K on 09-17-2009 12:06 PM

I am probably not alone in my trepidation in using the Block Diagram Cleanup tool, but I can not help but recognize its power to be a tremendous help.   We already have tools (Grids, Align and Distribute, Ctrl-T QD shortcut, etc.) to get Nodes and terminals positioned nicely.  Even with this idea in Beta, wiring can still be a tedious chore.  The BDCT does a reasonable job routing wires, but also moves things around including control/indicator labels, and is often unsatisfying.

 

What I want is to be able to lay out the BD, wire things while only worrying about beginning and end, and then have the BDCT only adjust the wire routing.

 

Despite numerous RCF shortcuts and new behavior in LV10, this is not the same as cleaning wiresThe solution is not to methodically select only wires and Ctrl+U.  The reason:  the process should be a global optimization, not a serial process where each wire route is chosen based on the current state of the BD.  The BDCT uses a global optimization, 'Cleaning wires' does not.  What I want is the optimization of the BDCT limited to only wires, leave my nodes and terminals and labels alone!

 

For example see the following:

 

RouteWires.PNG

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.

There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:

 

NXG Style Path.png

 

Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.

So, i just changed a case from a string input to a boolean input. Ofcourse it gets broken with a red "1" in the case selector. That's logical. 

Now i need to select the case selector and write False, then switch to the other and write True ...  

Once both cases are correct i can r-click and switch them with a "Make this case False".

 

Improvement suggestion:

If having a boolean input, the Make this case True/False should be active for all cases always.

Even if you have multiple cases (it'll still be broken and you'll have to clear the extra cases)

Why dont wires have an optional label associated with them.  Style guides have use label long wires but wires have to be moved often during development, and the labels are not fixed to the wire.  This should be maintained for us.  Right click on wire and add label, with ability to lock label to wire source, wire midpoint or wire destination.

 

Message Edited by Support on 06-03-2009 03:26 PM

I find often the need of creating array indicators with many elements, and of labelling them is a way which allows easy identification of the element index.

Normally the labels of the elements can be made visible, like in the left example shown:

 

array index labelling example

 

One way of doing it, if the array has a fixed size, and all of the array is shown at once, is to juxtapose a set of text labels identifying the elements. Tedious to build.

 

If the array changes size, if it is larger than shown, if it is supposed to be scrolled on the FP, static labels are useless. Currently the label of the element can be made visible, but all elements share the same label. The index display of the array can be shown, but it relates to a single element, which makes cumbersome to identify elements of long arrays.

 

I usually resort to more sophisticate contraptions, like arrays of clusters, each composed of the element in question and of a numeric indicator; or to two parallel array indicators, one for the elements itself and one for the indices. Both solutions are more cumbersome to build and to size and align equally; the index content has to be prefilled and maintained in sync when array elements are added or deleted (programmatically or via contextual menu); in the second case, a lot of events have to be trapped programmatically, for instance to maintain synchronism when the main array is scrolled.

 

What I would like to have is an additional label natively visible, showing the element index, like on the right.

The labels could be made optionally visible with a contextual menu ---- left click->visible items->index label.

Options (perhaps properties) in order to set the value of the first element (e.g. 0 or 1 or any other value) and the step value if different than 1 would also be useful. Standard options about location and orientation of the label with respect to the array element would apply.

The function Index & Bundle Cluster Array can be quite useful and mimics a bundle in a for loop.

 

The reverse operation (= unbundle in a for loop!) would be equally useful.

 I wonder why it is not part of LabVIEW. Seems like an omission. 😉

 

I suggest to add it with the same icon graphics, but with left and right halves swapped.

 

(See also this example)

Message Edited by altenbach on 06-17-2009 01:21 PM

Similar to how array and cluster constants on the block diagram can be edited, it would be useful to be able to edit map and set constants on the block diagram.

 

For example:

tannells_0-1581381337525.png

In the map constant above, the developer can scroll through and see all of the key value pairs in the map (plus an empty element at the end of the map).

 

It would be useful to also be able to edit the key-value pairs in the map (and add more key-value pairs to the map by changing the empty element at the end of the map).