First, let it be known that I'm new to java and it's quirks. I'm a seasoned programmer with various languages, which may be why I'm stuck...
I have an application that, possibly due to poor design, spawns new JFrames through the users' work-flow. My question is, if there is an event in a spawned JFrame, is it able to contact and pass data or an event to it's parent?
I have read that using a JDialog seems to be the way to design, but let's assume that's not an option. Essentially, JFrame1 contains a JTable with a list of data. An action spawns JFrame2 and a user "does something" that impacts the data in the list in JFrame1. Upon closing JFrame2, is there a way to control the JTable based on JFrame2's close event?
It's a pretty basic concept, I just can't seem to find the mechanism that would allow such an action.
Thanks!
You can use "listeners" to listen for various events.
It sounds like you might want to start with How to Write a Window Listener.
I have read that using a JDialog seems to be the way to design, but let's assume that's not an option.
Why? The code is the same and JDialogs where designed for this purpose. What is the specific requirement that says you need to use a JFrame?
An action spawns JFrame2 and a user "does something" that impacts the data in the list in JFrame1. Upon closing JFrame2, is there a way to control the JTable based on JFrame2's close event?
This is a common design. The user selects a row to change or update and a model dialog is created to display all the data so it can be changed. When the dialog is saved the data in the table is updated. If this is your requirement, then you can just pass in the TableModel to the dialog. Then when the dialog is closed you update the TableModel and the table will be repainted automatically.
You would have to capture the window closing event using a window listener. The window listener would also need a reference to the data that needs to be changed.
In addition to using Window.addWindowListener() on either a JFrame or a JDialog, consider using a model-view approach. Have the close event modify the table's data, rather than the table itself. Use AbstractTableModel as the model for the table, and listen for changes to the data.
Related
Okay so I'm making a Library admin program and I have created a special frame where the user would enter details about a new book. However my method for adding a new book is in a separate class (methods). My question is how can I get the information the user enters in the text fields? Do I have to use something like getters, or is there an easier way. Also keep in mind that I am using the GUI layout (thing) in netbeans, and that I have already actually made the form. (I know it's frowned upon but I'm pressed for time and this is how we were taught.) This is a school project by the way. Thanks.
Okay so I'm making a Library admin program and I have created a special frame where the user would enter details about a new book.
Usually, a detail window should be a dialog, and likely a modal dialog. I suggest that you display this information in a modal JDialog, not a JFrame. Do this and it will make extracting information from the detail window much easier.
However my method for adding a new book is in a separate class (methods). My question is how can I get the information the user enters in the text fields? Do I have to use something like getters, or is there an easier way.
This begs the question -- what's so hard about using getters? And in fact his is exactly what I suggest that you use! Please note that your question essentially boils down to, "how can I get information on the state of one class's object from within another class's object", and for this getter methods are almost mandatory.
Also keep in mind that I am using the GUI layout (thing) in netbeans, and that I have already actually made the form. (I know it's frowned upon but I'm pressed for time and this is how we were taught.) This is a school project by the way.
This is unrelated to your current problem and should have little effect on its solution other than if you've hard-coded your "form" as a JFrame, then scrap it and re-do it as a JPanel.
I suggest:
Create an addEditBook modal JDialog
Give it getter methods to allow outside classes to be able to query its textfields for their contents.
Display the dialog from the main program.
Since it is modal the main program's code flow will pause until the dialog has been dealt with.
In your OK and Cancel button, set the dialog's state (OK_STATE or CANCEL_STATE) and close the dialog. The easiest way to do this actually is to use a JOptionPane as your modal dialog since it has mechanism for just this sort of thing. This is easily accomplished if your addEditBook is geared to create a JPanel, one that you display in the JOptionPane.
Program flow will then resume in your main program from right after where you showed the dialog
query the dialog for the contents of its fields.
For examples of the JOptionPane solutions, including option panes that request information from multiple fields similar to your window above, please see:
How can I make a JFrame modal like a JOptionPane?
Multiple input in JOptionPane.showInputDialog
Edit
You state in comment:
Oh and I was wondering how can I make the field of a normal JOptionpane input dialogue come up with a word already in it like for editing it will show the information stored already?
Please see the example answers that I have listed above as you'll see that they're not examples of a "normal JOptionPane" but rather JOptionPanes that display a GUI that you create. And just the same as it's easy to query the state of this GUI after it is displayed, it's just as easy to set the state of the GUI via setter methods before it is displayed.
My question is how can I get the information the user enters in the
text fields? Do I have to use something like getters, or is there an
easier way
You need to add actionListeners for you buttons, which means you will be overriding a method called actionPerformed. You basically need to associate your actionListeners with your 'Ok' and 'Cancel' buttons. When the 'ok' button is pressed, you should get a callback in the associated actionPerformed method. Then you should try to fetch the values of your textfiled using the getText method. Collect all the fileds and set the bean you have created to store that data. Then you can call your business logic to save/modify the books info.
I have 5 JFrames in my application and I want the values from all 5 JFrames to be sent to a single JFrame. And it is a process where I have to go one frame to another and the value entered previously should not be lost and must be visible at the end of the process.
Easy example is,
I key in my name in the first frame,
then I key in my Address in the second frame,
then my mobile number in the third frame
and so on till the last frame where I want my keyed in details in the previous forms to be in the final frame to display my data in JTextfields. Is this possible? Because if it is a single form, I know how to do it. But when it is multiple forms in this situation I am lost. Please help.
This has nothing to do with Swing or JFrames and all to do with the general issue of getting information from one object into another. Yes it's possible -- give the classes that you wish to extract information from "getter" methods, and then call them when you want the information. If you want to gather this information in an event-dependent fashion, then you will need to have one class listening for state changes brought on by events in the other classes. A PropertyChangeListener can work well for this.
Or if you use modal JDialog windows instead of JFrames, you will always be notified when the dialog has returned and is no longer visible, since the calling code's program flow resumes from right after where it told the dialog to become visible.
Next we can discuss whether having 5 separate JFrames is a good idea or not. I'm guessing you know my opinion on this, else I wouldn't have mentioned the subject.
I'm looking to build out a Java GUI with a table area and an area that will display the data of a selected row of the table. I've never tried a multi-frame set up before so before I venture to do this I wanted to check with others. Is it difficult to have two frames and have them passing data back and forth? The idea would be that I could move the details frame anywhere I like on the screen or to a second monitor and allow the table to go full-screen if the user wants. Any input or examples are appreciated.
don't to create two of more JFrames use JDialog instead,
reuse this JDialog for another action(s)
create one JFrame and one JDialog for displaying details
have to determine if and which of JTables row(s) is selected
better would be to set ListSelectionMode to the SingleSelection
maybe would be better to invoke (show that already exist) JDialog from JPopupMenu Action
You should have no problem in doing what you are after. You can have public methods in each frame which expose properties and/or structures and you then pass the instance of one JFrame to the other. This should allow you to pass data back and forth.
That being said however, I think that this scenario is valid only when you have one, two, or at most three JFrames. Having a lot of frames calling each other could result a maintenance nightmare.
there are several possibilities to do so:
you can add one of the jframes as a listener to anothe, or both to each other. For this, you have to implement a listener mechanism, like in java.awt. You can pass the information contained in the event objects - this would be the most clean alternative
you can pass the instance of the detailframe directly in the constructor of the main frame and call operations from main frame on detail frame. this is the simplest way, but you will need lot of code changes if you have some new features to add
I have a JComboBox whose values are retrieved across the net.
I'm looking for a way to indicate that fact to the user, when the user wants to see the list, expands the drop down, and only then the data is being retrieved.
The basic requirements include:
JComboBox's drop-down shouldn't lock the EDT, but the combo's action should not work until there are values.
User should know when all data has been retrieved.
The size (UI real-estate) of the indication should be as small as possible.
Note that the data isn't retrieved until the user wants to see the combo's values (i.e. expands the drop-down list).
The solution i've used:
I've used a SwingWorker to keep the UI responsive. The combo box was overlayed using JIDE's Overlayable with JIDE's InfiniteProgressPanel that listens to the worker.
To avoid locking the EDT, your data retrieval should be done in a background thread. I would use a SwingWorker to find and load the values since this makes available a background thread with other goodies that make it very Swing-friendly. I would make the JComboBox enabled property false until all values have been loaded, and then enable it via setEnabled(true). You will know the SwingWorker is done either through its done() method (by overriding it), or by adding a PropertyChangeListener to the SwingWorker and being notified when its state is SwingWorker.StateValue.DONE.
One way for the user to know that the process is complete is that they will see when the combo box has been re-enabled. If you want a more obvious indicator, you could display a JProgressBar or a ProgressMonitor. This could be displayed in a dialog if you wish to leave the GUI appearance mostly unchanged.
I implemented it by adding "Loading..." item and a special border around the JComboBox. On click separate thread is started adding new items via SwingUtilities.invokeAndWait. When loading is completed the "Loading..." last item is removed.
to not force my users to wait until the data is loaded, combine the answers by eel and stan :-)
start off with the model containing zero or one real value plus the dummy entry "loading"
register a PopupMenuListener and start a SwingWorker loading the data (into a separate datastructure, might be a new model) in its very first menuWillBecomeVisible
while loading, select the dummy entry (and/or whatever else is appropriate to inform the user what's happening), the action has to be aware of "nothing-to-do-yet" as well
listen to the worker, when receiving the DONE replace/fill the data into the combo's model
I'm building my first Swing app and am trying to figure out how my JDialogs - exclusively invoked when the user selects a JMenuItem - can update the components in the main client area of the JFrame which is the parent "window" of the whole app.
This is the design I've come up with, but don't know if its: (1) just plain bad, (2) not the standard (thus best) way, or (3) if I'm totally off-base here. Any suggestions are enormously appreciated.
Basically, the user selects a JMenuItem, which launches a JDialog. The user interacts with the components on the dialog, and then clicks "Done". If everything validates, the JDialog closes, and I want the parent window (a JFrame) to have its state updated (and eventually rippled out into its components).
My design:
Have an AppStateController that is a member of the JFrame subclass (my application). I would then create an AppStateChangeListener and AppStateChange EventObject subclass so that whenever a dialog validates and closes, it fires an AppStateChange event. Since the parent JFrame is the only registered listener to that event, I could define a handler that gets the event passed to it. I would make sure the AppStateChangeEvent had enough metadata to describe all the possible changes.
In theory, I like this approach: it should be clean and free of "spaghetti"-type calls to multiple controls every time a different event fires. However, I fear it may be overkill.
What do best practices dictate here? I'm not really a GUI person!
Java has several ways to implement the observer pattern; several are discussed here.
The mechanism prescribed by EventListenerList is probably the most general, as it would allow you to define your own event and listener types, and it is familiar to Swing programmers. Instead of making the JFrame a listener, let the highest level JComponent do so. Each instance of JComponent has a suitable protected member, listenerList.
Bound Properties are also an excellent choice, as shown here.
If you go with Observable, you'll need to use a delegate.
Addendum: As concrete examples, jfreechart uses the EventListenerList scheme to manage chart, dataset and series events. In contrast, jcalendar uses bean properties to notify listeners of widget selections.