Re: Why cursor keys are not longer reported in key press events

Kjell Ahlstedt via gtkmm-list <[email protected]>
Newsgroups gmane.comp.gnome.gtkmm
Message-ID <[email protected]>
On 2020-03-28 21:52, Klaus wrote:
>
>> This is normal behavior for event signals. The default handler can stop
>> further processing by returning true. It's described e.g. at
>> https://developer.gnome.org/gtkmm-tutorial/stable/sec-xeventsignals.html.en 
>>
>> https://developer.gnome.org/gtkmm-tutorial/stable/chapter-keyboardevents.html.en 
>>
>>
>>
>> You shall set the 'after' parameter to false in the call the connect().
>> https://developer.gnome.org/glibmm/stable/classGlib_1_1SignalProxy.html#a0bee9dba36374339ab19ec34f288613e 
>>
>>
>
>
> Yes, I know that this can happen and set my handlers now "before" the
> others. What makes me wonder is that it looks that the default handler
> has changed behavior. Or had I myself programmed some unlucky side
> effects? :-)
>
> Thanks for your detailed answer/link list!
>
> Regards
>  Klaus
>
>
Almost all default handling of signals is done in gtk, not in gtkmm. If 
something has changed, the change is probably in gtk. In order to find 
out what has changed, you need to know which version of gtk you used 
before, and which version you use now. And also which type of widget you 
see the change in. Different widgets can of course handle signals 
differently.

This is a kind of change that can very well happen from one release to 
the next, at least if the minor version number has changed. (Example: 
some_pkg 2.14.1: 2 = major, 14 = minor, 1 = micro version number)

_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.