what is the best way to have JFrames, JDialogs, etc that derive from a common parent but differ some, to be able to have the common parts update automatically when the parent does, but also have new components which are still easily modified in a GUI builder.
One approach I have used before is having placeholder JPanels that populate with existing isolated components at runtime, but I suspect that this is not the best way.
Example frame visual inheritence:
Don't use a GUIBuilder unless you creating some sort of prototype or other throw away code.
Have the components that need to update automatically setup as listeners for some sort of change event. Once an update is needed fire of an "Event" to each listener.
Related
Right now, when I have a form with many JComponents, mainly JTextFields, JTextAreas, JComboboxes, JCheckBoxes and JButtons and want to control their behaviour, for instance the change of focus after a certain key was released, I do the following:
I put all my components in a JComponent[] and cycle through it, adding the appropriate listener. When an event is registered by said listener, I check with "instanceof" what kind of JComponent fired the event and assign the proper reaction.
I use this method for instance to cycle with VK_ENTER through the form, or to "firePropertyChange(..)" after a DocumentListener fires, or to add UndoRedoListeners and so on.
My question : is there a better way to do this and if yes, can you explain to me the benefits ?
but my question refers to the general practice of putting all
JComponents in an array and cycling through them for every listener
and every fired event. It works fine enough, but it feels a bit
"uneconomic",so I wanted to know if it is recommended practice, or if
there is a better way of doing it.
I usually write a custom listener (often as an anonymous class) per type/ instance if I have type/ instance specific behavior so that I can avoid instanceof and other other checks.
You'll want to customise the focus tranfersal system.
Take a look at How to Use the Focus Subsystem, in particular Customizing Focus Traversal
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 GUI with nested panels(tabbed with nested panels and etc). I need to pass domain object to deeply nested panel. I can think of two ways:
Instantiate all gui objects in one place, like frame class. That
would make passing domain objects dead simple, but Frame class will
be huge and hardly maintanable.
Each panel has its own class, where we instantiate and layout its
components. Now its easy to maintain and classes are clean, but how
do I pass down the chain my domain objects? I dont want to chain-pass
them through constructors of panels that shouldn't even know their
existance. And top level panels would have a ton of these objects to
start with.
Niether way seems like a soulution. How do you usually aproach this?
When I put together a Java Swing GUI, I have a data model for each major GUI element. Note that this isn't an MVC pattern. This is more like a local MV pattern. If you want, you can consider GUI element listeners as the "controller".
Each panel has its own class, where we instantiate and layout its
components. Now its easy to maintain and classes are clean, but how
do I pass down the chain my domain objects?
You have the right idea, although you shouldn't have to do much passing.
My JFrame (or JApplet) will have an associated model class of global type fields. An instance of this model class will usually be passed along to the children elements. This is to allow children elements to react properly when a menu option is selected (as an example)
My JPanel(s) will have an associated model class that maintains the state of text or button children elements.
More complicated children elements, like a JList or a JTree, already have an associated data model. I will probably wrap these associated data models into the JPanel model class for convenience.
The children elements will trigger some sort of selection or action listener. Some of these listeners might need access to model classes besides the model class associated with the parent. In this case, you're going to have to pass the instances of your model classes to the listeners.
This is sort of a Chain of Responsibility pattern. What I would do is have something that creates a map with all of your display objects in it and pass it from constructor to constructor. That way every instance can take what it needs from the map without caring what else is there.
I have used the Eclipse plugin Visual Editor to construct Java Swing interfaces. As I'm not a big fan of the code WYSIWYG (UI) editors generate, I wanted to optimize it, when I noticed, that the editor implemented all elements using lazy loading like this:
private JPanel getSomePanel ()
{
if ( somePanel == null )
{
somePanel = new JPanel();
// construct the panel
}
return somePanel;
}
I know that lazy loading is used to get better performance, when the objects in question are not used immediately. However for most user interfaces this makes less sense, as a window for example should usually show all components on it right from the beginning. This is also the case in my situation where I have a rather simple clear layout, where all components are expected to exist when the window is displayed.
Visual Editor added an initialize call in the root container's constructor in which the root panel is constructed and all the other elements are added (via lazy loading). So actually all components are created right when the root container is constructed, just nested into multiple methods.
Is there actually any use for lazy loading in this case? In which UI cases should I use lazy loading? And when using lazy loading, am I actually even allowed to access the member variables directly - or should I call the getter each time?
Thanks!
When you use lazy loading, you should always use the getter each time you access the member variables. This is a fundamental part of lazy loading.
However, in this case you described, there is no reason to use lazy loading. I have to wonder if the author of Visual Editor didn't just have some thing for lazy loading where he felt it always needed to be used, or just decided that he wanted to use it in the tool for some arbitrary reason.
You are exactly right about UI's where components are generally all loaded when the panel is constructed because they're all visible. There are some cases where parts of a panel may appear and disappear based on other choices on the panel, and it's conceivable that you could use lazy loading in these cases. My point of view, however, is that people are likely to click around an interface anyways and use all the different tabs and options, so you might as well load everything to begin with.
Obviously, there's something different going on when you're talking about loading data. If you have a drop-down that's hidden when the panel comes up and has a lot of information if loaded, you may want to not load the drop-down until it becomes visible. I still see no reason not to instantiate the drop-down right away, though, even though it's hidden.
I would not consider lazy loading to be the norm behavior for a panel at all. I could not offer a reason why Visual Editor chose to generate code in this manner.
I'm not a big fan of the code WYSIWYG
(UI) editors generate
Me either.
Is there actually any use for lazy
loading in this case?
I don't think so, the creation of the component takes no time so all components should be visible when the GUI is displayed.
To me the bigger concern is the data. If your data for components like combo boxes and tables comes from a database you may not want to load it all up front.
I know I can specify one for each form, or for the root form and then it'll cascade through to all of the children forms, but I'd like to have a way of overriding the default Java Coffee Cup for all forms even those I might forget.
Any suggestions?
You can make the root form (by which I assume you mean JFrame) be your own subclass of JFrame, and put standard functionality in its constructor, such as:
this.setIconImage(STANDARD_ICON);
You can bundle other standard stuff in here too, such as memorizing the frame's window metrics as a user preference, managing splash panes, etc.
Any new frames spawned by this one would also be instances of this JFrame subclass. The only thing you have to remember is to instantiate your subclass, instead of JFrame. I don't think there's any substitute for remembering to do this, but at least now it's a matter of remembering a subclass instead of a setIconImage call (among possibly other features).
There is another way, but its more of a "hack" then a real fix....
If you are distributing the JRE with your Application, you could replace the coffee cup icon resource in the java exe/dll/rt.jar wherever that is with your own icon. It might not be very legit, but it is a possibility...
Also, if you have one "main" window, and set its icon properly, as long as you use that main window as the "parent" for any Dialog classes, they will inherit the icon. Any new Frames need to have the icon set on them, though.
as Paul/Andreas said, subclassing JFrame is going to be your best bet.
Extend the JDialog class (for example name it MyDialog) and set the icon in constructor. Then all dialogs should extend your implementation (MyDialog).