LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Connector Pane Overhaul

It has been mentioned before (here, and here, and here) that there are some problems with the connector pane. Let me add my suggestions. Does the image below ring a bell? WHAT GOOD ARE ALL THOSE CONNECTOR PANES FOR?

I suggest the following view:

The "Define New Connector Pane" will allow you to contrive custom panes to suit your fancy. It could have templates of the current connector pane collection. Below is a pane you could create with the new editor (I would suggest combining the Icon Editor with the Connector Pane Editor!!!!). The only constraints that need to be imposed on a connector is that it is rectangular and touches the edge of the icon. Otherwise, you can make it however big you want it (for all the myopics out there like me!), and wherever you want it.

Two new concepts are introduced above: empty space, and the ability to land a wire NOT directly in the center of the connector. Placing the landing as close to the center as possible would alleviate the current problem of the "gapped wire" that does not touch slim icons (look at gap on top input and the output).

View All (6)

The current boolean diagram constant is potentially confusing and too elaborate.

Confusing, because it almost looks like a toggle switch, so the new user might click on the right half, expecing an unconditional FALSE. However, there are no active areas, and an inversion of the current value occurs no matter where we click.

Too elaborate. All we need to see is the current value! Why do we need to see the "other" value greyed out??? We can guess that by simple elimination. 😉 There is too much redundant information, wasting twice as much diagram space than actually needed to display relevant information. The current design also makes e.g. 2D boolean diagram constant very confusing. Have a look at the image. Can you immediately tell that the 2D array on the left is only true on the diagonal? (I did not think so!). Now look at the suggestion on the right. Ahh... much better! 😄

Suggestion:

The boolean diagram constant should be smaller, simpler, and cleaner.

The image shows the current design on the left and the suggested design on the right.

What a difference in clarity and economy!!

Message Edited by altenbach on 07-03-2009 02:39 PM

View All (1)

Make the default probes smarter

Custom probes are great, however unlike the default probes you do not always have them with you...so why not just make the default probes just a tad smarter?

- The array probe e.g. should not just show a single cell - it should by default show at least some of them (1*10 for 1D, 10*10 if 2D etc. e.g.), have it's scrollbars visible and be resizable?

You could add some core information about the array, like it's size e.g. in an indicator on the top as well....and perhaps have a pull-down menu for the display format. Keep it general and simple of course, but a bit more convenient than today's probe.

- The string probe should also be resizable and have a control that let's you switch the display format.

- etc.

View All (3)

The property node has two major advantage over LVOOP - it allows placing a lot of function calls in a horizontally limited space and it uses text, which is MUCH clearer than small icons (IMO) for something like this. It would be nice if LVOOP had support for this as well.

The implementation I'm thinking of is basically having VIs which will be marked as property VIs (similar to what XControls have) and will only be allowed to have a single input (or output) other than the class and error I/O. These will appear in the list when you connect an LVOOP object to a property node (ideally with the properties from the parents as well), somewhat like this:

When you run the code in this image, LV will run the VIs sequentially, passing the object and error I/O from one VI to the next.

I know that NI already tried to do this in the past, but didn't finish it. Hopefully, enough support here will encourage them to pick it up again.

View All (2)

Integrated Structure Labels

View All (8)

While the Image datatype is very useful for working with images, there are many functions that are not available (e.g. Square Root, or the Wavelet Transforms). In order to achieve this, it is necessary to convert the Image to an Array, thereby duplicating the memory required, and then convert back again. (IMAQ GetImagePixelPtr/IMAQ MemPeek also duplicates data). I would like to be able to directly access the Image data as a LabVIEW Array. Perhaps the In Memory structure could be used to achieve this, e.g.

One potential problem is the extra information (border pixels) which are part of Images - for most use cases it would probably be ok to retain these (i.e. the array is larger than the image, though perhaps there could be an option as to whether they are mirrored or zero etc. RGB images would provide an array of U32/64, but even better might be a cluster of arrays for each colour plane.

Bonus points for the ability to access an Array of Images as a 3D Array!

View All (5)

Reorder Button Color

I find the color of the Reorder Button on the front panel a little confusing. The colors of the two circular arrows being gray gives me the impression that the buttons is disabled for some reason, especially considering the related buttons to the left have some color with green and yellow boxes. It causes me a slight mental block every time I want to use it. I would suggest that the Reorder button be given some color, such as green, so that it mentally gives the impression that it is allowed to be pressed.

Message Edited by Ravens Fan on 06-21-2009 01:15 AM

This ties into a recent post I made on the NI Forum HERE.

I have already run into this problem a few times.

Somewhere in my code I have a process returning an object of a particular class which does not have the exact same type as a dynamic dispatch input. My post above shows a workaround for this (which, if it wasn't so horrible it'd be funny).

I've run into similar problems where the object is being passed via Queue or Event where I have to pass the Objects as a parent class to enable portability but where I KNOW the only source of the data is a VI sending an object of EXACTLY THE SAME TYPE as the dynamic dispatch input.

A normal "to more specific class" does not work presumably because the resulting object COULD be a further sibling of the required object, thus breaking any dynamic dispatch tables.

Up to now I've had to write a class member to take the existing object and another object of type parent and make a cast and update the values manually which is really annoying because it requires each and every child class to implement this (and make use of the parent function).

So what I'd like is a function to allow an EXACT cast of an LVOOP object so that I can still satisfy the Dynamic Dispatch requirements without having to have a piece of code for each and every child class created. If the Object classes don't match EXACTLY, return an error and the contents of the object used for the cast.