I have a button that open a new window to the user do some configurations. After the configuration window is closed, I want to reload the configurations in the window that called the configuration window.
How I do this?
Use a modal dialog for your configuration window. Then when the dialog is closed execution of the code will continue after your statement that displayed the configuration window so you can reload the properties.
As long as the form isn't freed on close you can still access the variable representing the form and get its properties and control values.
EDIT:
Ok, I'm a little confused, but let's try this again. There are MANY ways in which you can solve this problem.
The easiest way is to simply call the configuration form with ShowModal and then process the configuration information within the button's click event once the form is closed.
Another way is to have the configuration form store its values in an allocated object (a TStringList, for instance) and then send the reference to that object via a message to the main form in the OnClose of the configuration form. Your main form would then use the TStringList to get all the configuration information and then free it. Again, this is only one way of many this can be done.
So much depends on how you want this all to work.
You need to implement a WindowListener. See how to write Window Listeners.
WindowAdapter myListener = new WindowAdapter() {
// maybe you want windowClosing
public void windowClosed(WindowEvent e) {
// actions to perform after window is closed
}
}
// add to a Window (JFrame is a subclass of Window)
myWindow.addWindowListener(this);
Related
I want to save information from last window (there is possible to use a couple of window in my program) before closing java fx app.
I tried to do this in stop() method, but it saves first opened window.
using Platform.exit() stops whole app after closing randow window.
I tried to do some special main window and let user save chosen window by using extra button, but it's not the prettiest solution.
How can I save last used window? Is there any event handler which is gonna solve my problem?
Yes there is, a few ways you could try...
1) Inside of your Application class, in the Application#launch method, specify the onCloseRequest event
yourStage.setOnCloseRequest(event -> {
//Do Your on close events here
});
2) Inside of your Application class, override the Application#stop method
#Override
public void stop(){
//Do Your on close events here
}
And alternatively, you can specify a system shutdown hook for when the jvm exits, which you can do like so
Runtime.getRuntime().addShutdownHook(() -> whatToDoOnExit());
My JavaFX 8 application has to doStuff() when it gets focused. That's pretty simple:
primaryStage.focusedProperty().addListener((observable, wasFocused, nowFocused) -> {
doStuff();
});
However, when I display a dialog and user closes it, doStuff() fires. I want it to fire only when user switches from another app to mine, for example Alt+Tab from a browser.
In other words, I want to doStuff() iff other app's window loses focus and my app's window gets focus.
Is it possible?
Edit: Answers posted by FibreFoX and Appelemac require explicitly performing additional step before showing a dialog. This solution is far from perfect, because I (or any developer, in general) have to remember about this step before showing a dialog. Forgetting about it will introduce hard to find bugs.
Extending Dialog to do it automatically isn't an option, because I want to use built-in dialogs that already extend original Dialog.
That's pretty basic feature, I'd be surprised if there's no easy way to achieve this in JavaFX.
You could use a global boolean when opening such dialogs, and only when that global switch is true/false/whatever-you-choose then you could react on that state-switch.
public class GlobalDialogMemory{
public static boolean dialogShown = false;
}
When using CDI you could inject the application-scoped current instance (but you should use getter/setter and non-static booleans instead ;)
I'd suggest adding a listener to your Dialog, which then allows you to not doStuff() if the Dialog was just closed/lost focus.
Easiest way I can think of is setting an Instant (with Instant.now) when the dialog is closed, and if the application regains focus, create another Instant, and check whether the Duration.between(instantLostFocusDialog, instantGainedFocusApp).getSeconds() exceeds 1 (or add getNano() to that to be more specific). Only then would you doStuff()
I have three classes I am working with here. The first is an admin page where the user can select to either add, update or delete an employee on the system via a drop down box. When the user selects one of the three options from the combo box, a JFrame (employees) comes up with the necessary fields to perform their task and the admin frame will still be displayed behind it. On this frame there is a "Cancel" button. When they click the cancel button only this frame must close but keep the admin frame open still. The button is generated from a separate class (empClass) to be displayed on the employee frame. My problem now is I am struggling to get the button to dispose of the employee frame, but out of the several ways of trying this it cannot work. One way produced an error each time I ran the application, another method caused the application to crash/freeze whenever I try select an option to perform on the employee frame and the code I have currently implemented performs no action at all. I think the problem is a an issue with communicating with the forms but I am not entirely sure. Please help as I have been struggling with this for hours and the internet is providing absolutely nothing useful. Most resources refer to the dispose() method which I have tried in various ways but all the ways I have tried do not work, crash the application or cause errors to occur. Even the other questions similar to this on here have not helped me out at all.
I have tried calling the button from the employee frame to try and link the function to the "Cancel" button. Here is the code I have implemented in the empClass:
public void disposeof()
{
employees empp = new employees();
empp.dispose();
}
private void cancelActionPerformed(java.awt.event.ActionEvent evt)
{
disposeof();
}
Here is the employee coding:
public class employees extends javax.swing.JFrame {
empClass ec = new empClass();
adminPage ap = new adminPage();
public employees() {
initComponents();
getContentPane().add(ec.getpanel());
this.add(ec.getpanel());
this.add(ec.lbltitle);
this.add(ec.cancel);
this.add(ec.bfunction);
this.add(ec.empList);
}
As you didn't provide the code of your JFrame so I guess problem is in the code of your JFrame. You might be setting setDefaultCloseOperation(JFrame .EXIT_ON_CLOSE) for your employee class as it is static property so it will close all JFrames. You should set it setDefaultCloseOperation(employees.DISPOSE_ON_CLOSE) OR setDefaultCloseOperation(employees.HIDE_ON_CLOSE). And after that while triggering your event you can call empp.dispose(); OR setVisible(flase).
First of all only use one JFrame and use JDialogs for the underlying other windows you may want to see appearing. On JDialog, use setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE).
Another way you can do this is to hide the frame using setVisible(false).
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.
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.