LabVIEW Idea Exchange

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

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

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.

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.