The GUI consists of a JFrame into which I've placed a "Board" panel and an "Interface" panel. The interface panel has a series of sub-panels showing various bits of information, one of which has the input elements -some text boxes, spinners and a button.
The individual GUI elements are all separate objects extending JPanel. However, whereas I can add the textboxes and spinners to the input panel inside its own code, the button has to be added at the same level as the creation of the Jpanel in order for the actionListener to be able to repaint it using an inner class (it needs access to the "frame" variable). This seems clunky and very non-OO - I'd like to be adding the button along with all the other elements in that panel. Is there a better solution?
here I am adding the button to a panel, which I then add to the input panel - all the other elements on the input panel that do not need actionListeners are added when the inputPanel is created - see below
So really it's this block of code above, between this and the provious comment that "feels", from an OO point of view, that it belongs elsewhere.
The clunkiness is compounded by the fact that I've had to add a whole raft of getters for the references to the textboxes and spinners in order to update the values in the actionListener.
And the input panel class
All the variables and getters below were a work around to extract the information to the actionListener level. However, because repaint needs the frame variable, and there doesn't seem a way of having the button on this level where I think it belongs
That's the end of the work around
The question of how the repaint method can be empty can wait for another time!
Simon* [ September 15, 2006: Message edited by: Simon Hunt ]
"I was born in a water moon..."
The Algebraist by Iain M. Banks
Congrats to your first Java App! You are right that it's "not very OO", but that's quite natural for a beginner - mine did look similar when I started with Java.
I think your design issue actually is more fundamental, in at least two dimensions. Basically I think your panel is doing way too much - a good OO design has lots of little classes that collaborate to get the work done.
For example, your panel looks way too big to me. When I look at your buildInput method, I see opportunities for a number of subpanels being extracted into their own classes, taking over responsibilities for updating themselfes to changes in the world around them.
Second, it might be a good idea to introduce a model for the dialog. When the button gets pressed, the listener would just update the appropriate values in the model by directly reading them from the GUI elements. The model could than update other values that are derived from it (i.e. recalculate those). It then could fire an event to all panels listening (or several events, one for each changed value), and the panels could update their GUI elements accordingly.
That way, all the panels and listeners only had to know the model, and woulud update themselfes automagically whenever there is a change in the model. It wouldn't even matter whether change happened due to a user action, a timed event, a change in a database etc. pp.
I hope that gives you a rough idea on how a "more OO" solution to a GUI design could look like. It probably looks a little bit intimidating to you now, but I suggest you just start playing with the ideas until you get familiar with them. Worked for me...
And come back with your questions!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 17, 2006
Just to say (a very belated) thanks for the replies. I'm afraid that my programming only ever happens very sporadically (i.e. out of term time when I get a break from marking), so this is the first time I've looked at it since the summer.
Michael - Am I right in thinking that
Is actually allowing me access to the original "frame" variable? I'll try this out on the next panel class I write. Thanks!
Ilja - I'm now working on a slightly different (but related) app. This one has lots of little panel objects as you suggest. However, my understanding of generating events is too weak currently to implement your
"It then could fire an event to all panels listening (or several events, one for each changed value), and the panels could update their GUI elements accordingly.]"
idea. Are there any sandbox references you could suggest (or even a code snippet if it's reasonably simple)?
I've actually recently gone over to passing the frame variable to the panel objects, which allows all the control code to be in the correct place - each button's listener does it's own little bit, as Ilja suggested, rather than the large ugly listener class you saw last time. This also seems to work fine.
Simon* [ January 07, 2007: Message edited by: Simon Hunt ]