Re: Self destructing dialog question



Thanks David,

It was the "destroy" signal that I was looking for. Indeed I mixed it up with the "destroy-event" signal, as I only looked at the GtkWidget signals and not at its parent signals.

I knew the solution was simple...

Regards,
Dov

2009/11/25 David Nečas <yeti physics muni cz>
On Wed, Nov 25, 2009 at 08:41:58AM +0200, Dov Grobgeld wrote:
> Assume I have a program with a widget MyApp that has a member called
> my_dialog that is created to catch its destruction as follows:
>
> if (!priv->my_dialog) {
>     priv->my_dialog = my_dialog_new();
>
>     g_signal_connect(priv->my_dialog, "delete-event",
>                      G_CALLBACK(cb_my_dialog_destroy), priv);
> }
> :
>
> static gboolean cb_my_dialog_destroy(GtkWidget *widget,
>                                      GdkEvent *event,
>                                      gpointer data)
> {
>     MyAppPriv *priv = MY_APP_PRIV(data);
>     priv->my_dialog = NULL;
>     return FALSE;
> }
>
> ...
>
> Trying to connect to the "destroy-event" in MyApp didn't work. I never got
> any callback.
>
> So how should this be done?

By inspecting the list of signals more closely.

"delete-event" is sent when the delete event is received, i.e.
(typically) when the user closes the window by window manager means.
Receiving "delete-event" may and may not lead to actual destruction of
the widget (destruction is just the default response).  If you destroy
the widget directly with gtk_widget_destroy(), no delete events are
involved.

"destroy" is emitted when the widget is destroyed.  It is not an
event-signal and has no "-event" in its name.

g_object_add_weak_pointer() ensures clearing a pointer when an object is
finalized.  Note if the holder of the weak pointer can be finalized
first, it needs to remove the weak pointer to avoid disaster.

Yeti




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