I'm new to Swing [used SWT before] and I wonder how should I design two windows communicating with each other.
I have my mainframe window, which is a JFrame. I want it to open a new frame, and I want that new frame to affect the mainframe, for that I need access to the mainframe variables and stuff. I have few design ideas in mind, I'm not sure which is better - 1]I could put the other form in the same package, and make the variables package friendly. 2]I could make the other frame as an inner class. 3]I could make getters/setters methods for the mainframe.
Now, how is this done usually? I don't like the first option, seems messy to me. Package friendly is something I don't like.
I tried using the second approach, I have several problems with that though, for example this.dispose() closes both frames for me.
And the third option, well, it looks weird to me having getters /setters for a GUIclass...tomorrow I could use the same GUI code, just instead of having AddressBook data structure inside the class, I'll make some different logic one.
Anywayyy - how stuff is done in the real world? Am I missing an option or getting some wrong?
Any thoughts will be appreciated. Thanks in advance. [ October 16, 2008: Message edited by: Patrick Brahami ]
Ever thought of using a JDesktopPane as a Main Frame and using JInternalFrames for whatever you intend to do with your two separate Windows. Given that all three be members of, say, a class Main extends Object or whatever you intend to extend ... this approach seems pretty object-oriented to me, but maybe there's better ways to do what you want to do.
Hope this helps ...
The man who sets out to carry a cat by its tail learns something that will always be useful and which never will grow dim or doubtful.
-- Mark Twain
My answer to your question is to forget about Swing, forget about GUI. How would you have two objects of different classes communicate with each other regardless of whether these are GUI objects or not? Would you break encapsulation and have one object directly mess with the instance variables of the other? Or would you use solid OOP principles and have the objects communicate in an OOP-compliant manner? The latter can include getters and setters, public methods, and often design patterns such as the command pattern or the observer pattern. To me the answer here is obvious. [ October 18, 2008: Message edited by: pete stein ]
Joined: Oct 12, 2008
I see what you say Pete, this is how I usually prefer to communicate objects. It's just that working with this GUI kinda messed up my way of thinking.
Because like the newFrame class has no existence purposes without my mainFrame. It totally dependent on it, and designed especially for it. So it makes sense it will be an inner class.
BUT, again I don't like it messing with the variables of the mainFrame as if it were their own + it leads to some technical problems.
Joined: Feb 23, 2007
I'd say that if the NewFrame class is a trivial class, kind of like a simple ActionListener or a "gimme" when putting in golf, sure make it an inner class. If not, if it's moderately to fairly complex, then you are likely to be better off making it a stand-alone class.
As an aside, I rarely have classes that extend JFrame or even JPanel for that matter. Most of the time I'm not overriding methods of these classes, and I find it safer to use composition and not inheritance. I also avoid coding to the JFrame but rather to the JPanel as this gives me much more flexibility. If I want to use the panel in a JOptionPane or a JDialog, its a trivial matter.
Joined: Oct 12, 2008
To tell you the truth, I'm new to Swing and I don't know much about this library. I have more experience with SWT, developed with it without GUIBuilder, so I had to understand the classes well.
The application I'm creating had quite alot of logic coding, so I thought I should try the NetBeans GUIBuilder, because heard alot about it. Problem is I didn't read beforehand much about the different classes.
Anyway long message for a simple question : Where is there a tutorial explaining the difference between the classes of swing and their purpose? (not coding examples like in the java tutorials)
Thanks in advance. [ October 19, 2008: Message edited by: Patrick Brahami ]
Also, as a simple example of what I was describing previously, say I have 2 classes that produce JPanels:
1) PanelCommReceiver class simply holds a non-editable JTextField that can be changed by calling the object's setText(String text) method. 2) PanelCommSender class has a JTextField whose text can be retrieved by calling the object's getText() method. It also has a JButton and outside classes can add an ActionListener to this button via the class's addActionListener method.
Both classes do not subclass JPanel but both hold a JPanel called "mainPanel" that can be retreived for displayal calling the getMainComponent() method of either class (if I were to do this seriously, I'd probably incorporate this idea into an interface).
Finally there's a third class called PanelCommControl that creates a JFrame and places the receiver class object's JPanel into it. The control also creates a JDialog and places the sender class object's JPanel into this. The control finally connects everything together so that pressing the sender's jbutton will send the sender's text into the receiver. It's not a particularily exciting program, but it does (I hope) illustrate the point.
Here are the classes and I hope this helps a little bit: