On 24.02.2011, at 22:31, corvid wrote:
>> Matthias wrote:
>> On 23.02.2011, at 21:22, corvid wrote:
>>
>>> I wrote:
>>>> If the widget flag enum says:
>>>>
>>>> INVISIBLE = 1<<1, ///< the widget is not drawn but can
>>>> receive events
>>>>
>>>> then why is visibility required in:
>>>>
>>>> unsigned int takesevents() const {
>>>> return !output() && active_r() && visible_r();
>>>> }
>>>
>>> I ask this because the fltk2 dillo uses a search bar that works by receiving
>>> shortcut events even when invisible.
>>
>> Normal widgets will not receive shortcut events when hidden, or any of their
>> parents is hidden. There are a few events that still go through though,
>> HIDE, SHOW, ACTIVATE, DEACTIVATE for example.
>>
>> Shortcut events will ultimately be sent to a custom handler. See: void
>> Fl::add_handler(Fl_Event_Handler ha); and void Fl_Menu_::global();
>
> Okay.
>
> Would you consider it wrong that it works in FLTK2?
I assume there is a reason for the change form 1 to 2. It may be related to the
fact that in FLTK2, menu items are true widgets, and invisible if the menu is
closed, but of course they should still function. So for popup window and their
children, it's probably correct to accept shortcuts if they are hidden, but
"hot" could be clicked at any time). For buttons in a UI, it would be wrong
IMHO.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
