LabVIEW Idea Exchange

Whenever I'm working on let's say a state machine I find that I need to resize the case structure now and then. Mostly make it larger, then I clean up my code and want to make it smaller again. Often when I do this, the constants (usually) pointing out the next case either get longer wires since they get further away from the border (when making the structure larger), become hidden (structure made smaller and no auto-grow) or prevent the resize (auto-grow enabled).

A solution to this would be to be able to lock BD objects with respect to the nearest corner of an owning structure, in the same way the loop index terminal is locked wrt to the corner of a for or while loop.

 

Problem - Bundle by name causes unnecessary wire bends because the type specifier is on the top.

 

Make the type specifier terminal on the upper left and the output on the upper right. Also right clicking on an item will allow you to select "Change to Read" or "Change to Write".

 

Would look something like the following.

Hello all,

 

This is a rather non-technical request.  When classes are created from Project Explorer, a color is assigned by default.  If that's a color you're fine with, you hastily modify the icon and move on to more important matters.

 

While the color assignment works well enough to serve its mundane purpose, I've noticed several weaknesses:

 

1. The object "cube" icon is not so easily edited because of its pretty, blurred lines and several colors.
2. As far as I can tell, there are exactly six color families that LabVIEW assigns to classes: "goldenrod," blue, green, red, yellow, and purple.
3. Depending on the order you make your classes in, the colors can introduce confusion.  e.g. What if three layers of inheritence are all blue? Not a big deal, but confusing nonetheless.

 

My suggestion is this, and maybe there's a better way to do this:

 

In the class properties dialog, why not allow the user to simultaneously assign a color scheme to the icon and the class private data ("cube") icon, in one quick step?

 

This would adjust the hue of the "cube" icon and the VI Icon Template at the same time.  It could also optionally modify the wire color accordingly.

 

Leave everything else on the UI as it is - this would be a new feature in addition to that pre-existing methodogy.

 

Thank you as always,

 

Jim

 

Note: For the sake of simplicity I chose the color picker dialog that LabVIEW uses everywhere else.  Any of several other methods could be used, such as a pulldown menu with predefined color names and swatches.  (Say, a dozen selections)

 

 

Related ideas I came across:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-the-color-of-different-classes-in-the-project-explorer/idi-p/1958803

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Class-ICON-update-to-Class-wire-scheme/idi-p/2516440

Viewing this suggestion requires a bit of setup

1. Forget you know what Silver controls look like
2. Think about it from a user point of view
3. Imagine a set of indicators including a sole boolean indicator show up on the screen. You have no comparison to other states of the boolean indicator.

Is it True or False?

 

 

 

 

 

 

My opinion is that the gradient and lighter shade of green makes the state a little ambiguous. Not too much ambiguity, but enough to give me pause. Decreasing the gradient and darking the shade a little should help.

 

Yes, I realize this is a property you can set. This is more of a suggestion for setting the standard.

(this suggestion aside, my compliments to the designer of the Silver controls)

I often have code in my apps where some error-out nodes are not wired, simply because the errors are generally not of interest to me or the error wiring would clutter up my block diagram. Typically this happens a lot in UI handling code where a lot of property nodes are used. For these parts I would rely on the automatic error handling for debugging purposes. One of the drawbacks of this method is that program execution is suspended when the automatic error handler kicks in. Even worse if this happens for code that is in a loop. You're only option then would be to abort the app, which e.g. is no good for your reference-based objects, etc.

 

I would love to have the ability to just specify my own 'Automatic Error Handler', enabling me to decide what to do with the unhandled errors. Just logging them is what first comes to mind, but maybe also do some special stuff depending on the type of error, just like a 'normal' error handler. I want to be in control!

 

Added values of this is that your application then has a catch-all error handler which enables you to at least log every error that occurs, even if not wired through. (Everyone forgets to wire some error-out that they actually did want to wire one time or another don't they? ;-))

 

Ofcourse the proposed setting in the image would ideally also be available programmatically by application property nodes.

 

Putting a comment next to a shift register item is something that I frequently do, and is frequently done in NI sample code.  (See Quadrature Decoder with Position & Velocity - NI 9505 (FPGA).vi as an example of this.)  The trouble is that when you move the shift register, the label doesn't go with it.  I would like a right-click option to add a label to a shift register.  The label should have a default position on the inside of the loop above the shift register, but options to locate it on the left or right, and inside or outside the loop.  It should also be able to be moved around like any label in labVIEW.  But is should stay in the same relative position to the shift register when the shift register is moved.  And if a labeled shift register is duplilcated, the label should also duplicate with an added extension number to make them distinct, just like duplicating a control or indicator.

It'd be great if when sorting a column of items (say in the Multiple Variable Editor, or a table of data), the values were sorted using a numeric sort rather than a literal sort (ie. DI10 should not come after DI1, and DI20 should not come after DI2).

 

 

There could also be a specialised string sort function which takes in a string array and provides an option for a numeric or literal sort.

 

 

What happens when you want to change a Border Node on an IPE? It is a manual process which I propose can be automated as shown in the two examples I have provided...

 

---

 

 

 

 

When a control is disabled, especially a large table or string control, it would be nice if the scroll bar would remain active in order to view the contents of the control, without the ability to actually change it.

 

I am not asking that the default behavior be changed, however a right click property/property node "scroll when disabled" would certainly have some value.

It would be nice to add another dimension to the system exec.vi that gives the user the option to open up the “Run as Administrator” command prompt in Windows 7.  This would enable a system administrator to use LabVIEW to make certain, currently restricted, changes to the computer.  I don’t believe it would create a security risk because you have to be logged in as an administrator anyway to have the access rights

 

As far as I’ve seen, there really is no string that you can enter into the command line that will instruct an elevated command prompt to open.   With this added functionality in the system exec vi, however, you will be given more flexibility with what you can do through your LabVIEW program.