Im trying to make a java program that will popup/notify me to stop what I am currently doing and do something. more like a reminder. My question is how will I make a pop up in java.
I found this docs, but dont know how to implement for the parent component.
JOptionPane.showMessageDialog(??,"this is a modal dialog.");
The answer depends, do you have a parent component (like a JFrame or other component) or are you simply display the JOptionPane independently?
If you are simply displaying the JOptionPane independently, you can simply pass it null.
If you are displaying the JOptionPane as part of a large application, with windows and other components, you can simply pass it a reference of what ever component you want the JOptionPane to displayed relative to, such as the window or most accessible container/component
The parent argument (if supplied) simply allows the dialog to act as a modal (blocking) dialog for the window which contains the supplied component. This requires the user to have to dismiss the dialog before they can continue to interact with the parent window/component
Take a closer look at How to Make Dialogs for more details
Related
I am working on an application that will have the following feature:
The application will have a "Load Image" button to open an image and settings modal dialog. It will need to block until that dialog returns, either with the results of the processing or null if the user changed his mind.
The image and settings dialog will allow the user to select an image using a JFileChooser dialog and to specify to what level of detail to process the image. Clicking a "Load" button will open a load dialog.
The load dialog needs to be a custom-designed dialog that reports in detail about the time-consuming processing of the image. If the user allows the processing to finish, it needs to close and return the object back to the original dialog, which needs to close and return that object back to the application. If the user decides it is taking too long to perform the processing, he can cancel the load, closing the loading dialog and returning to the image and settings dialog.
Conceptually, this does not seem so difficult to me. However, when I try to determine how to get this to work within Swing, somehow I cannot put it together. From what I've read, GUI components need to be instantiated in Swing's event thread since many of them are not thread-safe. These same components need to block on calls similar to (but not the same as, since I need to write custom components) the JOptionPane.showInputDialog() methods. But these calls need to instantiate new components in the event thread and wait for events to occur in the event thread before returning a value to the application. Compounding this with the fact that I need a dialog to pop up from a dialog, I feel quite lost.
I have read the Java Tutorial on dialogs and several posts on StackOverflow and other sites trying to determine how I can design classes that work correctly. Somehow, I just don't understand how this can work at all (isn't the event thread going to sleep after the first blocking call?), and how I can write the custom classes I need to make this work. Frankly, I am not certain I understand my confusion enough that I was able to explain it.
Could someone please explain what goes on under the hood when modal dialogs have been instantiated? How I can write dialog classes that behave the way I need as described above?
The application will have a "Load Image" button to open an image and settings modal dialog. It will need to block until that dialog returns, either with the results of the processing or null if the user changed his mind.
OK, so this dialog will need to be modal. That much we know.
The image and settings dialog will allow the user to select an image using a JFileChooser dialog and to specify to what level of detail to process the image. Clicking a "Load" button will open a load dialog.
OK, so the load dialog will need to be modal off of the image and settings dialog. No biggie there either.
The load dialog needs to be a custom-designed dialog that reports in detail about the time-consuming processing of the image. If the user allows the processing to finish, it needs to close and return the object back to the original dialog, which needs to close and return that object back to the application. If the user decides it is taking too long to perform the processing, he can cancel the load, closing the loading dialog and returning to the image and settings dialog.
OK, so the load dialog code will need to instantiate and execute a SwingWorker to do the time-consuming image processing in a background thread, and then have the SwingWorker use its publish/process method pair to push information about the processing details back to the load dialog.
...From what I've read, GUI components need to be instantiated in Swing's event thread since many of them are not thread-safe.
Correct.
These same components need to block on calls similar to (but not the same as, since I need to write custom components) the JOptionPane.showInputDialog() methods.
And this is what a modal JDialog allows you to do. Another option to keep in mind is to use a JOptionPane and pass in a JPanel with whatever GUI you want the JOptionPane to display. JOptionPanes are surprisingly flexible and useful.
But these calls need to instantiate new components in the event thread and wait for events to occur in the event thread before returning a value to the application. Compounding this with the fact that I need a dialog to pop up from a dialog, I feel quite lost.
Again it's simple. The load dialog will call a SwingWorker which will communicate back to the load dialog.
Could someone please explain what goes on under the hood when modal dialogs have been instantiated?
Now you may be asking a bit too much for the volunteers on this site to do, since this question would probably require someone to write a complete tutorial to answer, and it has been asked and answered before, so the information should be discoverable by you. If you really want to see what is going on under the hood, you should first do the preliminary research on the subject yourself, look at the source code, and if still stuck, ask a much more specific and answerable question after first doing your own due diligence work.
Modal dialogs started from the primary event loop spawn a secondary event loop that remains active while the primary loop is blocked. See java.awt.SecondaryLoop.
It seems that making a new JFrame to act as a dialog box isn't the best way to do this as it seems tricky to grab the specific value from the class which creates it.
I basically want to make a dialog box with a large number of buttons, which once a user clicks on one, the main class will grab that value. If I make a frame to do this, getting that value is tricky (but it's much easier to design in Windowbuilder Pro) but it also means the user can still interact with the main frame while this frame is presented.
What's the best way to create such a dialog box?
Use a JDialog or JOptionPane instead. If you want the user to be able to interact with the frame while it is open, it should be non-modal, but then you have the problem of knowing when it is closed in order to get the values.
See also:
The Use of Multiple JFrames, Good/Bad Practice?
How to Make Dialogs
How to Use Modality in Dialogs
I'm making custom dialogs that I want to pop up and disable the main shell behind it so that it cannot be clicked while the dialog is active.
My initial plan was something like as follows:
shell.setEnabled(false);
doDialogStuff();
shell.setEnabled(true);
this worked but as I close the dialog, it loses focus of the shell that was open before the dialog. I managed to sort of fix it by adding
shell.setFocus();
after the last line but this is messy and causes the screen to flicker as the window loses and then gains focus in a split second, also, it sometimes doesn't regain focus and I can't understand why :/
Is there a better way to disable the background window without it losing focus.
Thanks in advance SO peeps
You should create a custom dialog based on this tutorial.
This way you just have to set the modality of the dialog to whatever you need exactly and the dialog will take care of the rest for you.
This should be helpful as well (Javadoc of Shell):
The modality of an instance may be specified using style bits. The modality style bits are used to determine whether input is blocked for other shells on the display. The PRIMARY_MODAL style allows an instance to block input to its parent. The APPLICATION_MODAL style allows an instance to block input to every other shell in the display. The SYSTEM_MODAL style allows an instance to block input to all shells, including shells belonging to different applications.
The proper thing to do is create the dialog as a modal window. When you create the dialog's shell you should do something like
dialogShell = new Shell(mainShell, PRIMARY_MODAL | DIALOG_TRIM);
We have an application which, as its first UI action, displays a modal JDialog without a parent frame.
public LoginDialog(Frame owner, Config config, Object... params) {
super((Frame)null, true);
It unfortunately has the annoying characteristic that when it appears, although it comes to the front, it does not grab the focus.
So the user, after launching the application by double-clicking on the start menu, has to use the mouse to select the "login" dialog and type in information.
Is there a way to make this JDialog grab the focus when it appears in the front?
I've tried calls to "requestFocus" before, after and via invokeLater "during" the call to setVisible(true) - but none of these seems to have any effect.
How do we make a modal dialog grab the focus?
UPDATE: The issue was the code used to try to present a background "wait window". This window was displayed "behind" the login dialog as a hack so that when the dialog disappeared the user would see the "Please wait" message. As it was the first window created by the application, it got the focus. I am not sure if there would have been a way to make the dialog gain the focus again inside the event dispatch thread with this hack - but I fixed it by un-hacking it and doing things properly.
First, it a little strange that modal dialog is parent-less. The point in modal dialog is that it is displayed on its parent and does not allow to access parent.
So, the first recommendation is to make it non-modal. I believe it will work.
BTW I have just tried to create such dialog and have not problems with focus. Try probably to simplify your code:
JDialog d = new JDialog();
d.setSize(200, 200);
d.setVisible(true);
This works for me and I believe will work for you. Now start changing this simple code towords your real application code. At some point it will stop working and you will see where the problem is.
If nothing helps try to use the trick I described in this article. Look for title "Portable window activation". I hope it will help.
See Dialog Focus for a potential fix using a RequestFocusListener. I have used it successfully for setting focus in JOptionPane dialogs.
1) you have to create JDialog contents and showing container wrapped inside invokeLater()
or best and safiest way is
2) you have to set for ModalityTypes or Modal for parent
3) only one from containers could be Modal in applications lifecycle
I have a JApplet which is used for chat. I would like to make it possible that when the applet is minimised and a chat message is received by the user, the minimised window becomes orange (and thus shows the user that something has occurred).
How is it possible to make the applet do this?
Thanks,
Tim
You may have access to the system tray in an applet (I'm not sure). Have a look at the java.awt.SystemTray class - the in-tray lets you pop up messages to the user.
Alternatively you could attempt to cause the Window's toFront method to be called or to "maximize" using the setSize methods (again, I'm not sure what effect this has in an applet). I suspect that the toFront method will be a good bet
Another option I'd look at is raising a JDialog. The presence of this may cause the OS to draw attention to the minimized applet. You could listen to window events representing the screen un-minimizing to clear the dialog so that the user never knew it was there.