Jane wrote:
> On 2008-10-12, Albrecht Schlosser <[EMAIL PROTECTED]> wrote:
>> jane wrote:
>>
>>> oh, this looks pretty easy, just draw and handle? well,
>>> makes sense, draw something and then handle events on it.
>> Your question was, where to start ... ;-)
>>
>> Of course you would also need member variables to save the values and
>> the appropriate get and set methods, but that should be obvious.
>>
>>> do i need damage too? or is that on a lower level?
>> No, not really. Damage can be used to improve drawing, to minimize areas
>> that need to be redrawn, but you can also let the default FLTK handling
>> draw everything when needed. After you change something, calling
>> redraw() should be enough.
>>
>> I propose using Fl_Double_Window, because then there won't be any
>> visible flickering, but you could also use damage() and
>> {push_|pop_}clip() to reduce flickering, if you want to use a normal
>> Fl_Window. Otherwise, if your widget becomes big (and I assume that
>> would be necessary to hit the correct keys with the mouse), then
>> flickering could become a problem with normal Fl_Windows. But you can
>> decide this later, you don't need it for starting.
>>
>> Albrecht
>
> man, this is great. thank you.
> it is kinda like opengl programming. :) it took me a
> little time to get things right and the way i wanted them
> to be but i am quite happy with it now. fltk is great! ")
I'm glad that we could help you.
> i am not 100% sure when to return 1 and when to return 0 in
> my handle function.
The easy rule (but you know that): if you don't use it, return 0,
otherwise return 1.
> eg, should i return 1 for an
> FL_MOUSEWHEEL event, even if i dont use that event for any
> control? because i wonder if i don't, where is the event
> going to?
That's the more difficult part. FLTK "tries really hard not to loose any
event" (cited without looking at the docs, may be different). That means
that unused (mouse and keyboard) events are delivered "bottom up" from
the Fl::belowmouse() and Fl::focus() widget, resp. to the parent
group(s) and then again "top down" to other widgets in these groups,
maybe even to competely unrelated "sister" groups.
That said, if your widget is a child of an Fl_Scroll group, then the
Fl_Scroll would get the event and do, what the user would expect. But if
not, the FL_MOUSEWHEEL event could end up in another unrelated group,
maybe annoying for the user. You can sometimes see such unexpected
behavior in browsers with embedded scroll boxes and a page that is
bigger than the window. But your widget can't "know" if it is a child of
a scroll group, thus it depends on your application and needs.
Another example: FL_KEYUP events. Almost no widget uses keyup events,
and therefore they can fly around and may eventually be delivered to
every widget in the window. I decided to return 1 on FL_KEYUP events in
one of my input widgets, if this widget is the Fl::focus() widget,
because the probability is high that this widget used the FL_KEYDOWN
evetn before. This reduced the (IMHO) useless FL_KEYUP event propagation
to unrelated widgets in _my_ application. YMMV.
And one more: if a user clicks the mouse on an object, but this object
is inactive (at that moment), what should happen? IMHO, the object
should return 1 on the click event (I got it and "used" it, but did
_nothing_ with it), which is better (because it would be expected by the
user) than asking all other widgets, if they want to use this particular
click event. But that may depend, too...
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
