Please give me "A Wack on the Side of the Head"* ! Implement pallettes in a GUI?

[Ben]

I am looking fro idea on how to implement "palettes" in the GUI of a new application.

The requirements would read;

Given a set of icons, present a po-up palette populated by those icons that will allow a user to select one of the icons.

The ability to group sub-sets of the icons into sub-palettes is highly desirable"

As an example, just look at the function and control palette as used in LV.

No I am not trying to re-write LabVIEW, just expand it envelope.

So if you have ideas or examples, please share.

Thank you!

Ben

*"A wack on the Side of the Head" is the sub-title of a the book "A Guide to Creative Thinking" ( I do not remeber the author).

Cross post on LAVA is here.

Message Edited by Ben on 06-06-2007 08:42 AM

[tst]

I would do the palette as a transparent 2D array of transparent pictures (I assume they all have a standard size) and detect which element was clicked. I would probably extract the square root to try to get the palettes to be as square as possible. You can see a basic example here.

I would also look up the context menu examples posted on the web (I believe PJM had one in the LAVA forums) and use that as a basis for doing the nesting of multiple palettes.

If this is for the touch screen application, you should also check whether your screen can handle drags properly, since I have seen in the past that they sometimes tend to detect a release too early, so you might need to have the users click on the icon and then click inside the picture control to release.

[Ben]

Nice "wack" tst!

You've got me thinking.

Ben

[unclebump]

Maybe you could hack the Mac iphone interface when it comes out.

http://www.apple.com/iphone/

[unclebump]

Wasn't there an issue with the picture control and transparent backgrounds in v8???

[Marc_A]

How about making each palette a dialog VI with no title or menu bars. Then each subpalette could be activated by a button which opens another one of these dialog VIs. Run the main palette when the user right clicks, and move it to the position of the click. This would make it pop up right under the mouse like the LV palettes do.

Detecting a mouse click outside of the palette VI could close it, and clicking another button at a higher level could close a subpalette if one was opened and open a new one. I could see these things being tricky, but you're a smart guy.

Now you've got me thinking, maybe I'll give it a try to see if I can get anything working.

[smercurio_fc]

An alternative approach would be to use an ActiveX control like a button bar, similar to those used in Office. The interface is a little different, but it allows you to create groups and each group has its own set of buttons. The downside is that this is platform specific.

[Ben]

Well that was a nice flurry of ideas.

Give me time to think and process and I will update back.

Ben

[sth]

Ok, how about.....

Something based on one of the User events examples. You have a palette of icons on the right hand side. Each icon has a bunch of invisible corresponding invisible GUI elements in an array of references.

The app detects a mouse down event over one of the icons, it then makes a corresponding GUI element visible and registers the mouse move events. Then as mouse move comes in it moves that gui element around. When dropped it unregisters the mouse move events. If the element is now visible it is marked in the array as in use and not available for a new element.

Also detect mouse down on the new gui element to move it again. When dropped on the palette it makes it invisible and marks that one as available.

The down side is that you have a maximum number of each gui element that you can use that is fixed. But that can be large.

See the examples/general/dynamicevents.llb/Dynamically Register for Events.vi as an interesting way to move GUI elements around. You can hide and un-hide them by having a special drop/pickup area for each event.

NO ACTIVE-X (evil evil) and completely cross platform pure G!
-Scott

Message Edited by sth on 06-06-2007 07:50 PM

[DFGray]

I think I would use a picture control for the icons for the following reasons:

1. The icon clicked on can be quickly and simply decoded from a simple mouse down event.  You know the spacing and location of all the icons.  WIth a 2D array, a mouse down event does not get you data or the element selected and elements can change size based on font.  You can use the control reference to decode things, but it gets messy and slow.  A change value event on a 2D array will not work because the user may wish to pick the same element twice.
2. Picture control is easy to populate, although not as easy as a 2D array would be.
3. Picture control is easy to control layout and formatting.  While this can be done with a 2D array or multi-column listbox, the kinds of things you would want to do with a palette would be much more difficult.

On the down side

1. Picture control is not automatically formatted to the native operating system look.
2. Picture control makes you do everything (could be considered a plus).

I would probably embed the picture control into a VIT or rentrant VI and call it by reference when I needed the dialog.  This would allow easy multiple palettes, a la LabVIEW.  I did a similar thing once with a LV7.0 pop-up menu, before LV had them natively.  In this case, you may want to avoid libraries, since they can cause load time issues, and you want the dialogs up fast.  Lazy loading the dialogs would solve this issue.

Sounds like fun, Ben.  Be sure to let us know what you did.