I am facing a very strange issue: I have a non-modal JDialog in a very complex Swing application. There is a situation where another (modal) dialog opens above the non-modal one. After closing the modal dialog, it is no longer possible to click on anything in the non-modal dialog. After adding a FocusListener I realized that the focus cannot be gained. I am not able to click on any button or slider inside the dialog, nor does it react if I click on its title bar. Whenever I am trying to do so, an OS sound clip is being played which you would normally expect to hear when trying to click on a component while another modal component is still visible. But it's not.
Fun fact: the bevavior goes away when another modal window of any kind is being opened and closed again! After that, the non-modal dialog re-gains the focus.
I apologize for not being able to post the code here, as dozens of classes are involved to reproduce this. But if maybe anyone has ever come across a similar issue or behavior and knows where it comes from, it would be great if you shared your knowledge about how to overcome it.
Thanks in advance!
Related
I need to drag windows that do not have keyboard focus on Windows 10 computers. Swing functions on my PC deny "mouse focus" on all windows in the same java application; they are locked out of being moved or uncovered for viewing.
The latest Swing dialog window controls the show; any other window that is needed for viewing (to help on answering the dialog) is unavailable when it is covered by another application window. On the Mac/OS X, mouse focus is not a problem; all windows seem to have it.
Is there a way to get this "mouse focus" on the PC when using the convenient modal Swing functions?
The 3 windows at issue in my application are:
Dialog: The latest Swing dialog hording all the mouse focus
Blocker: A JFrame or JDialog window that may or may not be an ancestor of Dialog but it is a big enough window to block view of Blockee
Blockee: The one that has information needed to answer the Dialog.
Only Dialog can be dragged on Windows 10 in this situation.
Is moving the information needed into the Dialog the only answer?
Are there windows 10 settings that can make it perform more sensibly?
I tried using different threads for Blockee and Blocker to no avail.
I found a fairly easy workaround for many cases: Identify the Blocker window and then take away its focusability (perhaps temporarily) when it might be a blocker and is no longer needed.
java.awt.Frame blocker = this; // or <parent> <grandparent>, etc.
blocker.setFocusable(false);
This does not make the Blocker or Blockee window moveable but it eliminates the problem by preventing the blocking. Maybe some day there will be a better solution for this in Windows 10.
I wrote a data plotter application a while ago, which has an autoreload feature. Both load and reload action cause a JDialog with a cancel button to pop up. In autoreload mode this happens every several seconds, with the JDialog window requesting focus every time.
I tried calling setFocusableWindowState(false) on the JDialog instance, but that did not make any difference. Could it be because it's a JDialog rather than some other subclass of Window?
UPDATE: setFocusableWindowState(false) does work, I was just stupidly running the wrong jar file. Long story. Anyway, I'm not deleting the question because when I did a little bit of research before posting it, I saw a few other people having trouble with similar issues. This is the solution :)
You have to put these two statements, in the constructor of your class extending JDialog
setFocusableWindowState(false);
setFocusable(false);
So when each time the JDialog appears, the parent container will still have focus on whatever it had.
setFocusableWindowstate() does work, after all. It was my own stupid mistake: I was running the wrong jar file, i.e. not the one with the fix. Thanks to everyone for their suggestions.
I have a non-trivial Java applet. It has a menu, and via that menu applet shows a dialog that extends JDialog. Dialog is shown using setVisible(true). When user finishes working with that dialog, dialog is closed (after pressing "done" button) using this.dispose().
Now, there's a strange problem - applet works fine in Firefox, even in IE but in Chrome, when applet shows some other (dialog) window, that window is shown behind the applet. I have to click on the place where dialog should be in order to show it (bring it to front). If I click it again (while it's shown) it will disappear (go to background) again. Button clicks are working as usual, but whenever I click at popup window itself (even it's title-bar) it changes it's "visible" state.
Please, any idea what's wrong? How to resolve that bug?
// the applet will typically appear inside a Window, get a reference to it using:
Window parent = Window.getWindows()[0];
// use the window as the parent of a modal dialog.
JDialog dialog = new JDialog(parent);
dialog.setModal(true);
// ...
dialog.setVisible(true);
// won't be called until the applet is dismissed
someJComponent.requestFocusInWindow();
Applets embedded in web pages will always be subject to modality and focus problems. For a better user experience, launch the applet free-floating using Java Web Start, or even better still, launch a frame using JWS.
Setting: Java 5 - no upgrade possible.
I have a large application that has a number of modal dialog windows. I have heard that hidden modal dialogs can result in uninformed users going so far as to restart their computer. Even if a user knows how to ALT-TAB (in MS Windows, at least), it's a pain. From what I understand, this was in part fixed in later versions of Java, but that's not an option here, unfortunately.
So, is there any way to force a modal dialog to be shown if any part of the running application is clicked on? I was thinking it might have something to do with either MouseListeners, GlassPanes, or something else. However, I've got a bunch of other stuff I'm supposed to be working on, so I don't have a lot of time to devote to hashing this out right now. Can anybody point me in the right direction?
Thanks so much!
So, is there any way to force a modal dialog to be shown if any part of the running application is clicked on?
When you create the dialog you need to specify the parent frame as the owner of the dialog. Then whenever you click on the frame any dialog that is a child will also be shown.
I have an application that runs in fullscreen mode and has been working fine. Now I need to add a simple, undecorated dialog and I'm running into trouble. If I run the application maximized but not in fullscreen, the dialog displays and functions as expected. When I switch back to fullscreen, the dialog will not display.
The dialog extends JDialog and only contains a JSlider and a couple of buttons. It is undecorated and not modal. (I disabled modality for testing purposes -- it was a pain to force exit the app every time the dialog blocked input.) I'm entering full screen mode using setFullScreenWindow(), passing in the main JFrame for the app. It doesn't make a difference if I set that very JFrame as the owner of the JDialog or not. Nor does it seem to help if I call toFront() on the dialog.
The dialog seems to be active -- especially since it blocks input if I make it modal -- but just not showing or being hidden. So, is there any obvious trick to displaying a JDialog in fullscreen mode? Something I might be overlooking or omitting?
If there's no obvious solution, I can post some code later. Unfortunately, I don't have time right now.
JOptionPane.showInternalXXXDialog()
methods render dialogs as JInternalFrames.
Maybe you could consider using a JIternaFrame to simulate the dialog box.
And in fact, as M1EK alluded in his answer and I mentioned in a comment, Java applications in full screen mode will not allow other windows to show over them. The Javadoc API for GraphicsDevice reads:
Windows cannot overlap the full-screen window. All other application windows will always appear beneath the full-screen window in the Z-order.
In the end, I reconfigured my application so that it doesn't enter full screen mode until a bit later. This still gives me a fairly class presentation at the start and allows my JDialog to function as it should. The transition to full screen mode is quick and smooth, even in the "middle" of my app.
Do you really want to be in full-screen mode for this app? That's more of a gaming feature - to get more direct access to the frame-buffer, I always thought. Have you read this tutorial:
http://java.sun.com/docs/books/tutorial/extra/fullscreen/index.html
Really seems to me not to be the best choice for a Swing app with child windows.
Try to use this. Is not an exclusive full screen but it is close enough.
setExtendedState(JFrame.MAXIMIZED_BOTH);
setUndecorated(true);