On Sat, 10 Aug 2002 08:07:08 +0200 (CEST) Pavel Parizek <pavelparizek vol cz> wrote:
On Fri, 9 Aug 2002, Allin Cottrell wrote:On Fri, 9 Aug 2002, Matthew Walker wrote:Don't quote me on this, but I think your key_press signal handler needs to return FALSE, to indicate that no more processing needs to be done for the key that was pressed...Um, TRUE will have that effect. FALSE says "keep going". Allin Cottrell.I'm using TRUE as a return value from the beginning. It's just the same problem.
I think there's more to the problem. It depends on which widget has the focus when the key-press occurs. This widget will have the first choice at handling the signal. It depends on this widgets signal handlers what happens next: signal propagation can stop, or the parent widget gets the signal. Seeing your post, it appears that signal propagation continues. So I think there are a couple of possiblities: 1) Add a handler to _every visible widget_ that intercepts the key-presses you are interested in, triggers the appropriate action on the gtkglarea widget and returns TRUE. All other key-presses should go to the default handlers by returning FALSE. 2) Install a key-press signal handler on the gtkglarea. This means that it only reacts if the gtkglarea has the focus. I think that (2) is the best option from a user-interface design standpoint; otherwise you could be destroying the consistency of the toolkit's response if you claim keys that are used for keyboard navigation (which it looks like you are doing) Roland -- R.F. Smith /"\ ASCII Ribbon Campaign r s m i t h @ x s 4 a l l . n l \ / No HTML/RTF in email http://www.xs4all.nl/~rsmith/ X No Word docs in email / \ Respect for open standards
Attachment:
pgpr5dB51wRG6.pgp
Description: PGP signature