Thanks for your reply! On Wed, Jun 18, 2003 at 01:12:08PM +0200, Melvin Hadasht wrote:
When I tried to connect it to the main window, a backspace in a form (or in the location bar) would trigger "back". Why is this?
This is because it is an event rather than a signal. And events can be transferred to the parent widget if the event handler returns FALSE. So if the (key) event handler in the entry (location bar) returns FALSE, the event is forwarded to the other (key) event handlers of the same widget and then to its parent (the main window). To avoid this, once you handled the event, you can stop the event transmission by making your event handler return TRUE. See GTK tutorial about the events handling. I figured that out (see below), but thanks anyway.
Why doesn't the the current key_press_handler receive signals when entering text in a form?
This is related to above. The default entry key event handler returns TRUE. So I guess you added a key event handler to the entry and made it return FALSE, am I right? I'm afraid not. I haven't added any event handlers to the location entry (nor to any text widgets for html forms). What I would like to have is a "global" handler, to handle any key presses not handled by a text widgets default handler (like function keys etc...)
What I can't figure out is why a key press event is forwarded from a text widgets default handler (e.g. a form) to a handler connected to the main window (bw->main_window), but it is NOT forwarded to a handler connected to the main document window (GTBIN(bw->docwin)->child). Could it be that the main window handler somehow gets called before the text widgets default handler? To reproduce this just connect the current key press handler to bw->main_window instead of docwin->child. Then, entering backspace in an html form will trigger "back". Johan Hovold