Submitted On 17-APR-1999
jsirota
This has been a long-time inconsitency between
Solaris and Windows. I believe that the Solaris
behavior is right. Will it ever get fixed???
Submitted On 09-JUN-1999
bobbyt
Will Sun ever address this problem or give a viable workaround for Win
platform?
Submitted On 02-MAR-2000
chitale
The JDK1.2 javadoc says
<quote>
A modal dialog is one which blocks input to all other toplevel
windows in the app context, except for any windows created
with the dialog as their owner.
</quote>
I figured out how to create a separate AppContext. It still
does not work correctly.
Here is the test case
<code>
/**
* MTGDialogTest.java
*
*
* Created: Thu Feb 18 15:55:03 1999
*
* @author Sandip Chitale
* @version
*/
import sun.awt.*;
import java.awt.*;
import java.awt.event.*;
public class MTGDialogTest extends Frame {
private Dialog jd;
private static int i = 0;
private static int count = 0;
public MTGDialogTest() {
i++;
setTitle(MTGDialogTest.class.getName() + "-" + i);
jd = new Dialog(this, "JDialog" + "-" + i , true);
jd.setResizable(false);
jd.addWindowListener(new WindowAdapter() {
public void windowActivated(WindowEvent e) {}
public void windowClosed(WindowEvent e) {}
public void windowClosing(WindowEvent e) {jd.setVisible(false);}
public void windowDeactivated(WindowEvent e) {}
public void windowDeiconified(WindowEvent e) {}
public void windowIconified(WindowEvent e) {}
public void windowOpened(WindowEvent e) {}});
jd.setSize(200,200);
Button b = new Button("Show dialog");
b.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
jd.show();
}});
add(b, BorderLayout.CENTER);
setBounds(count*50, count*50, 300,300);
count++;
addWindowListener(new WindowAdapter() {
public void windowActivated(WindowEvent e) {}
public void windowClosed(WindowEvent e) {}
public void windowClosing(WindowEvent e) {System.exit(0);}
public void windowDeactivated(WindowEvent e) {}
public void windowDeiconified(WindowEvent e) {}
public void windowIconified(WindowEvent e) {}
public void windowOpened(WindowEvent e) {}});
System.out.println("----");
System.out.println(AppContext.getAppContext());
System.out.println(Toolkit.getDefaultToolkit().getSystemEventQueue());
}
public static void main(String args[])
{
ThreadGroup tg = null;
Thread t = null;
for (int i = 0; i < 4; i++) {
tg = new ThreadGroup("sandip" + i);
t = new Thread(tg,
new Runnable() {
public void run()
{
// Comment the
following to have shared AppContext vs separate AppContext per
// threadgroup
SunToolkit.createNewAppContext();
new
MTGDialogTest().setVisible(true);
}
}
);
t.start();
}
}
} // MTGDialogTest
</code>
Submitted On 30-MAR-2000
rickl
I get so depressed reading the same thing. If sun breaks
l&f guidelines and documents it, it's not a bug but a
feature, argh!
You claim to run just like a windows app, yet when you
don't, it's no big deal. These are the highest priority
bugs from a user complaint standpoint, and makes it hard to
sell java as a development tool.
Rick
Submitted On 16-JUN-2000
martinr2
Hello Hello,
where can I find
http://javaweb.eng/~dpm/modal.txt
???
Submitted On 19-AUG-2000
kuhse
martinr2: That's an intranet resource at Sun,
I don't think it's accessible to the public.
Submitted On 17-SEP-2000
javabandit
Sun, we need frame-level modality. While you are at it,
you might want to combine all of the other bug votes into
this one. It needs all the help it can get.
Submitted On 30-OCT-2000
cabsercan
This behavior is also true for modeless dialogs. All input to all other frames are blocked. Even though
paramString shows the dialog as modeless it still acts as modal.
Submitted On 12-DEC-2000
BezugliyY
I am observing the same bug if two modal dialogs are opened
from two applets opened in different instances of IE
(Netscape's behaviour is a little different). It looks like
java's modality is JVM-wide.
Submitted On 19-DEC-2000
belli
JavaHelp has no use until this bug is fixed! You cannot
open a dialog sensitive help page, because the help window
cannot be used (it's blocked by the modal dialog).
Submitted On 28-FEB-2001
ms366472
The JDK1.2 javadoc says
<quote>
A modal dialog is one which blocks input to all other toplevel
windows in the app context, except for any windows created
with the dialog as their owner.
</quote>
This implies that you can set the owner of a Frame or JFrame.
Unfortunately, this is not true.
There is not constructor which allows you to supply an owner.
In addition the parent class 'Window' allows you to do getOwner(), but not setOwner().
Thus when you create a Frame when there is already a modal Dialog,
the user cannot interact with or even close the new frame until the dialog is closed!
Submitted On 22-MAR-2001
ASheffield
This is REALLY DIRE for JavaHelp - it means you can't show
help for modal dialogs unless you want to completely
confuse the user!
There are a couple of workarounds, depending on whether
you're interested in JavaHelp or not.
If you're not interested in JavaHelp and just want the
partial-modality functionality, try this:
Before the call to show() call setEnabled(false) on the
dialog's parent and add a window listener to that dialog
which calls setEnabled(true) on the dialog's parent when
the dialog is deactivated. That will give you the disabled
parent frame, but of course the call to show() won't block
so you can't wait for the user to do something in the
dialog before the execution of your method continues.
I don't think there's any way of forcing execution to wait
until the dialog is deactivated - can anyone think of a way
using threads? I think the problem with using threads is
that you might violate Swing's single thread rule.
The workaround for JavaHelp would be to use another JVM to
show the JavaHelp window, and use RMI to communicate with
it to set the help ID to view, etc. That way you could use
modal dialogs as normal and they wouldn't block access to
the JavaHelp window as it would be running in another
virtual machine.
If anyone can think of any more options, please let us know!
Alistair
Submitted On 23-MAR-2001
ASheffield
Oops - my mistake about JavaHelp: there's a method on
DefaultHelpBroker called setActivationWindow(Window) which
allows you to set the JavaHelp window's parent to the modal
dialog - then the JavaHelp window is fully accessible.
Alistair
Submitted On 02-MAY-2001
mckinney
Lets go Sun. There is no right or wrong behavior for
modality interaction with frames. There is, however, a
right and wrong approach to supporting multiple platforms.
Windows, the dominant windowing platform, happens to allow
modality to be chained. Therefore it is your
responsibility to support it.
Submitted On 04-MAY-2001
lmakosky
Sun, please tell us what the current targetted release for
this enhancment is. Also, please make publicly available
the document referred to in the
evaluation "http://javaweb.eng/~dpm/modal.txt".
Submitted On 13-JUL-2001
gbishop
jsirota:
I believe the windows behavior is right. I vote for a RFE
to let the programmer decide.
Submitted On 08-AUG-2001
walpj
If both modes (parent-blocking and all-frame blocking) are
offered, then the all-frame blocking must be confined to a
single AppContext.
Submitted On 16-AUG-2001
rwestbrock
Dear Sun JDK-Developers, please contact the developers from
IBM, as they had this problem fixed in Visual Age 2.0/3.0.
Submitted On 28-SEP-2001
nexirius
How would one build a multi application application, an
application which starts a number of other applications in
separate threads?
I am thinking of an application which behaves like the
windows desktop but which manages independent Java
applications.
Submitted On 20-NOV-2001
christoph76
hi nexirius, i am thinking of the same application and i
had to stop thinking about it as i discovered this bug.
After investing one year of learning java intensively i
finaly discovered i cant realize my plans, i cant belive it
arg!!!
Submitted On 31-DEC-2001
twoodruff
The Java Plug-in is a great example of why the current
behavior is undesirable. If one applet opens a modal
dialog, no other applets are usable until it is closed.
Submitted On 15-FEB-2002
gbishop
nexirius, christoph76
You can implement your own special frame based modality
guys. Just have all of your frames descend from something
that checks to see if they have a child that is
speciallyModal registered with them, if so, have them
ignore all input. On the other hand, there is no way to
have system level wide modality, and this should be the
focus of this RFE.
Submitted On 15-FEB-2002
gbishop
nexirius, christoph76
You can implement your own special frame based modality
guys. Just have all of your frames descend from something
that checks to see if they have a child that is
speciallyModal registered with them, if so, have them
ignore all input. On the other hand, there is no way to
have system level wide modality, and this should be the
focus of this RFE.
Submitted On 06-MAR-2002
jheid
I agree one good example is the plugin console.
Every console on windows won't work until this bug (as
there's not workaround) is fixed.
Submitted On 22-MAR-2002
jheid
Here is a workaround whichworks perfectly for me (although
not fully tested). You can see two JFrames. One of them has
a button to open a modal dialog. When the dialog is opened
one frame is editable the other not (as expected). When
closing the dialog both frames become editable and the
event handler methods which opened the dialog will finish
(the setVisible() method blocks).
public class NonBlockingDialog extends JDialog {
protected boolean modal = false;
public NonBlockingDialog (Frame parent, String title,
boolean modal) {
super (parent, title, false);
this.modal = modal;
}
public void setVisible (boolean visible) {
getParent ().setEnabled (!(visible && modal));
super.setVisible (visible);
if (modal)
try {
if (SwingUtilities.isEventDispatchThread ()) {
EventQueue theQueue = getToolkit
().getSystemEventQueue ();
while (isVisible ()) {
AWTEvent event =
theQueue.getNextEvent ();
Object src = event.getSource ();
if (event instanceof ActiveEvent) {
((ActiveEvent) event).dispatch ();
} else if (src instanceof
Component) {
((Component)
src).dispatchEvent (event);
}
}
} else synchronized (getTreeLock ()) {
while (isVisible ())
try {
getTreeLock().wait();
} catch
(InterruptedException e) {
break;
}
}
} catch (Exception ex) { ex.printStackTrace
(); }
}
public void setModal (boolean modal) {
this.modal = modal;
}
public static void main(String[] args) {
JFrame f = new JFrame ("Test Frame");
f.getContentPane ().add (new JButton ("Soll bedienbar
sein"));
f.setSize (300, 300);
f.setVisible (true);
f = new JFrame ("Abhängiger Frame");
final NonBlockingDialog dialog = new NonBlockingDialog
(f, "Test-Dialog", true);
dialog.getContentPane ().add (new JButton ("Klcik
mich"));
dialog.setDefaultCloseOperation
(WindowConstants.HIDE_ON_CLOSE);
dialog.setSize (300, 300);
f.getContentPane ().add (new JButton (new
AbstractAction ("Dialog aufrufen") {
public void actionPerformed (ActionEvent e) {
dialog.setVisible (true);
System.out.println ("Sollte erst weitergehen,
wenn Dialog geschlossen wurde.");
}
}));
f.setSize (300, 300);
f.setVisible (true);
}
}
Submitted On 10-APR-2002
jheid
Bugfix for the code above:
Change
if (modal)
to
if (modal && visible)
Submitted On 06-MAY-2002
lynnleboe
This is consistent on Solaris8, Windows, OSX1.3. This
fix is necessary to create a multi-user using the same
VM.
Submitted On 18-MAY-2002
john_p_elliott
The "work-around" stated in the comments is not useful is
you want to use readily-available Dialogs, such as Option
panes (or anything else that is not entirely home grown).
When will this be fixed? Come on!
Submitted On 17-JUN-2002
pham9747
I agree with gbishop that this windows behavior is right.
Dialogs should be globally modal as they are now. The best
thing is to give the options of either to block input to
all frame windows not just its parent or block input to
just the parent.
Submitted On 11-JUL-2002
moti-p
A partial modal dialog (window specific) workaround is in:
http://forum.java.sun.com/thread.jsp?forum=57&thread=148218
(see reply 4).
Submitted On 15-JUL-2002
vegala
A much safer workaround was adde to
http://forum.java.sun.com/thread.jsp?forum=57&thread=148218
It is an enhanced version of jheid's example included here.
A million thanks to jheid for his demo.
I also managed to write a JOptionPane that is modal to only
the parent. Please email if you would like a copy of the source.
Submitted On 30-JUL-2002
leedavies
The problem with the workarounds is that they don't fix the
undesired behaviour of standard Swing components such as
JDialog and JOptionPane.
It seems we still need a "modality type" adding to JDialog and
JOptionPane - please Sun...
Submitted On 12-AUG-2002
mporta
please sun it's really time to fix this bug! it has been
reported in 1997 !
and it is a BUG, not a RFE !!!
Submitted On 25-SEP-2002
vegala
mporta:
IT WAS A BUG until my project (NASA-CLCS) opened a SUN
trouble ticket against it. The next day it became an RFE.
Since it is an RFE Sun didn't have to fix it and closed the
trouble ticket.
Although this issue was fixed by BugID 4029855 it was later
reverted as a workaround for BugID 4058370.
SUN is been very irresponsible in fixing this issue.
Submitted On 29-OCT-2002
ssossalla
We developing a multi-frame Application with modal dialogs.
We had the same Problem - one modaldialog is blocking all
other TOP-Level-Windows in the hole Application! But what
is a multiframed-Application without possibility using all Frames
at the same time???
So we needed a solution for this. I tryed the Workaround from
jheid (thank you for the opensource workaround)
and was very satisfied! Only Problem is: Is is flickering
before opening and after closing NoneBlockingDialog!!!
Our application is having always only one mainframe per
session (client). For user is should be possible to work in
all session-windows in the application, also if there are
modal-dialogs opened on some session-windows.
And my Dialog is blocking only
the masterwindows, but not the session-windows.
// modified-Code from jheid:
public void setVisible (boolean visible) {
// Toplevel-Window bei modalen Dialogen disablen...
getParent ().setEnabled (!(visible && modal));
super.setVisible (visible);
if (modal && visible)
try {
// Wird der Thread im Event-Dispatcher-Thread
ausgeführt?
if (SwingUtilities.isEventDispatchThread ()) {
EventQueue theQueue = getToolkit
().getSystemEventQueue ();
while (isVisible ()) {
AWTEvent event =
theQueue.getNextEvent ();
Object src = event.getSource ();
boolean owner = isOwnerWindow
( src);
if ( event instanceof
ActiveEvent) {
((ActiveEvent) event).dispatch ();
} else if (event
instanceof PaintEvent) { // paintevents should be always
dispatched...
((Component)
src).dispatchEvent( event);
} else if ( src
instanceof Component) {
//
mouseEvents and KeyEvents not dispatching to
masterwindows!!!
if ( event
instanceof MouseEvent || event instanceof KeyEvent) {
if (!
owner)
((Component) src).dispatchEvent (event); // event
dispatchen...
} else
((Component) src).dispatchEvent (event); // event
dispatchen...
}
}
} else synchronized (getTreeLock ()) {
while (isVisible ())
try {
getTreeLock().wait();
} catch
(InterruptedException e) {
break;
}
}
} catch (Exception ex) { ex.printStackTrace
(); }
}
private boolean isOwnerWindow( Object src) {
boolean owner = false;
Window source;
if ( ! (src instanceof Window))
return false;
source = (Window) src;
Window parent = this.getOwner();
while (parent != null && owner == false) {
owner = (source == parent);
parent = parent.getOwner();
}
return owner;
}
Submitted On 29-NOV-2002
fancellu
5 years, and not a fix! You couldn't make this kind of stuff up.
Who is in charge of fixing bugs at Sun? Rip Van Winkle?
Submitted On 01-DEC-2002
pepeio
Seems that the link given in evaluation is dead.
Nevertheless, even without reading the content of the link,
i agree that this had to be a RFE since the beginning, as we
need to specifiate the modality mode. API has to be enhanced
in order to take that in account.
Submitted On 05-DEC-2002
nuff-respec
I think this is incorrect behavior. If I have an application,
that launches a non-modal section and it lauched a modal
dialog (like a progress bar/ monitor) for a lenghty task, the
original application should NOT be affected, as the user would
like to continue working in the main application.
Thanks for the solutions .. the flickering is annoying but much
better than the alternative. Since 1997, and no other API to
support a "owner-style", what a shame.
Submitted On 06-DEC-2002
cradle
I've been using vegala's version of jheid's workaround,
and I'm trying to understand the problem vegala
describes: "In some OSs the WindowListener may force
the dialog and the parent window to pop to the front
in a loop. Please test by clicking on the parent window
while the PMDialog is up."
I've only observed this problem under Solaris. Even
then, it's dependent on the window manager I use.
For example, I don't see the problem with KDE's window
manager, but I do see it with fvmw2.
One interesting discovery: on Windows (XP, jdk 1.4.1),
the windowActivated() method in the parentWindowListener
is never actually called, which means that getFocusBack()
isn't called, either. I can comment out all but the
first two lines of initDialog() (which set the owner and
modal fields), with no change in behavior (so far) --
all the magic seems to be hapenning in setVisible().
Under solaris, though, getFocusBack() is actually used.
Without it, the blocked parent frame can become
the active window, although it remains insensitive and
the stacking order is preserved.
Hmmm.
Submitted On 11-DEC-2002
mmartak
This is useful to our business as well.
Submitted On 07-MAR-2003
str6
i'm trying to write a multi-window application that allows
users to start as many concurrent windows as they need.
these windows need to open modal dialogs while allowing the
other windows to remain functional. the currently
implemented all-or-nothing approach to modality is
frustrating. i am very disappointed that this bug is taking
so long to fix.
Submitted On 07-AUG-2003
cbratschi
Is there still no acceptable fix for this bug?
I'm working on a project with many frame windows. It's
confusing that one modal dialog blocks the whole
application. I never saw such a default behaviour on any
platform I used.
Sun, please fix this in Java 1.5.
Submitted On 09-AUG-2003
tzander2
Marking this as a RFE seems silly to me, as the behavior requested is
done in every toolkit in the industry today. Except for AWT (and thus
Swing).
If the enhancement is made but the default is left to the current state
of things, then it is just another bad default in Swing. It already takes
way to many lines to do things that other widget sets have per default
(and the user expect).
Submitted On 18-AUG-2003
cbratschi
The locking code didn't work, the wait() forever blocks the
calling thread. I modified this part and added a more
flexible way to choose the modal handling. Thanks go to all
previous authors.
public class TDialog extends JDialog
{
private int modality;
private boolean inModalLoop = false;
private boolean inTreeLock = false;
//modality
public static final int MOD_NONMODAL = 1;
public static final int MOD_MODAL = 2;
public static final int MOD_SYSMODAL = 3;
public TDialog(JFrame parent,String title,int modality)
{
super(parent,title,modality == MOD_SYSMODAL);
this.modality = modality;
}
public TDialog(Frame parent,String title,int modality)
{
super(parent,title,modality == MOD_SYSMODAL);
this.modality = modality;
}
public TDialog(JDialog parent,String title,int modality)
{
super(parent,title,modality == MOD_SYSMODAL);
this.modality = modality;
}
public TDialog(Dialog parent,String title,int modality)
{
super(parent,title,modality == MOD_SYSMODAL);
this.modality = modality;
}
public TDialog(String title)
{
super();
modality = MOD_NONMODAL;
setTitle(title);
}
public void setVisible(boolean visible)
{
Component parent = getParent();
if ((parent == null) || (modality != MOD_MODAL))
{
super.setVisible(visible);
return;
}
//handle parent modality
parent.setEnabled(!visible);
super.setVisible(visible);
if (visible)
{
inModalLoop = true;
try
{
if (SwingUtilities.isEventDispatchThread())
{
EventQueue theQueue =
getToolkit().getSystemEventQueue();
while (isVisible())
{
AWTEvent event = theQueue.getNextEvent();
Object src = event.getSource();
boolean owner = isOwnerWindow(src);
if (event instanceof ActiveEvent)
{
((ActiveEvent)event).dispatch();
} else if (event instanceof PaintEvent)
{
//always dispatch
((Component)src).dispatchEvent(event);
} else if (src instanceof Component)
{
//filter events to owner
if ((event instanceof MouseEvent) || (event
instanceof KeyEvent))
{
if (!owner)
((Component)src).dispatchEvent(event);
} else
{
((Component)src).dispatchEvent(event);
}
}
}
} else
{
Object lock = getTreeLock();
synchronized(lock)
{
inTreeLock = true;
while (isVisible())
{
try
{
//wait 10 ms (low overhead)
getTreeLock().wait(10);
} catch (InterruptedException e)
{
break;
}
}
inTreeLock = false;
}
}
} catch (Exception e)
{
e.printStackTrace();
}
inModalLoop = false;
}
}
private boolean isOwnerWindow(Object src)
{
boolean owner = false;
Window source;
if (!(src instanceof Window)) return false;
source = (Window)src;
Window parent = this.getOwner();
while ((parent != null) && (!owner))
{
owner = (source == parent);
parent = parent.getOwner();
}
return owner;
}
public int getModality()
{
return modality;
}
public void setModality(int modality)
{
this.modality = modality;
}
}
Submitted On 31-OCT-2003
cpell
Now that 1.4 has added Window.setFocusableWindowState, which
can prevent keyboard input, a workaround is as easy as using
that and forcing the glassPane to catch MouseEvents. So
Swing users can do this:
dialog.addComponentListener(new ComponentAdapter()
{
public void componentShown(ComponentEvent event)
{
setParentFocusability(event, false);
}
public void componentHidden(ComponentEvent event)
{
setParentFocusability(event, true);
}
private final MouseListener dummyMouseListener =
new MouseAdapter() { };
private void setParentFocusability(ComponentEvent event,
boolean focusable)
{
Component root =
SwingUtilities.getRoot(event.getComponent());
if (!(root instanceof Window))
{
return;
}
Window parent = ((Window) root).getOwner();
if (parent == null)
{
return;
}
parent.setFocusableWindowState(focusable);
if (parent instanceof RootPaneContainer)
{
RootPaneContainer r = (RootPaneContainer) parent;
Component glassPane = r.getGlassPane();
/*
* The glass pane won't intercept MouseEvents unless
* at least one MouseListener has been added.
*/
if (focusable)
{
glassPane.removeMouseListener(dummyMouseListener);
}
else
{
glassPane.addMouseListener(dummyMouseListener);
}
glassPane.setVisible(!focusable);
}
if (focusable)
{
/*
* When setFocusableWindowState(false) was called,
* the parent window's focus owner became null,
* so we need to restore the focus owner ourselves.
*/
parent.getMostRecentFocusOwner().requestFocusInWindow();
}
}
});
Submitted On 07-NOV-2003
fadeyev
If dialog is modeless, its parent window can be disabled
before dialog is shown and enabled after it is hidden.
dialog.addComponentListener(new ComponentAdapter()
{
public void componentShown(ComponentEvent event)
{
setParentFocusability(event, false);
}
public void componentHidden(ComponentEvent event)
{
setParentFocusability(event, true);
}
private void setParentFocusability(ComponentEvent
event, boolean focusable)
{
Component root = SwingUtilities.getRoot
(event.getComponent());
if (!(root instanceof Window))
return;
Window parent = ((Window) root).getOwner();
if (parent == null)
return;
parent.setEnabled(focusable);
if (focusable)
{
parent.getMostRecentFocusOwner().requestFocus();
}
}
});
Submitted On 25-NOV-2003
msenin
RFE or not, I'd like to have same behaviour and API in Java
as in Windows or Linux, which is being able to set APP_MODAL
or WINDOW_MODAL state of modality to the window.
Submitted On 08-JAN-2004
psypar
It’s amazing to see this issue un-resolved for so long
where the issue is fundamental as this.
If i have different instances of the same application
running and one pops up a dialog and doing so does
not allow me to access any other instance running
would be stupid
The dialog, which popped up, should only belong to
the parent who initiated this and should not affect any
other instances ...
Why no action? It puzzles me :(
parthi.
Submitted On 04-FEB-2004
untilted
one issue that noone seems to mention, is that
modality on a single particulr window can cause
problems if that window somehow manages to get in
front of the modal dialog it is displaying.. this routinely
happens to me on windows systems, where some
apps like winrar or paintshop pro give a message, that
manages to sink under its owner after a few window
shufflings.. the issue is less likely to occur if every
window in the applicaiton is blocked by the modal
dialog...
Submitted On 09-FEB-2004
vegala
This is a question for SUN’s Java Development Team:
WHY IS THIS ISSUE NOT FIXED IN TIGER (JDK1.5)??
Last time I talked to Sun tech support, this RFE was pushed
to TIGER after been promised a fix in Merlin (JDK1.4) and
never getting a resolution. Now that 1.5 beta is out, I
find myself without a fix to this problem again.
I find it irresponsible that this issue is been dragged for
more than 6 years without a fix.
I may have come up with a temporary solution (read previous
comments) to this issue, but it is less than perfect and
does not work in all platforms.
Submitted On 08-MAR-2004
cradle
I just noticed this project, though I haven't tried it yet:
http://jmodalwindow.dev.java.net/
Submitted On 10-MAR-2004
vladimirkondratyev
It's a shame for AWT/Swing team that they do not fix such
requests for ages.
Submitted On 24-MAR-2004
TripleTuned
This is so typical for Java SWING. Sometimes I believe
they doing this on purpose.
Submitted On 25-MAR-2004
oleg.sukhodolsky
The problem is that native platform (Solaris & Linux)
doesn't provide good support for this :(
Submitted On 19-APR-2004
Rippuru
There is good reason not to support modal windows. Windows
might support a desktop-wide model window, but other system
might not. And on systems where modal windows are possible
you should not use them. Think about it: two application
instances might compete with eachother to have their model
window on top.
It is up to the user to decide what window is displayed on
top and what window has input focus. Applications should not
dictate these things. It only limits useability.
Submitted On 04-MAY-2004
vegala
oleg.sukhodolsky:
Both Solaris and Linux provide support for APP_MODAL dialogs.
Rippuru:
Have you ever worked on in a real world multi-threaded
development project?? This option is widely used on high
scaled projects.
-----------------------
There is no reason why this option is not available except
for Sun’s unwillingness to implement the fix.
Come on guys, it is been almost 7 years since this issue was
created. And IT WAS A BUG UNTIL 2001 when SUN decided to
changed into an RFE.
Submitted On 05-MAY-2004
oleg.sukhodolsky
vegala: Both Solaris and Linux provide support for
APP_MODAL dialogs.
We use this support and have problems with it :(
Java programmers don't think much about good
hierarhy of modal windows :( And javadoc allows
this. So we have to think how to workaround existed
problems, and so I, personally, prefer do not add one
more bogus feature.
Submitted On 19-MAY-2004
vladimirkondratyev
To oleg.sukhodolsky:
>Java programmers don't think much about good
>hierarhy of modal windows :(
they should. The problem is that good Java programmers
cannot create good GUI applications with current API. I
suppose that you will never find workaround for existing
problems util AWT play by native windwing system rules. I
perfectly understand that it's out of your scope but Javadoc
should be clarified to reflect real situation. For example
new focus subsystem was introduced in JDK 1.4. The Javadoc
now clearly states that some operations are system
depending. It's OK. But the result is that now it's possible
to do some manipulations with focus (and it wasn't possible
in 1.3, because focus is 1.3 was a kind of magic). We, Java
developers, are waiting 1.5/1.6 as a good point of real GUI
improvements. I hope that every people understand that it's
impossible to create cross-platform application (application
without platform-specific Java code) that will be consistent
on every platfom. But it's rather deal of Java developer to
make application consistent (not a deal of AWT). AWT should
only help us providing API to native windowing system.
Submitted On 24-MAY-2004
dione@mso
Modal dialogs (or dialogs in general?) seem to be a perennial problem! I have just been browsing the bug database and the
whole situation is rather confusing :( I have a need for full
application modal dialogs in the development I'm doing but
appreciate that owner-style modality is also needed. Java is
a desirable language to develop with but for crying out loud,
PLEASE GIVE SERIOUS ATTENTION TO SUPPORTING GUIs!!!
Will be much appreciated.
Submitted On 03-JUN-2004
xuhaoqing
This bug or ref bites me as a Swing developer for years!
Yes it's years!
Submitted On 14-JUN-2004
vegala
This is really funny.
According to the document this bug report was submitted on 24-MAY-2004, but it was evaluated on January 20, 1999 and the 1st comment was writen on 17-APR-1999
GUESS WHAT SUN, the 1st issue of this bug was submitted on 03-FEB-1997 (4029855 ) and after it was fix, somebody broke it to fix 4058370 (on 11-JUN-1997).
IT IS ABOUT TIME YOU FIX THIS PROBLEM!!!
YES!!! Even with my workaround (see previous comments) this is still a problem that needs to be addressed.
Submitted On 23-JUN-2004
singer_regnis_de
When this BUG ever get fixed? Anybody there at Sun? Or everybody burnt?
Submitted On 26-JUL-2004
xuhaoqing
God, I begin to love J# + Windows Forms. Is it my guilt?
Submitted On 20-SEP-2004
cradle
Here's a java.net article on the JModalWindow project, published earlier this month:
http://today.java.net/pub/a/today/2004/09/07/modal.html
Project home page:
https://jmodalwindow.dev.java.net/
Submitted On 01-OCT-2004
vegala
Amazing!!! Tyger is out (1.5) and this BUG is still open.
Even as an RFE is being in the top 25 for the past 3 years, but SUN refuses to fix it.
Submitted On 02-OCT-2004
charlie76
WTF is the reviewer talking about. This is NOT how window's works in all cases. Open IE now choose File > New Window. Now choose Tools > Internet Options. Leave that dialog open and Atl-Tab back to the first IE window. Can you get to it? Hell yes. Now open TaskManager see that there is only ONE process of the IEExplorer.exe running. Select it and choose End Task > Yes option. Now did both of your windows go away? Hell YES! Window's has parent context modality and the whole app modality. It has both. Just fix this problem. Damn how much do we need to vote for this.
Submitted On 06-MAY-2005
Replouf66
Since 18-SEP-1997 !!
what a shame !
Submitted On 26-MAY-2005
GRenard
It's reported as closed, but when I open a modal dialog, and in this one I open a non-modal dialog, everything is blocked on the second one. (using Java5)
Normal ?
Submitted On 26-MAY-2005
vegala
GRenard
This bug/REF was fixed for the next version of Java. JDK1.5 will not include the fix (as far as I know).
Submitted On 28-MAY-2005
Replouf66
Great, work well know :)
GRenard, try the mustang b38 (Java 6)
dialog.setModalityType(Dialog.ModalityType.DOCUMENT_MODAL);
Submitted On 24-AUG-2005
JimmySMith
Yet another reason to switch to SWT, it's developers care a lot more about GUI quality/performance... is it any wonder that the most popular Java apps (Eclipse, Azureus) use SWT?
Submitted On 15-SEP-2005
rmoore_jdc
there is a good workaround for this bug.
see forum thread 215788, reply #14
Submitted On 29-SEP-2005
elkner
Which forum? Possible to provide an URL ?
Submitted On 04-APR-2006
MortenHjerlHansen
elkner, it's here:
http://forum.java.sun.com/thread.jspa?forumID=257&threadID=215788
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
