Graphical drop-down selector

[HughBanton]

I'm not very good at graphics! Never really been my thing ...

The other day I was visualing a drop-down list selector, that instead of displaying a list of numerical options - like the regular DropList prim does - would instead display a group of bitmap icons or shapes that you could click on, and output an index number from that. Would improve the user experience I think.

For example, instead of it listing 1: Sine 2: Saw 3: Square 4: Triangle 5: Noise, we'd have four pics of the wave shapes to click on. Or it could be Left Speaker, Right Speaker, Centre Speaker. I'm personally currectly looking at updating my 'stereo-distribution' selector but it could be anything - Trains, Planes, Automobiles if you like ...

Anyone ever done anything like this? I made a good start on suitable graphics, and managed to get the click & index-select bit to work OK in Ruby using mouse-over etc. But stumped how to make such a graphic group appear and disappear as required, like the drop-list does.

Grateful for any inspiration

H

[tulamide]

The easiest probably is to use .setShowInParent and a view that only contains the list.
You can have it invisible unless the "menu item" in the main view is clicked.

You have to track the state! Only react to mouseclicks if .setShowInParent is true.

[Spogg]

I imagine you’ve already read this thread, but just in case…

viewtopic.php?f=2&t=13420&start=0&hilit=selector+bitmap

[HughBanton]

Actually I hadn't! Doh .. I must have spilt it wrang when I typoed in the Saerch

Thanks both, I'm keenly pursuing!

H

[tulamide]

I imagine you’ve already read this thread, but just in case…

viewtopic.php?f=2&t=13420&start=0&hilit=selector+bitmap

Totally forgot about this one!

Hugh, when looking at that project, remember that .setShowInParent from the view class is equivalent to using a selector to send the view into oblivion. You might want to prefer the all-in-Ruby method, as it is literally the function, you would use manually when activating "show in parent" in the context menu.

Good luck!

[Spogg]

Totally forgot about this one!

It was good luck that I heard a very distant bell ringing!

For me the really tricky thing would be creating the actual bitmaps!

[HughBanton]

Been a bit busy on other stuff (life!) but I have also made some attempts to progress this ..

I'm not having any luck getting setShowInParent to work, sorry. Can't seem to nail the syntax. Any chance of a very very simple Ruby demonstration just to get me started? I belive there's 'showInParent' available as well?

9 times out of 10, once I have the key to the door, I get on a roll ...

H

[HughBanton]

Realised this sort of thing can be done quite simply with a Selector in an MGUI V-connector line. I've made a working example in FS4, snd if I get time to translate it to FS3 I'll post something here; otherwise on the Slack forum.

But I'll describe it now anyway! Two elements - i) a 'Select' button, and ii) a drop-down graphic list that can be moused over, containing the items you want to select from. When you click on i) it switches the GUI selector which brings up ii). And when you release the mouse inside ii) it outputs the value of the item you're currently moused over, closes the graphic and reverts back to i). So we have a simple change-over graphic selector switch controlled by mouse-down inside i) and mouse-up inside ii). Makes the drop-down list appear and dissappear.

Hope this makes sense!

I dare say Ruby showInParent could be made to do something similar, but the method is proving elusive to me at the moment. Anyway old-time GUI switching seems to work fine for this.

I do however have a niggling doubt that overlaying graphic layers like this in FS3 has a flaw .. I remember I tried something similar to this years back, and found that if, say, you overlay one control on top of another control, then the control on top remains 'transparent' to mouse clicks and the invisible control underneath can still get invisibly modified as well - urgghh! I've checked that this definitely does not happen in my new FS4 experiment so possibly this is an old bug that Maik has dealt with. We will find out!

H

[Spogg]

I do however have a niggling doubt that overlaying graphic layers like this in FS3 has a flaw .. I remember I tried something similar to this years back, and found that if, say, you overlay one control on top of another control, then the control on top remains 'transparent' to mouse clicks and the invisible control underneath can still get invisibly modified as well - urgghh! I've checked that this definitely does not happen in my new FS4 experiment so possibly this is an old bug that Maik has dealt with. We will find out!

Yes I found out about that too some time ago. This isn’t a problem when using a conventional selector droplist because control goes over to Windows until a selection is made.

So… if you make a schematic in FS3 and open it in FS4 you don’t get the mouse operating on the graphics layer below? Or is it valid just for schematics made completely in FS4?

I know, I know… We mentioned FS4 but if this is the case it would be nice to include it in the FS4 documentation as an improvement.

[tulamide]

I can confirm that this is the standard behavior in FS3. It always bothered me. Mousclicks will always be delivered to all layers, no matter what.

Hearing that FS4 does not behave like that makes me happy. For the lack of layering I didn't encounter that change yet. When confirmed it should definitely be documented, as it is a huge step forward for layered design. Especially as it also gets rid of the additional computing time.

Hugh, regarding setShowInParent, it is (as far as I know) only active in FS4. I thought you were using the latter, sorry for confusion!