Rolf Howarth wrote:
| That, incidentally, is why setVisible() on Dialog ought to be
| deprecated. For components, yes, show() and hide() are a poor choice,
| where visibility is a property not very dissimilar from enabledness,
| opaqueness, bounds, etc.
The problem with show() and hide() isn't that visibility is a property, it's
that they're less general than setVisible(), using two methods where one
will suffice, and less consistent, since the "query" method (isVisible)
isn't as obviously related to the "update" methods (show and hide). It would
be perfectly reasonable to have, for example, enable() and disable() methods
instead of setEnabled(). The logic that motivates adopting setVisible() in
preference to show() and hide() applies just as much to windows as to any
other component that can be shown and hidden.
| For a window, however, and most especially a modal dialog, showing it
| is something quite, quite different.
Not really. Visible is visible. The only difference is the background.
(Consider JInternalFrames, which are windows, but are also components.) The
problem isn't that the dialog is being made visible, the problem is that the
call doesn't return immediately. If you really think that learning that "for
modal dialogs, Dialog.setVisible(true) doesn't return until the dialog
closes" is too heavy a burden on programmers, the fix is to change
Dialog.setVisible() to behave the same as EverythingElse.setVisible(), so
that it *does* return. All that would accomplish, though, is to introduce a
new error: forgetting to make the call that *did* block until the dialog was
closed. All in all, I think the current approach is probably the better one.
| I would always use JDialog.show() to make it quite clear what is
happening!
How does "show()" make things any clearer than "setVisible(true)"? *Neither*
one says "doesn't return until the dialog closes". You *still* have to
remember that the call behaves differently when used with modal dialogs.
Glen Fisher
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
