[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JDialog weirdness - what to do?
From: |
Michael Koch |
Subject: |
Re: JDialog weirdness - what to do? |
Date: |
Fri, 4 Mar 2005 08:38:09 +0100 |
User-agent: |
mutt-ng 1.5.8i (Debian) |
On Fri, Mar 04, 2005 at 01:57:53AM +0100, Robert Schuster wrote:
> Hi list,
> I just found out the following & got a headache from it:
>
> GNU Classpath's JDialog rejects illegal values given to the method
> setDefaultCloseOperation() with a IllegalArgumentException. This is good for
> robustness but
> it is not what the official implementation does :-(
>
> The official JDialog takes any argument (whether legal or not) and does not
> complain. That means for any int value n, after the call to
> dialog.setDefaultCloseOperation(n) the result of the corresponding getter is
> n.
>
> The behavior when you actually press the close button is as if you had set
> the operation to DO_NOTHING_ON_CLOSE. Btw. the default value for
> getDefaultCloseOperation() is HIDE_ON_CLOSE (this is documented at least).
>
> Eg. if you have a JDialog and set it's default close operation to
> JDialog.EXIT_ON_CLOSE getDefaultCloseOperation() will return exactly this
> value but does not
> act in this way.
>
> Now, I have two questions:
> 1) Who codes such crap and are we really really forced to adopt this? (I
> propose setting the value to DO_NOTHING_ON_CLOSE if the argument is invalid. )
We should change the current behaviour only when real world applications
fail to execute.
> 2) How could I test in mauve whether pressing the close button of a JDialog
> has no effect?
You can use the hava.awt.Robot feature to press the buttun in a (GUI)
mauve test. There are already some examples in mauve that use this
feature.
Michael
--
Java Trap: http://www.gnu.org/philosophy/java-trap.html