which class to implement/extend to add actionListener to a component
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 12 of 12

Thread: which class to implement/extend to add actionListener to a component

  1. #1
    Join Date
    Jan 2003
    Posts
    155

    which class to implement/extend to add actionListener to a component

    Hello,

    I have a class A, and would like to use it inside a class B. I was wondering which interfaces or classes I should implement or extend on A, so that inside of class B, I can add an A as an actionListener to B.

    Code:
    final class B implements ActionListener{
        private A element;
    
        B(){
            element = new A();
            element.addActionListener( this );
    
    
        public void actionPerformed( ActionEvent e ){
        }
    
    }
    
    final class A extends ???, implements ???{
    }
    Thanks again!
    You guys are the best.
    Last edited by Saeven; June 16th, 2004 at 03:42 PM.

  2. #2
    Join Date
    Mar 2004
    Posts
    14
    I don't think I would use implements unless you are comparing or something like that. If you want B to be a super class of A then you use extends. Remember to use a super() call in your constructor or your compiler won't like you.

    HTH

    M2k

  3. #3
    Join Date
    Jan 2003
    Posts
    155
    Sup m2k, I'm not sure what you're talking about hehe, has nothing to do with the question.. erm thanks though hehe.

    Anyone know how to do the above?

  4. #4
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104

    Re: which class to implement/extend to add actionListener to a component

    >I have a class A, and would like to use it inside a class B.

    So pass the instance of A that you would like to use, into class B


    >I was wondering which interfaces or classes I should implement or extend on A, so that inside of class B, I can add an A as an actionListener to B.

    are you doing this for GUI reasons? or are you merely wishing to pass messages from B to A (or vice versa.. its actually hard to make any sort of proper english sense out of your question) then you can either use the Observer/able architecture or the JMS (java messaging services)
    JMS concept is quite simple; a class may be a producer and/or a consumer.. prducers produce messages that are posted to the message queues of relevant consumers. consumers deal with them in their own time..
    "it's a fax from your dog, Mr Dansworth. It looks like your cat" - Gary Larson...DW1: Data Walkthroughs 1.1...DW2: Data Walkthroughs 2.0...DDS: The DataSet Designer Surface...ANO: ADO.NET2 Orientation...DAN: Deeper ADO.NET...DNU...PQ

  5. #5
    Join Date
    Jan 2003
    Posts
    155
    Good insight.

    This is precisely because of GUI reasons, I have an inner panel that is pretty busy, but I would like certain messages to escape to its parent panel in which it is contained. A contains B, and A should act when certain things occur in B. I had the e.getSource() == "panel B" in mind.

    Which would be more lightweight of the two approaches you describe?

  6. #6
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    the Observervation architecture may not be totally suitable for your current skeleton, because a class must "extends Observable" in order to support being watched. The class that does the watching "implements Observer". Currently, you propose that panel A watches panel B. However, because to be a panel, B must extends JPanel, it cannot also extend Observable.

    Java does not allow MI, but this is not a flaw in the inheritance structure of java. To be honest, you should re-assess your skeleton structure at the moment; Panels are dumb view components only; something more intelligent is creating the messages that B displays; it should not be down to B to choose which are to be bubbled to A, because both A and B are too dumb to be allowed to do this.

    you may wish to consider that the message source is the only object entitled to classify the importance of the message
    hence, a proposal for your structure is:

    A and B are "extends JPanel" and also "implements Observer" - they are now capable of watching the messages that MessageSource generates. MessageSource should "extends Observable". Now, both A and B can watch the messages. The message source can provide some meta-information about the message including its importance, and A or B can select which messages to view. How intelligent you make A and B after this is up to you.

    If panel B is the source of messages and the source cannot be uncoupled from this, perhaps because they are mmouse-over-panel-b events, then you should create a small class that extends Observable, call it BEmitter and make B aware of it.. B can then relay messages to it, and it will announce them to any interested observers. the observers may then choose whether or not to act upon the messages. The panelB should be a subclass of JPanel, to become the scenario where 'panel b extends jpanel, has-a message emitter' (rather than IS-A message emitter)
    "it's a fax from your dog, Mr Dansworth. It looks like your cat" - Gary Larson...DW1: Data Walkthroughs 1.1...DW2: Data Walkthroughs 2.0...DDS: The DataSet Designer Surface...ANO: ADO.NET2 Orientation...DAN: Deeper ADO.NET...DNU...PQ

  7. #7
    dlorde is offline Elite Member Power Poster
    Join Date
    Aug 1999
    Location
    UK
    Posts
    10,163
    You're already adding B as an ActionListener to A, and you want to add A as an ActionListener to B?

    Sounds horribly confused, but if you want to do it, just make A implement ActionListener as well - then they can listen to each other... where's the problem?

    Reciprocity in ActionListeners can lead to infinite recursion...
    Please use [CODE]...your code here...[/CODE] tags when posting code. If you get an error, please post the full error message and stack trace, if present.

  8. #8
    Join Date
    Jan 2003
    Posts
    155
    Nono, they are not listening to each other. cjord had the right idea. Much like you would do:

    Code:
    final class A implements ActionListener{
       JButton button;
       B           element;
       
    
       A(){
           button = new JButton( "a button" );
           button.addActionListener( this );
           element = new B();
           element.addActionListener( this );
       }
    
       public void actionPerformed( ActionEvent e ){
           if( e.getSource() == button )
               System.out.println( "button pressed" );
           else if( e.getSource() == element )
               System.out.println( "element did something" );
       }
    }
    
    final class B ??? {
       B(){
       }
    }
    Where the ??? was my question - what can I implement or extend in order to let a custom class, have that action trigger that allows it to dispatch messages to actionListeners.

    Cheers.
    A

  9. #9
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    when you get to this level of complication (which is rarely warranted in a GUI sense) you do NOT want to make GUI classes listen to themselves (i.e., do not use addActionListener(this) )

    instead you should decide what GUI function A and B are to have, and make them have that ONLY
    of messaging purposes, you should then make 2 SEPARATE classes that implement ActionListener

    these separate classes then have the freedom to be more sophisticated than the dumb gui components they listen to.. remember that this is OO programming, and shoving everything into one class is seldom desirable
    "it's a fax from your dog, Mr Dansworth. It looks like your cat" - Gary Larson...DW1: Data Walkthroughs 1.1...DW2: Data Walkthroughs 2.0...DDS: The DataSet Designer Surface...ANO: ADO.NET2 Orientation...DAN: Deeper ADO.NET...DNU...PQ

  10. #10
    dlorde is offline Elite Member Power Poster
    Join Date
    Aug 1999
    Location
    UK
    Posts
    10,163
    You've lost me now - you originally had:
    Code:
    final class B implements ActionListener {
    private A element;
    
        B(){
            element = new A();
            element.addActionListener( this );
        }
        ...
    So B is an ActionListener. In B's constructor you create an A that B registers with as an action listener. So B is listening to actions from A - yes?

    Then you said: "I was wondering which interfaces or classes I should implement or extend on A, so that inside of class B, I can add an A as an actionListener to B.". So now you want A to listen to actions from B, e.g:
    Code:
    // add A as an action listener to B (B is 'this', A is 'element')
    this.addActionListener(element);
    Now B is listening to A (see top), and A is listening to B (see above)...

    Now you say "Nono, they are not listening to each other", and you post a piece of code that reverses the roles of A and B in the original... what am I supposed to make of that?

    Maybe if you gave the classes sensible names and explained clearly what they were trying to achieve, there would be less confusion.

    The first step towards wisdom is calling things by their right names...
    Chinese proverb
    Please use [CODE]...your code here...[/CODE] tags when posting code. If you get an error, please post the full error message and stack trace, if present.

  11. #11
    Join Date
    Mar 2002
    Location
    NY, USA
    Posts
    12,097
    I believe that "A" and "B" have been transposed multiple times in this thread.....

    That being said, I would not necessarily use actionListener for the communication at all. If the "inner" object will always be contained within an instance of the "outter" object, then a reference to the outter cobject should [IMHO] be passed as part of the constructor to the inner object. Actions that occur within the inner object are propogated directly by a method call to the outter/parent/container object.

    If the "inner" object can be the child of many different TYPES of parents, then create an abstract interface that contains the methods a valid parent must have.

    Hope this helps...
    TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!)
    2008, 2009
    In theory, there is no difference between theory and paractice; in practice there is.

    * Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
    * How NOT to post a question here
    * Of course you read this carefully before you posted
    * Need homework help? Read this first

  12. #12
    dlorde is offline Elite Member Power Poster
    Join Date
    Aug 1999
    Location
    UK
    Posts
    10,163
    Originally posted by TheCPUWizard If the "inner" object will always be contained within an instance of the "outter" object, then a reference to the outter cobject should [IMHO] be passed as part of the constructor to the inner object.
    Agreed - in fact, if the inner object will always be contained within an instance of the outer object, it could be made an inner class, with automatic access to the outer object's fields and methods.

    In the cramped cabin, they could all hear the depth charge as it clanged against the pressure hull...
    Please use [CODE]...your code here...[/CODE] tags when posting code. If you get an error, please post the full error message and stack trace, if present.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center