LabVIEW Idea Exchange

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

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

Hello everybody,

 

(as suggested I will separate my idea Expand the functionality of Event structures into four seperate ideas to allow giving kudos separately.)

 

Make it possible to add conditions to events, e.g. only allow event foo, if condition bar is True. I'm not sure, how this should look like. Some static conditions could be "key pressed == a" coupled with "key down" event. Conditions could also be coupled to controls via registering the control reference like dynamic events. If my idea Expand Event structure functionality: Register new types of references is realized, a condition could also be something like "tcp/ip connection is offline". If a condition is not fullfilled, than either nothing happens or there is a leftside node, which indicates the status of the condition. This should be configurable.

 

Regards,

Marc

Hello everybody,

 

(as suggested I will separate my idea Expand the functionality of Event structures into four seperate ideas to allow giving kudos separately.)

 

It should be possible to configure events to run first (placing the fired event as the next event to execute like the queue function "Enqueue Element At Opposite End"). Or add priority to events.

 

Regards,

Marc

Hello everybody,

 

(as suggested I will separate my idea Expand the functionality of Event structures into four seperate ideas to allow giving kudos separately.)

 

Allow for better handling of the event buffer for fired events of Event structures. I would like to have a feature to list and remove item(s) from the buffer of fired events. Otherwise you have always to write some code to catch events, you d'ont want just to execute or you want to remove, because you just pressed the stop button. This could be realised by new leftside and rightside nodes inside the event structure.

 

Regards,

Marc

Hello everybody,

 

(as suggested I will separate my idea Expand the functionality of Event structures into four seperate ideas to allow giving kudos separately.)

 

Make it possibly to dynamically register references like tcp/ip, visa, queues, etc. for Event structures. Possible events are "new bytes at tcp/ip", "new bytes at seriel port", or "connection closed". In the case of queues it could be the same function as "Dequeue Element" or "Queue referenced closed". There are certainly a lot more of similar references, which could be registered for catching events, which up to now we have to poll regularly or use other event functions (as in the case of visa -> new bytes at seriel port). Benefits are: no more regular polling of changes, better integration of several functions (like using queues to communicate with GUIs instead of dynamic user events), and in my opinion just better code.

 

Regards

Marc

Hello everybody,

 

here are my ideas about expanding the functionality of Event structures:

 

1.) Make it possibly to dynamically register references like tcp/ip, visa, queues, etc. for Event structures. Possible events are "new bytes at tcp/ip", "new bytes at seriel port", or "connection closed". In the case of queues it could be the same function as "Dequeue Element" or "Queue referenced closed". There are certainly a lot more of similar references, which could be registered for catching events, which up to now we have to poll regularly or use other event functions (as in the case of visa -> new bytes at seriel port). Benefits are: no more regular polling of changes, better integration of several functions (like using queues to communicate with GUIs instead of dynamic user events), and in my opinion just better code.

 

2.) Allow for better handling of the event buffer for fired events of Event structures. I would like to have a feature to list and remove item(s) from the buffer of fired events. Otherwise you have always to write some code to catch events, you d'ont want just to execute or you want to remove, because you just pressed the stop button. This could be realised by new leftside and rightside nodes inside the event structure.

 

3.) It should be possible to configure events to run first (placing the fired event as the next event to execute like the queue function "Enqueue Element At Opposite End"). Or add priority to events.

 

4.) Make it possible to add conditions to events, e.g. only allow event foo, if condition bar is True. I'm not sure, how this should look like. Some static conditions could be "key pressed == a" coupled with "key down" event. Conditions could also be coupled to controls via registering the control reference like dynamic events. If my 1st idea is realized, a condition could also be something like "tcp/ip connection is online". If a condition is not fullfilled, than either nothing happens or there is a leftside node, which indicates the status of the condition. This should be configurable.

 

Regards,

Marc

In the world of robotics, underwater vehicles, autonomous systems and more...there's a need for a few more UI controls that turn into quite a hack with the current picture control implementation. To quote a few of my new friend (Philbot and PJM_JKI)...

 

We need 1) A Compass (see attached image), 2) A way of displaying Pitch and Roll (like an artificial horizon) 3) A way of displaying thruster control (usually tie to the Pilot joystick)

...quoting PJM_JKI directly..."If there are no new native controls added, I would request improving the Picture Control (this would, in general, be a very good thing for LabVIEW). For instance one can create their own control using the picture control (see attached image of the compass we put together using this technique), but there are several limitations that requires a lot of work to overcome.

 

Picture control improvements:

 

  1. Performance (I think it will make a major difference if the Picture Control would use OpenGL Hardware acceleration for instance).
  2. Support for alpha transparency.
  3. Support for drawing antialiased object (such as lines, rectangle, circle, arc, ....)."

Something as cool as this is possible...but with a lot of work (from PMJ_JKI): 

My basic idea/complaint is to allow the mouse wheel to scroll the contents of a string control or indicator.  The mouse wheel works in other controls, like the listbox and the tree control but for some reason does not work on string controls.

 

More generally, I would like more effort placed on adding GUI features to LabVIEW that bring it more inline with the UI conventions of each OS it runs on.  For example, in windows, it would be nice to have toolbars supported natively instead of having to 'hack' together something that works like a toolbar.

 

My overall goal is to give LabVIEW developers the tools to create professional user interfaces that are at least up to par with other competing languages. 

By default, the mouse scroll wheel scrolls the block diagram or front panel vertically, CTRL+SCROLL scrolls through cases/events/sequences and adding the SHIFT modifer to either accelerates the scroll. In order to scroll horizontally, however, the mouse has to be hovering over the horizontal scrollbar. Because of the predominant left-to-right, top-to-bottom style of diagram organization, it would be excellent to have a more accessible way to scroll horizontally.

 

I haven't found anywhere ALT+SCROLL is used - I think horizontal scrolling is a good candidate to fill that spot.

 

 

I would love to be able to draw a box over a bit of code on the block diaghram and be able to highlight execution just for what's in the box. The rest of the code should execute at full speed. This frequently becomes an issue when you are trying to track down a bug in a big program and you've got to wait for ages to get to the bit your interested in.
The Index Array function should have an option (possibly default) to require that the index be wired. Forgetting to wire it up is a very common source of bugs and it's hard to find.  The autoincrementing feature when you grow this function is cool and should be preserved, but 95% of the time, I need to have the index wired in.
The venerable Array Size function should just resize itself for the number of dimensions on the input array and have each dimension's size emitted with a separate scalar output.
I would love it if the Call By Reference node had a "don't wait until done" option, so that we can stop using the inconvenient and inelegant Set Ctl Val method or other inconvenient ways to pass arguments to dynamically called processes.

 

I believe the main issue with this is what to do with the outputs from the subVI (since you won't be able to use them) and I can think of two options:

 

1. This option would be settable at edit time and would break the caller if you wire any of the outputs.

2. This option would be settable at run-time and you would get default data from the outputs and an error or warning from the error out terminal of the node if you wire any of the outputs.

A great time saver would be if we could drag or click to switch connections directly in the connector pane instead of having to disconnect and reconnect controls.

 

This can be a simple two click process:

 

Switch Connections.png

 

If there's already another control\indicator where you click, they get switched.

Right now a left-click on an icon connection pane with the operating tool (the finger tool) just highlights the connected control or indicator.  It would be much more useful to have a drop down with the most common choices, especially the required/recommended/optional/dynamic dispatch selection.
Be able to open the block diagram with a hot key or right click menu even when you use custom menu on user interface. This option should be available for debugging in development environment and when debugging an executable with debugging enabled.

Having the possibility to hide a pane at run time. For example if you want to hide a Button Palette, a status bar, Tree View or helper pane as specified in this snapshot:

 

 HidePane

Message Edited by Support on 06-02-2009 12:35 PM

Dany (below) requested support for alpha channel in picture control (I strongly agree with that). I also want support for drawing antialiased object (line, rectangle, circle, arc, ...).

Additionally, improve the performance of the picture control rendering will be greatly appreciated.

 

PJM

Sometimes I like to have the Context Help window viewable to my users so they can hover over FP elements and get some quick pointers on their respective functionalities.  I'd like to be able to control the position and size of the window, and also choose programmatically when it's floating/not floating, so I can have it blend into my user interface more intuatively.  It'd be great to be able to embed it into a subpanel too.

This goes a bit with Christian's suggestion to separate edit time and run time front panel sizes.

 

While I do appreciate the alignment grid on the front panel I find it insufficient a lot of the times. What I would like to see is some alignment helpers similar to the ones that are provided in the form editor of MS Visual Studio:

 

  • When you move a control close to another control, it automatically displays a standard distance "helper" that you can snap to.
  • When you move the edge of one control close to the edge (in one dimension) of another control a vertical or horizontal line is drawn from that other control to which you can snap, regardless of whether it happens to sit on a grid line or not. 
  • When you move a control close to the edge of the front panel a standard distance "helper" is displayed that you can snap to.


All of these features should be available for a move as well as for a resize of the controls.

 

You can find screen shots of what I am talking about here and here.