Re: Gdk-WARNING **: window 0x520 unexpectedly destroyed

[Owen Taylor <otaylor redhat com>]

Hans Breuer <hans breuer org> writes:

> At 10:50 21.07.01 -0400, Owen Taylor wrote:
> >
> >Hans Breuer <hans breuer org> writes:
> >
> >> Hi Owen,
> >> recent cvs gtk (win32) gives me a bunch of 'unexpectedly destroyed'
> >> warnings (apparently for almost every window). They vanish, if I 
> >> revert your change:
> >> 
> >> Mon Jul  2 16:53:25 2001  Owen Taylor  <otaylor redhat com>
> >> 
> >>  	* gdk/gdkwindow.c (_gdk_window_destroy_hierarchy): Don't
> >>  	mark the window as destroyed until after we
> >>  	called _gdk_windowing_window_destroy().
> >> 	(_gdk_windowing_window_destroy() may use GDK functions
> >> 	on the window.)
> >> 
> >> ... which probably isn't the right sollution :)
> >> Do you have any hints how this issues should be resolved correctly ?
> >
> >Where is gdk_window_destroy_notify() being called from? 
> >
> >As far as I can see, you should only get it when you get a WM_DESTROY
> >message in gdk_event_translate(), 
> Right.
> 
> >and gdk_event_translate shouldn't
> >get called out of _gdk_window_destroy_hierarchy(), 
> _gdk_window_destroy_hierarchy calls
> _gdk_windowing_window_destroy which calls
> DestroyWindow which sends the WM_DESTROY message to the window 
> which gets handled by the window procedure calling finally calling
> gdk_event_translate.
> 
> The window procedure gets called directly by the kernel while the
> Gtk is in the DestroyWindow call. I currently see no way to not
> let this happen. 

My memory of event processing in Win32 is pretty fuzzy after
8 years or so. I had recalled everything being dispatched
after the application called GetMessaged(), but I see what
is happening now.

> Or maybe a big rewrite of the window procedure to stuff all its 
> messages in a queue of native messages from which gdk fetches 
> them, when it is ready to do so ...

I don't see any particular reason to listen for WM_DESTROY
at all.

The reason that the X11 port listens for DestroyNotify events
is that queued events for that window ID may still be received
until the DestroNotify, so the window ID has to be kept around. 
But I don't think that's relevant on Win32.

It seems to me like you should be able to simply clean the window out
of the "handle table" in _gdk_windowing_window_destroy.

If that doesn't work, well you can also just set private->destroyed = TRUE;
yourself immediately before calling DestroyWindow().

Regards,
                                        Owen