|
Quick Lists
|
|
Bug ID:
|
4159234
|
|
Votes
|
0
|
|
Synopsis
|
JOptionPane's showInternal*Dialog methods should create modal dialogs
|
|
Category
|
java:classes_swing
|
|
Reported Against
|
1.2
, 1.1.6
, 1.2rc1
, swing1.0.2
|
|
Release Fixed
|
|
|
State
|
11-Closed, duplicate of 4139692,
bug
|
|
Priority:
|
4-Low
|
|
Related Bugs
|
4139692
|
|
Submit Date
|
21-JUL-1998
|
|
Description
|
JOptionPane's showInternal*Dialog methods create non-modal dialogs
(implemented as internal frames).
This is inconsistent with the show*Dialog methods, which produce
modal dialogs. Also, it's inconsistent with the spec, which says
that the showInternal*Dialog methods produce modal dialogs. Amy
says that the spec is right -- they should be modal. And, of course,
they should be internal frames.
|
|
Work Around
|
N/A
|
|
Evaluation
|
The problem is that JInternalFrame.startModal (used by JOptionPane.showInternalXX)
implements the blocking for the method call, but it doesn't implement
blocking input to other windows (which is what modality really is!).
This is going to be tough to fix. In 1.2 we could use the stackable
event queue to provide our own event queue handling which would block
input to other components. For 1.1 I'm not sure how we'll be able to
do this reliably in an insecure environment (requires access to event
queue).
xxxxx@xxxxx 1998-07-22
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |