Re: when are "delete_event" and "motion_notify_event" called?

[Sven Neumann <sven gimp org>]

Hi,

"Matt Strange" <mjs86 linuxmail org> writes:


>   I am a gtk newbie working on a widget which consists of 16 toggle
>   buttons in an hbox.  I have sucessfully stopped the emission of
>   the "event" and button_press/release signals on the toggle buttons
>   and set up a callback to these events which returns FALSE.  This
>   passes the signals to parent hbox where I can trap them
>   successfully.  The point is to allow the user to make multiple
>   toggle buttons ACTIVE (pushed in) in one mouse stroke by dragging
>   the mouse across the hbox, rather than clicking on each button
>   individually.
> 
> *motion_notify_event*
>   To make it work appropriately, I wanted the buttons to activate as
>   the pointer was dragged over then, so I thought I needed a
>   callback to "motion_notify_event".  Unfortunately it looks like
>   the toggle buttons and hbox don't emit this signal.  Simply using
>   "button_pressed/released_event" will force me to activate all the
>   buttons at once.  What would list members recommend to fufill this
>   requirement?

If you want motion notify events you will have to tell the widget
about this wish. gtk_widget_add_events() should solve your problem.

> *delete_event*
>   Since I am using events emitted from the hbox, I g_malloc() an
>   array of the 16 toggle buttons and pass it as a parameter in the
>   above-mentioned callbacks.  This works well, but I'm not sure
>   where to g_free the array.  I bound a callback to "delete_event"
>   and "destroy_event" on the hbox, but when I place a g_print()
>   message in these callbacks, it is never written to the terminal.
>   Why would a widget never recieve these events, and where should I
>   go about destroying the array? The array must be allocated so it
>   is resident in memory as long as the widget is.

AFAIK, delete_event is only called on top-level windows. All widgets
are destroyed at one point so you should connect to the "destroy" _signal_.

> (*code snippet below*)

I am sorry but that code is close to unreadable.


Sven