This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Coordinating Toolbar ActionListener with main Gui frame (architecture trouble)

Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am having difficulty with coordinating action listener events in my GUI. This is more of a theory/advice question than asking for help with a specific issue.

The basic hierarchy of the program so far is:
> Main
> class objects of the GUI that extend JFrame (for the different panels)
> main toolbar (another class object of the GUI)

I am trying to wrap my head around event handling with the toolbar. For example, if I used the File/Load JMenuItem in the Toolbar class, how can I manipulate it's action listener so that the data that is summoned from a file by this action finds its way back to the main GUI class to be used. In other words, how will the GUI class know when to retrieve the data from the toolbar class?

My solution to this problem was to use an ActionListener from the GUI class as the action listener for activating the JMenuItem "Load" in the toolbar class. In this way, when the loaded information was called into the program, it would already be in the appropriate class to be utilized by the program.
Please correct me if I am wrong, but this was my own thoughts on how to solve the problem.

However even if this is correct, I have no idea how to make this work. Can someone give me an example? And again, I may be way off base in my method of approaching this solution.

I am attaching a very basic example of my hierarchy in case some people didn't understand it above.

Posts: 65062
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you have mentioned a much more fundamental problem. Your hierarchy should be something like data-processing-interface-GUI components-listeners-buttons. That is a long-winded way of describing the MVC kind of architecture. You don’t want to create GUI code unless you have a solid logic underlying it. When the interface passes data back and forth reliably, then you can put a GUI on top of it.
A lot of books have the GUI components implement the listener interfaces, and you end up with what I think is non‑oriented‑ code full of ifs, but I think that approach is mistaken. I appear to have written about Listeners often. At least that is what it says here. That may give you a hint about how to add a listener to your buttons. (Remember a menu item is a button; have a look at its inheritance hierarchy.)
Chris Hericks
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have read through your response several times, and I am having a hard time figuring out how it answers the question that I originally asked. In essence, I am having difficulty sending information back up my hierarchy tree.

My Tree:
Main > GUI > Toolbar & JPanels
User data is on its own.

Toolbar is where the user is calling the data from, but it needs to move that data back up the tree to GUI to be implemented.

Your hierarchy should be something like data-processing-interface-GUI components-listeners-buttons

This is more or less what I have. But the same issue is implied here. The button, or object that is calling the information, needs to pass that information all the way back up the tree to data/processing, and that is what I am struggling with.

As I mentioned before, I believe the answer to my problem is having the actionListener for the calling object a the bottom of the tree point to an actionPerformed near the top of the tree. I am already well aware of anonymous inner classes as ActionListeners, and use them often, but I still fail to see how I can use them to get the information they are accessing to the correct level of the hierarchy.

I just had a thought. Could I call a static method (written in the GUI class) from the actionPerformed method at the JMenu level to get the information where it needs to go?. I am largely self taught, and I trained myself long ago to try and avoid static methods out of instinct, so this may be a poor idea like my gut is already telling me.

Second Edit:
Another thought, could I make my GUI component classes subclasses of the core GUI? That way they would each share the actionPerformed() method housed in the superclass, and could affect it in that manner. Yes? No?
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!