Re: on_*_event return



Thanks for the information. I think this gives me more questions than it
answers.

Murray Cumming wrote:
> On Sat, 2008-01-12 at 10:02 -0500, JLM wrote:
>> Some widget event handler functions return a boolean value.
>> on_expose_event is one. I think the return value is supposed to tell the
>> caller whether this widget handled the event or not. 
> 
> Yes:
> http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-xeventsignals.html
> 
>> What exactly does it mean to handle the event?
> 
> It means that no further signal handler will be asked to handle the
> event too.
> 
>> For example, I have an on_expose_event function set up for my widget
>> that is subclassed from DrawingArea.
> 
> When overeriding, remember also to call the base class's implementation.
> Sometimes it does something useful.
>
Should the base class's function always be called? If not, when should
it? I noticed that this isn't followed in the tutorial. The Cairo
example (first one I think) does not call the base class in the
on_expose_event function.

>>  It only does something if the
>> widget is realized, so I put everything in an if(is_realized()) { ... }
>> block. So should I return false if the widget is not realized when this
>> function is called? Or is the widget considered to handle the event, but
>> it just happens to not do anything?
>>
>> Are there any rules of thumb for when to return true versus false in
>> these cases?
> 
> I have often wondered the same thing in similar situations. I don't
> think I have a general answer, but maybe someone else does. I am
> generally not a fan of these signals or this technique because I think
> it requires you to have a knowledge of what the default implementation
> is.
If you are not a fan of this technique, then I am curious how you do
these things. The recommended techniques in the manual suggests
subclassing widgets to better organize your code, so I have done that. I
am not sure how to customize the drawing of my new widget without using
the on_expose_event function.

I'm only doing it this way because it's the only way I know how. If you
have a better way, I'm interested in hearing it.
> 
> But that would be the same with the more-traditional C++ technique of
> override-and-sometimes-call-the-base-handler.
> 

Thanks again.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]