Re: [Java-gnome-developer] Glade and reusing a window

[Andrew C. <an...@op...>]

On Sat, 2005-13-08 at 17:18 +0200, Stefan Prelle wrote:
> The adventWindow-Dialog has a cancel button to close the
> dialog again. It also has the usual button "x" on (the top right) window
> frame to close the window. The cancel button triggers a call to 
>   adventWindow.hide()
> which works fine and allows me to call the show method again (even
> without re-retrieving the widget from Glade).
> 
> My problem is: If I close the window with the "x"-Button on the frame
> the window closes but cannot be re-used.

In GTK, the default handler for the delete-event signal is to stop
emission of delete and re-emit destroy, which causes the window to be
[C] free()'d.

So, in your situation, it makes sense that [Java] hide()ing as result of
hitting some button and then re-show()ing your window works fine, but
'x' does not. Hitting the 'x' button causes delete, which you're not
handling in any particularly special way, which means that immediately
thereafter GTK's default handler will turn the signal into destroy, and
then most certainly you can't re-use it, and hence all the assertion
error crud.

What you need to do is handle the delete-event signal. In the
Listener/Event pattern, it looks something like this:

window.addListener(new LifeCycleListener() {
	public void lifeCycleEvent(LifeCycleEvent event) {
		System.out.println("DEBUG lifeCyleEvent(), " + event.getType().getName());

		if (event.getType() == LifeCycleEvent.Type.HIDE) {
			// do something. hide() perhaps.
		}
	}

	public boolean lifeCycleQuery(LifeCycleEvent event) {
		System.out.println("DEBUG lifeCyleQuery() " + event.getType().getName());

		if (event.getType() == LifeCycleEvent.Type.DELETE) {
			// do something, then,
			if ( whatever ) {
				// say to GTK that you've handled the signal, and
				// therefore to stop further emission of delete,
				// thereby avoiding an implicit destroy()
				return true;
			} else {
				// you want the default handler to carry on and destroy()
				return false;
			}
		}
	}
});

Again, in your situation, you'll want to be hid()ing and returning true.

In my experience, I end up calling external handlers (I called them
hideHook() and deleteHook()) from this listener. It makes it easier for
subclasses to override the behaviour. <shrug>

++

I had a long discussion with ijuma a couple of weeks ago about all this.
I agree that what is presently called LifeCycleListener is a bit clumsy
but it is what it is. 

Leave those debugs in for a while and watch the different events that
get caught by this listener. It's instructive.


AfC
Sydney

--
Andrew Frederick Cowie
Operational Dynamics Consulting Pty Ltd

Stand up and be counted!

Register your Linux computers at http://counter.li.org/