windowClosing causes GLCanvas to displose

Hello,

I have a small problem and I fail to find a way to solve it.
I use a GLCanvas in a java.awt.Frame. This frame receives a windowClosing event, that is fetched by a window listener to display such a "do you really want to close?" window. Sadly the event is forwarded to the GLCanvas also that causes it to dispose. That is pretty much of a problem in case you click "No, don't close"

Is there any way to solve this? So cause GLCanvas to ignore this event.

The used version of JOGL is 2.0.0 b162

Nitram

U are right this is indeed a strange behavior. Never noticed it myself.

After looking at the GLCanvas sourcecode on Github the behavior became clear as there is an implicit closing listener registered when the display method is called on the GLCanvas.

  public void display() {
    maybeDoSingleThreadedWorkaround(displayOnEventDispatchThreadAction,
                                    displayAction);
    if(null==closingListener) {
      synchronized(closingListenerLock) {
        if(null==closingListener) {
            closingListener=addClosingListener(this, new DestroyMethod() {
                        public void destroyMethod() { destroy(); } });
        }
      }
    }
  }

... don't know why this was done. Seems wrong to me but maybe theres a valid reason for this and Sven/Michael could shed light on this issue.

As a workaround for this issue I would suggest extending the GLCanvas and overriding the display method and remove the implicit closing listener registration.

Maybe this implicit listener should be rather called when the window is closed and not when the window is closing or you should find another solution of implementing your dialog.

A nice solution in theory. But this single line

maybeDoSingleThreadedWorkaround(displayOnEventDispatchThreadAction, displayAction);

contains that much private logic that its impossible with a reasonable amount of work to overwrite that method fully.

On Saturday, August 28, 2010 06:54:19 pm Demoscene Passivist [via jogamp] wrote:
Looks interesting, indeed.

We have to remove our GL/JOGL resources _before_ the native underlying window
has been closed!

Thats why we destroy on 'closing',
but IMHO 'closing' should be send only in case the window will be destroyed for sure.
Sounds like an AWT bug to me.

+++
void windowClosing(WindowEvent e)

    Invoked when the user attempts to close the window from the window's system menu.
+++

Or is such a use case (really close) valid in combination with 'closing' ?

The only pieces I have found involved a manual 'really closing' dialog like this:

http://forums.sun.com/thread.jspa?threadID=650850&tstart=0
http://forums.sun.com/thread.jspa?threadID=652071

In such case, we would need to opt-out the destroy() on 'closing' behavior in GLCanvas,
ie remove/not-add the listener for a user implemented 'closing' logic.

Proposal: New GLCanvas method 'disableDestroyOnClosing(boolean v)'

I guess that makes sense.

Questions, Comments, Remarks ?
 
Cheers, Sven

> As a workaround for this issue I would suggest extending the GLCanvas and
> overriding the display method and remove the implicit closing listener
> registration.
>
> ______________________________________
> View message @ http://jogamp.762907.n3.nabble.com/windowClosing-causes-GLCanvas-to-displose-tp1380491p1380604.html
> To start a new topic under jogamp, email [hidden email]
> To unsubscribe from jogamp, click http://jogamp.762907.n3.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=762907&code=c2dvdGhlbEBqYXVzb2Z0LmNvbXw3NjI5MDd8NDU1NjU4MjUx
>


--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1

>Proposal: New GLCanvas method 'disableDestroyOnClosing(boolean v)'

... sounds fine to me :)

And here come the nasty small details.

Its not a "AWT bug" its more like a "Swing issue"

My Frame is after all in fact a JFrame. That allows such nice things as

setDefaultCloseOperation(DO_NOTHING_ON_CLOSE)

AWT usually acts as you said. It calls windowClosing, then it disposes the window and calls windowClosed after this.
Using swing you can interrupt this with this DefaultCloseOperation what leads to the point that windowClosing is called once the native close window button is used and does nothing more after this. The disposal of the Frame has to be triggered manual.

How ever I think after all this disableDestroyOnClosing will work out just nicely in any case. I propose the default value to be true how ever since I think that will be the most used.

Nitram

Why do we have to remove our GL/JOGL resources before the native underlying window
has been closed? Sorry for my silly question.

disableDestroyOnClosing(boolean v) should rather be called setAutoDestroyOnClosingEnabled(boolean enabled) in my humble opinion, it would be more consistent.

I have another suggestion. We could rather use an interface that would be used to contain only a check when the closing listener is called.

public interface ConfirmCloseCondition{

       public boolean isVerified();
}

public void display() {
    maybeDoSingleThreadedWorkaround(displayOnEventDispatchThreadAction,
                                    displayAction);
    if(null==closingListener) {
      synchronized(closingListenerLock) {
        if(null==closingListener) {
            closingListener=addClosingListener(this, new DestroyMethod() {
                        public void destroyMethod() {
                               if(confirmCloseCondition==null || confirmCloseCondition.isVerified()){    
                                   destroy();
                               }
                        }
            });
        }
      }
    }
  }