Zen of Swing



  • this.addWindowListener(new WindowAdapter() {
      public void windowClosing(WindowEvent e) {
        setVisible(false);
      }
    });


  • I don't particularly know Java, but perhaps this is intended to hurry up and hide the window while some other tear-down logic is executed in parallel, to avoid "this window freezes for a second when I close it" bug reports?




  • @emurphy said:

    I don't particularly know Java, but perhaps this is intended to hurry up and hide the window while some other tear-down logic is executed in parallel, to avoid "this window freezes for a second when I close it" bug reports?



    That sounds like a good explanation, but the windowClosing method doesn't do anything else but hide the window.

    Unless, shudder they have multiple WindowListeners registered. They could have the default close operation set to exit on close (which would actually exit the program, not just hide the window), but that wouldn't give them any place to do any tearing down before exiting. Not that any of that makes that code any less useless.



  • JDialog dialog = new JDialog();
    dialog.setDefaultCloseOperation(WindowConstants.HIDE_ON_CLOSE);
    

    JFrame frame = new JFrame();
    frame.setDefaultCloseOperation(WindowConstants.HIDE_ON_CLOSE);
    

    I humbly suggest reading the javadoc in the future.

    That said, I agree "windowClosing" is a truly crappy name; it actually means "user tried to close the window via the window manager." It was part of Java 1.0, which contained a lot of mistakes in class names and method names.



  • @VGR said:

     

    That said, I agree "windowClosing" is a truly crappy name; it actually means "user tried to close the window via the window manager." It was part of Java 1.0, which contained a lot of mistakes in class names and method names.

     

    I guess they wrote the method names in India? (sorry i cant get over the linksys post) 



  • @dlikhten said:

    I guess they wrote the method names in India? (sorry i cant get over the linksys post) 

    I don't know how many people have seen this (normally I'm the last one by far) but it's a funny short video that's very much on topic:

    http://www.comedybox.tv/comedy-animated-picks-10119



  • @emurphy said:

    I don't particularly know Java, but perhaps this is intended to hurry up and hide the window while some other tear-down logic is executed in parallel, to avoid "this window freezes for a second when I close it" bug reports?



    Not the case this time (it's a hide-on-close window), but I hadn't thought of that. Mostly because relying on the (unspecified) order of execution of event listeners is asking for trouble.

    (I'd use either java.util.concurrent to spawn off the tear-down logic asynchronously, or better yet, use the windowClosed() hook for it instead. Swing is nothing if not complete in its clunkiness.)



  • @David Vallner said:

    @emurphy said:

    I don't particularly know Java, but perhaps this is intended to hurry up and hide the window while some other tear-down logic is executed in parallel, to avoid "this window freezes for a second when I close it" bug reports?



    Not the case this time (it's a hide-on-close window), but I hadn't thought of that. Mostly because relying on the (unspecified) order of execution of event listeners is asking for trouble.

    (I'd use either java.util.concurrent to spawn off the tear-down logic asynchronously, or better yet, use the windowClosed() hook for it instead. Swing is nothing if not complete in its clunkiness.)

    I agree that if all you want to do is close and destroy the window, then this is the wrong way to do it. But if you want to run some code when the window tries to close, then this is the right way. that being said though, if you've designed your app well, then there's nothing that needs to be done by the gui to tear anything down. Letting a frame dispose itself, or even disposing it manually is all that's required.

    Also, the windowClosed() event happens after the window has already been disposed, while the windowClosing event happens after the request to dispose has happened, but before actually disposing. The names make sense if you read the api.



  • @hunter9000 said:

    I agree that if all you want to do is close and destroy the window, then this is the wrong way to do it. But if you want to run some code when the window tries to close, then this is the right way. that being said though, if you've designed your app well, then there's nothing that needs to be done by the gui to tear anything down. Letting a frame dispose itself, or even disposing it manually is all that's required.

    Also, the windowClosed() event happens after the window has already been disposed, while the windowClosing event happens after the request to dispose has happened, but before actually disposing. The names make sense if you read the api.

    In many cases, you will want to ask the user something like "Document has been changed, save/discard/cancel?"; the windowClosing event is IIRC the right place to do that.


Log in to reply