LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
On my large monitor, the window size for the front panel and block diagram of a new, blank VI is much larger than those for most VIs that I would ever create.  So the first thing I do after creating a new VI is shrink down the FP and BD to something more manegeable.  Could we have an option for specifying the size of new VIs?

Unlike the scales of numeric controls, graph scales don't support text labels (wouldn't that be cool! :smileywink: ) *(see footnote)

 

It could be handled very similar to the way text labels are handled for the scales of numeric controls, so most of the code is already there.

 

This would come in very handy for e.g. histograms or bar graphs, where each bar needs a text label, or for cases where we have arbitrary units.

 

Examples for integer scales: 

  • "January", "February", ...
  • "LabVIEW users", "CVI Users" ...
  • "Europe", "Asia", ...

 

Examples for floating point scales (x, or y):

  • "Too cold", "cold", "warm", "hot", "too hot"...
  • "small", "medium", "large", ...
  • "min", "max"...
  • "high frequrency", "low frequency"...

 

*My quote from this old discussion . See also Ben's example further down.

Right-clicking on a case structure, we still have the option to convert a case structure to a stacked sequence.

 

I would prefer if this option would disappear without a trace forever :D. It has no purpose in life!

 

Nobody should ever use that option! It makes no sense!!! 😄

 

 

(I would probably retain the option to convert a stacked sequence to a case structure)

The argument is similar to what falkpl suggested here. The issue is refactoring old (pre event structure) code.

 

Many times I had the need to convert a multi-case case structure to an event structure where each event case duplicates one of the original cases. This is currently hard to do and involves a lot of copying and wire mending.

 

Of course the conversion cannot do any event assignments so things will be broken, but for me it would be sufficient to create the new event structure as a 1:1 "event-case":"plain-case" conversion of the code contents, without any events assigned. (This must be trivial in terms of code!) Assigning the events later is easy.

 

For symmetry, the reverse operation ("replace event structure with case structure") should also be available.

For no obvious reasons, the "array subset" and "string subset" nodes are currently not resizeable.

 

Many times, I need to get several subsets or substrings at once and resizeable nodes would be a welcome improvement. Thanks!

Message Edited by altenbach on 06-05-2009 03:53 PM
Message Edited by Support on 06-08-2009 09:07 AM

Anyone that refactors code from another programmer has probably received some code that has too many sequence structures.  Often I convert these to a simple state machine.  With scripting this could be easily converted to a state machine for loop.  A default enum type def could be created to do a state machine sequence 1 -> 2 -> 3 -> 4 ->5 -> ...last sequence in structure.  All sequence locals could be replaced with either a local or a shift register (that will bypass all other cases where it is not used). 

 

Why would I want this?

 

Sequences are over used and it is well documented that state machine architecture can provide many benefits over the static and simple sequence.  Many programmers are un aware of these benefits and don't understand data flow so use sequences  to force execution order.  Sometimes sequences are convenient early in the prototyping only to find the known shortfalls of this programming paradigm.  When this happend dont worry, just right click on the sequence structure and click convert to state machine.  This could make refactoring code easier, at least in my mind (but is late on friday and I am ready for the weekend which could cloud my thought process).

 

 

Add functionality/property to allow a cluster to have a scroll bar.  This way, long clusters with many elements can be shrunk down to a manageable front panel size and a scroll bar would navigate through the cluster elements.

One ugly way i usually have to code is  

 

Example_VI_BD-1.png

 

A better way would be to be able to wire, a wire to every function.

This wire will carry data, but it will not pass them in the middle function. It will be a bump input-output, just to determine which function to be executed first. There should be an indicator, when this dump input-output is activated. It can be activated with right clicking on the icon.

Example_VI_BD.png

 This wire should be able to be, a dump wire without any data so you can impliment this

Example_VI_BD.png

The images way not be so nice, but that's the idea..

 

 

I, like many others I am sure, have multiple LV versions installed on my computer.

 

I have often wished for a small launcher program (linked into Explorer.exe under Windows) which has a peek to see what version a VI (or ctl or whatever) is BEFORE calling the respective LV version.

 

It could also have an option to show a dialog whenever a VI is double clicked in a version different to a version of LV which is ALREADY open asking if it should be opened in the native version or in the currently opened version.

 

An alternative would be to treat VIs opened from a different version as locked (read-only), forcing either a manual setting of write permissions or saving under a different name.

 

Shane.

Tabbing will work for clusters on the front panel, currently we are using "Ctl+Down arrow key" to focus control in the cluster "Ctl+Up Arrow Key" to come out from the cluster

 

For use Tabbing feature for clusters, I need to use "Ctl+Down arrow key"/"Ctl+Up Arrow Key".

 

While tabbing on the front panel is there any way LabVIEW automatically detects the Clusters and it will directly focus the first element of the cluster and when you click Tab on last element in the cluster it will come out and focus the next availble control outside the Cluster (if next control is again Cluster it will focus the first element of the next cluster)

For distribution, only package necessary libraries in installer packages built with the project. A lightweight UI, server, or client does not need a full 70MB+ installer that bloats out to a few hundred MB's once installed! A colleague has remarked that the total size of our LabVIEW application+RTE EXCEEDS the entire size of the XPe image running on the embedded computer! This becomes an issue when distributing software upgrades to places in the world without high-speed internet connectivity.

Provide a way to compile an xcontrol, to have only 1 file to distribute.

The radio button control acts like a cluster container for booleans with some fancy logic behind it. Refactoring old code, we might have a bunch of customized booleans that we want to stick in a radiobutton control during refactoring.

 

For some unknown reason, we have to first drop at least one of the desired booleans into the control before we can delete the last one of the default controls that were already in there. I think we could get better work flow when doing these edits if we remove this random barrier that forces us to operate in a certain order. It would be nice if we could first empty out the radio button control and then drop all our desired customized controls in it. Of course a VI with an empty radio button control should probably be broken.

 

In summary, an empty radio button control should be allowed at edit time. We should be able to temporarily remove all existing content. Currently, LabVIEW won't let us remove the last remaining element if we try to do so.

 

(Hopefully, this is a trivial change and not something that would require lots of changes to the existing code) 😉

 

 

A few upgrades to  runtime menus would be nice.

 

1.  Allow for visibility on menu items.  Currently there is only the ability to disable or delete a menu option.  Disable is not often what is needed but deleting a menu item requires rebuilding the menu programatically.  Why not just have a show hide property on each menu item.

 

2.  Allow for a glyph/icon to be added to a menu item.  This is similar to list boxes.  The advantage here is that a psuedo-toolbar could easily be created using a menu.  Also modern menue systems are adding this feature so me should have it in our toolbox as well.

 

3.  Allow for detachable menus.  This could be a stretch to ask for since it is more difficult to implement.

 

Change the VI Properties Dialog to be able to reach the desired option with a single click, Instead of using the drop down menu.

 

It will be more clear and fast to access properties. 

 

VI Properties.png

 

OK, this may be a bit of a way-out-there suggestion but here goes.....

 

There are times when I would really like to be able to create some kind of "overlay" for an entire FP.  I'd actually like for an overlay for the entire available screen, but let's not get TOO far ahead of ourselves.

 

Uses may include user direction (highlighting in RED) or some menu-like interaction or whatever....

 

I know this can be simulated using a picture control but then all user interaction goes to the picture display which must be on top for it to work....

 

Or how about something like the Wafeform graph with Back Middle and top pictures available.....

 

Shane.

Who has ever made a cluster typedef, then added some elements, then added more, then a little more? Have you noticed the "typedef explosion" of your block diagram as a result, with constants overlapping other code? Make a right-click option to "link" a bundle by name to a typedef. Note that the two pieces of code below would be identical, but the bundle on left would not suffer from typedef explosion. In addition, have a selectable menu

LinkToTypedef.png

 

Another idea is to link the bundle to the destination:

 

LinkToDestination.png

 

 

Quite often I find myself running a new bit of code which contains an untested modal subvi somewhere in it's bowels, to find that the when called the modal subvi doesn't exit. Clearly there's a little bug in my code, but now I'm stuck. The modal vi has all the focus of LabVIEW, I can't close the vi, I can't abort the vi. Nothing is accessible, including the Project Explorer window.

 

Now what I need here is a LabVIEW Running VIs Task Manager, which allows me to simply scroll down a list of open and running vis, and abort the one that's stealing my focus.

It would probably have to operate outside the development environment to avoid being supressed itself, but presumably a standalone executable can link into LabVIEW through the server port and access the list of running vis with server calls.

 

This would save me from having to use Windows Task Manager and killing LabVIEW (and potentially any unsaved work)

I have often wished that LV have some easy way to display simple text with parts of the text marked BOLD, Italic or different colour in one display.

 

I think there has been an XControl created fror this, but it's be nice to have a proper "formatted Text" indicator / Control in LabVIEW.

 

No picture as I think everyone knows what is meant.

 

Shane.

The Skip this control when tabbing property is unchecked by default when adding a control to the front panel.

 

However, in the majority of my applications :

  • Most of the VIs are invisible and the tab behavior is not used. Therefore, the setting is irrelevant.
  • For most of the controls of the UI VIs, the default setting must be changed (all controls outside the visible part of the front panel...) 

 

It would save me some time by checking this property by default. But I wouldn't be surprised if other developers had the opposite opinion ! So add this property to the LabVIEW options to allow us to set it according to our needs and preferences.