knob tooltips

[tulamide]

You're still not getting my point. Every view is basically a bitmap that you can draw to. You do so by connecting a yellow V link. If you don't use an mgui but activate graphics on the panel, you also created a view link (you just don't see it in the schematic).

A MGUI also has a view input. Normally you connect a wireless link to it. This means, whatever the mgui draws, it draws it to the view of the input. And that's the point. If now the top layer needs a redraw (and it does as soon as you move the tooltip), it triggers ALL MGUIs connected to this view as well. So, in your example, if moving the tooltip, all 64 buttons get an order to draw themselves.

Maybe this very simple schematic can make it clear? You will see random colored pixels and a trigger button. Each time you hit the button the whole view is redrawn. Now look inside. There's a RubyEdit for the main view (the top layer), but it only contains an event method. In this method I call "redraw"". There is no draw method at all, still all 16 submodules redraw themselves. That's because the top layer commands all 16 sub modules to redraw, by just this one redraw command in the event method.

[tulamide]

And here is the redraw area version. You will see that only the first submodule gets the order to redraw.

[Tronic]

This system has no degradation of performance redraw,
It can be easily customized
and has already implemented a wait before being displayed,
then move your mouse and wait a second to see appear on the tooltips popups.

Edit: need to fix the drag mouse up release, at moment not work, very well.

[Nubeat7]

thank you tronic, thats the real smart way

there are a few things new for me, like the @tooltip = ObjectSpace._id2ref(@ruby_id_tooltip)
what exactly is this @tooltip variable ? is it generated inside the master tooltip module?
is there a difference to other variables starting with @?

and what does clear_events?

thanks for linking in!

[RJHollins]

Unfortunately I get a RUBY error when touching knobs. [FS 3.04]

I can't tell what the error message is since it clears when I leave the knob area.

[Nubeat7]

thanks to tronic and tulamide i could fix and improve my own version too,
i also integrated a delay for the infopanel to show up (done in green) because i really like the idea, also used the right area redrawing now so i think evrything is fine now..

but i'm pretty sure that tronics version has a better cpu performance, if you will test it with 448 knobs aombk or anyone else it would be interesting

@ rj hollins maybe this works too in 3.04

[RJHollins]

No errors with 3.04 .... however ...

nothing is displayed in the black box

[tulamide]

there are a few things new for me, like the @tooltip = ObjectSpace._id2ref(@ruby_id_tooltip)
what exactly is this @tooltip variable ? is it generated inside the master tooltip module?
is there a difference to other variables starting with @?

This is part of Tronic's and my efforts of finding ways for direct communication between modules. @ruby_id_tooltip is an input that gets fed with the object_id of the RubyEdit that creates the tooltip. ObjectSpace._id2ref converts an object_id to a usable object reference (e.g. @tooltip now represents the RubyEdit that manages the tooltip). See more about it in this thread.
clearEvents is an undocumented method of the RubyEdit class. I never used it, but from the name I guess it clears a buffer of events (which would make sense here to avoid too many triggers/redrawings).

Nice to see so much improvement. Yes, Tronic's version is lighter on the cpu, but all of us have learned today, and that is the most important thing, isn't it?

[Tronic]

@ Nubeat7
even your suffering of my own bugs,
I can not find an efficient way to handle the mouse up when captured after an drag and drop, and must be resolved.

@tulamide
Thanks for the explanation, but the clearEvents is documented in Chapter 8, page 148

[Nubeat7]

@ Nubeat7
even your suffering of my own bugs,
I can not find an efficient way to handle the mouse up when captured after an drag and drop, and must be resolved.

oh, you mean that the info label jumps around after valuechanges on the knobs?

a mOver to false when releasing mouse fixes this..