I have a modeless dialog box being generated which prompts users to open a new window. The box can be opened in two ways, either directly from the file menu for the frame I'm writing or indirectly via the framework my panel is plugging into.
When I make the call directly via the file menu the dialog box comes up with focus exactly as I want. But when I have the framework indirectly open the dialog box it does not have focus as it should.
There doesn't seem to be a difference between the two methods of opening the dialog, in both cases a load function is called and it's not until 5 method calls later the dialog box is opened. In both cases the frame which generates the dialog box is realized at the time the box is generated. I've tried calling requestFocus after making the dialog box visible but it doesn't seem to do anything.
Any suggestion why the dialog box wouldn't have focus, or how I can give it focus as a separate window from the window that usually has focus?
in some cases is hard to set Focus to the expected top-level container as are demonstrated here , but for excelent workaround would be better look at camickr's Dialog Focus
When you create the dialog, try setting the main GUI as parent of the dialog.
In the first case, when you click from menu, it automatically sets the main GUI as the parent of the dialog, but it doesnt in the second case.
So make sure when you create the dialog, you are setting the main GUI/ window as parent always.
It should help most times.
Related
I am wondering how you can change something in a parent window using a child window. So, let's say I have a window, that opens a pop-up window on the press of a button. That new window contains a JTextArea and another button called Ok. How can I change the title of the parent window based on what's inside the JTextArea when the Ok button is pressed?
The way I see it, there are two common ways to do this:
The child window could push the information into the parent window when OK is pressed. For this to occur, the child window would need a reference to the parent window and then call a public method of the parent.
The parent window could pull the information from the child. This can occur in one of two ways.
If the child window is a modal dialog, then the parent could simply query the child window once the dialog has been dealt with and program flow returns to the parent's code.
If the dialog is a non-modal dialog, then the parent window would need to add a listener to the child, say a PropertyChangeListener, and when the appropriate event is triggered by this listener, the parent window would query the dialog window for the information. This would be an example of using the Observer design pattern.
I much prefer the pull technique since because it is the parent that is the object that has code to display the child window and that needs the information from the child window, it should have the code to extract the information needed, and the child window would need to have no knowledge of or reference to the parent window object. This seems much cleaner to me.
For an example of this, please check out my code here, here and here.
Edit: Note that for the example that you described, you could easily solve this by using a JOptionPane. Many don't know that JOptionPanes can display very complex GUI's; basically anything that can be put onto a JPanel can be displayed in a JOptionPane (and then some). You would simply display the JOptionPane that shows your JTextField, and when program flow returns to the calling program, simply get the text held by the JTextField that was displayed in the JOptionPane. Nothing could be simpler.
I'm trying to create a multi-windowed interface, ala GIMP. One of them allows the user to load an image, to be displayed in the frame. So, when the program loads, all windows (two for now but I plan to have three) are shown in the application bar. However, when the second* window invokes JFileChooser, it disappears in the application bar (but does not close). But if I <Super>+<Tab> or <Alt>+<Tab> it still appears there. It also reappears in the app bar when I click the "Show/Hide All Windows" button.
All JFrames are invoked from a single Runnable. Anyone else encountered this issue? How do I work around this one (i.e., make all windows visible in the application bar at all times)?
Thanks!
*I called it the second window since it is the second one that is setVisibled to true.
A JFrame will appear on the task bar. A JWindow or JDialog do not appear on the task bar.
A JFileChooser uses a JDialog to display the date so it will not appear on the task bar. You need to specify a JFrame as the owner of the file chooser. The file choose will still not appear on the task bar, but when you click on the icon representing the owner frame it will become visible along with the frame.
In my application, on some screen, I launch a popup. Depends on what button the user will click on this popup, another popup has to be launched. I use JDialog object to implement these popups. The issue is that the second popup doesn't show up (even though is use setVisible(true) and toFront()). It's created but I can't see it. I defined in its constructor the first popup as its owner. Anyone can help?
When a JDialog is opened from a parent window or dialog, and set to be modal, the Event Dispatch Thread for the parent window is halted. This prevents the parent from being focused or from passing other events, or essentially doing anything until the modal dialog is closed. The call is therefore blocking.
What you must do instead is fire your event from somewhere else, like the new dialog instead of the parent window, OR instead of using modal dialogs, use a regular JFrame and set it to be always on top using setAlwaysOnTop(true). That means the user can continue to use the parent window, and events will still fire from it.
Addendum: in response to your problem "the program concentrates in showing it and doesn't react to the event that has to hide it": when you make a dialog modal, as soon as you make it visible, it will block the parent window until it is closed, including event firing. If you need the new popup to be closed programatically, you either need to make the popup non-modal, or you need to execute the subsequent code in the context of the new popup window (such as firing an event when it becomes visible)
OK, now I managed to show the second popup. The code in the event that triggers the popup is:
printingWindow.setLocationRelativeTo(null);
printingWindow.toFront();
printingWindow.setModal(true);
printingWindow.pack();
printingWindow.setVisible(true);
But now I have a different problem:
when the printingWindow is set to be visible, the program concentrates in showing it and doesn't react to the event that has to hide it.
The code that is executed when the appropriate event is fired is:
printingWindow.setVisible(false);
printingWindow.dispose();
So how I close this popup (by firing the event)?
I Have a java program that does sort of this:
It starts off with dialog boxes, then after user clicks OK/Cancel or X or whatever, it goes to JFrames or dialog boxes. The JFrames also have buttons like Next/Ok, etc. As the program goes on, one JFrame (lets call it "Status Bar") is always visible on the screen and never goes away (that's what I want). (I don't want to dispose it because they hold important information that the user needs to see while making choices on future dialog boxes and other JFrames).
Now my problem occurs..when the future dialog box appears, I can't click on that JFrame "Status Bar". For some reason, I have to do something on the dialog box first. Like I have to click Ok/Cancel on the dialog box, if I get another dialog box (depends where on the program), I have same issue. Until I am blessed with another JFrame, then I can click on the "Status bar" JFrame, click buttons on it and all the good things presented on that JFrame.
One solution is to convert all my remaining dialog boxes to JFrames, but that would take a lot of time since I have all sort of dialog boxes. And then linking everything together will be time consuming.
So is there a function or code that I can tell Java...to give the user the power to interact with JFrame "Status Bar" while a dialog box is presented on the screen.
I Hope I am making sense. Please ask if something is not clear. I appreciate the help.
If you're using Java 6, you can use the new modality settings.
Modality in dialogs
Depending on your GUI design, you may wish to make the dialogs Document modal as opposed to modeless(equivalent to setModal(false)). Note that this will only work if the dialogs are shown in a different root container than the Progress JFrame.
Another option is to set a modal exclusion on the JFrame you want to be always visible. This way your dialogs can still block other frames and you don't need to remember to setModal(false) everytime you add a new dialog:
progressFrame.setModalExclusionType(Dialog.ModalExclusionType.APPLICATION_EXCLUDE);
Call setModal(false) method on all dialogues so that you will be able to go to JFrame while JDialog is open.
I am creating an options dialog using JOptionPane.showOptionDialog(...)
When I click one of the buttons added to this dialog, I need a label to apear underneath on the dialog (and this label should be scrollable if necessary). I have written event handlers for the buttons, but I am not sure how to get this label to appear on the dialog.
Any help would be great.
Update: I realized that it would be ok if I somehow called JOptionPane.showOptionDialog(...) with an initial message, and then when one of the buttons was clicked I would change the message. Is this possible?
JOptionPane static methods are only shortcuts to easily create a dialog with option buttons and a fixed message. If you check the source from it, you will see that all is wrapped in this purpose. It's only a convenience class over a frequent use case of dialogs.
The suggestion from comment is correct, if you want more than this, you will have to create your own JDialog, as it will be easier than trying to change something from this generated dialog.
Edit: You can create your own JDialog yourself, using layout managers. A more simple way, suggested as well in the previous link, is to use a GUI builder, like the one included in Netbeans.