My program consists of 3 main 'sections'. Main function, Login form and App form. The main function should do something like: Open Login form, wait for it to close, then open App form. I can't get the waiting part to work, or rather, I don't know how I would go around doing that.
I was told by someone to use a JDialog instead and use setModal(true), but with that approach the Login form wouldn't appear on the taskbar, which is terrible in my opinion.
Another thing I considered was to open the App from inside the Login after it closes, but that feels like bad design since that'd make the Login form non-reusable.
So, please, what would you suggest?
Why must the login appear on the task bar, since the main app will be there, and you don't want more than one task bar item for an individual program. Your best option may be to use a modal JDialog.
Another option is to use CardLayout to swap "views".
A third option is to use a JFrame if you must but attach a listener to it, a WindowListener I believe, to respond to its close event.
Regardless of which route you go, your login gui should be a JPanel so that you can place it anywhere you wish and then change your mind later.
Related
I'm working on a RMI client server program. And for my client class I want when I start the client to have a window for verification of the password. If the password is wrong a pop-up message will appear, and if it's correct the current window needs to close and another window with options to work with the server should appear. The code for such an action would be something like that:
//Button for checking password - actionListener
if(!checkPass(btnLogin.getPassword())
JOptionPane.showMessageDialog(null,"ALERT MESSAGE",JOptionPane.WARNING_MESSAGE);
else
// do something so this window closes and a new window,
//with say one button for example, pop-ups
How should I do something like that? The current code is just the back-bone of the client with the remote methods and it also inherits from a jFrame which is currently the password checking window. Keep in mind, that I'm trying to keep all the client gui and functionality in one class. Should the two windows be jPanes and how should I deal with them. I'm lost here so any kind of help is welcomed :)
You want to try and separate and isolate responsibility. That is, the login view should do nothing more then gather the credentials from the user an validate those credentials. It should NOT be responsible for moving the user onto the next view, that responsibility belongs to a different part of you application (or controller)
Wrap the login component in a modal JDialog. From your main class, you can show this dialog, it will block until the dialog is closed (calling dispose on the dialog)
Once the dialog has been closed, and the current user verified,you can create your main application window as per normal
This is an example of a MVC based login dialog, while it might seem complicated, it would be a good lesson in separation of responsibility and introduction in to the Model-View-Controller paradigm
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.
I am attempting to learn Java (at this point GUI programming in Swing and as a concept in general) and I have managed to create a basic login page. What I want to do however is to have it change what is displayed somehow to a 'home' page, as it were. I can think of only two ways of doing this, the first being opening a new window and closing the old one and the second being somehow changing the frame the login page is in to whatever I want to display. How is this usually done in real-world applications?
There are a number of ways that it can be done including the two that you mentioned. It really depends on what you are trying to achieve. Something like a login form could be done with a JDialog that pops up over the main window such that you start the main window and the main window simply pops open a JDialog for credentials etc.
Sometimes you create multi document interfaces using JInternalFrame. Where the various windows that you need all appear to be within a bigger main window.
So if you were creating a simple UI then simply switching out the content of the JFrame as you suggested would suffice. You can use an apprpriate LayoutManager to assist such as a CardLayout.
If you have a login frame, a better way is to make it a modal dialog, which is:
1) more user-friendly.
2) making your coding job easier.
In a package in Netbeans I created two JFrame Forms, first one is Login, second is, mainProgram, after the successful log in, I use the following way to "close" the Login frame and open the main program frame.
mainProgram m=new mainProgram();
m.setVisible(true);
setVisible(false); //to hide the log in frame
Is this the correct way? Isn't it wrong if these two separated classes are hidden instead of being closed? are these one process or two different processes? if there's a better way then what is it?
thanks..
Is this the correct way?
Yes, this should be fine.
isn't it wrong if these 2 separated classes are hidden instead of
being closed?
The ideal is dispose of your unused forms (such as the login form when not needed any more)
are these 1 process or 2 different processes?
These will run on the same process
In a package in Netbeans I created 2 JFrame Forms, first one is Login, second is, mainProgram, after the successful log in, I use the following way to "close" the Login frame and open the main program frame.
use CardLayout, after correct login you can to switch the GUI to next Card and/or with change for JFrame Dimmnsion on the screen too,
in my opinion the more correct way is to use another class, like Launcher, which will have the entry point (main method).
Make the login window as a modal JDialog, and set DISPOSE_ON_CLOSE as a value of default close operation. The class of dialog should contain a method to inform a user really logged in. After the login dialog is closed, show the main frame
loginDialog.setVisible(true);
if (loginDialog.isLoggedIn())
mainFrame.setVisible(true);
Try this...
The approach you used to hide and un-hide is fine, but will be better if dispose is used.
Try applying the Singleton pattern on the classes which govern these JFrames.
And yes they both will be on the same Process.
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.