Such attempts are usually an indication of a misguided design. Rethink
your design.

/Thomas

Is such a loop going to take significantly long compared with the rest
of the action?

If you are sufficiently twisted, from within the constructor of MyButton
you can get the stack trace. Later, at button click time, the stack
trace can be used to find the source of the code that created the
button. Cameron Purdy presented a similar icky piece of code in his weblog:

http://www.jroller.com/page/cpurdy?entry=yaul_trac

Tom Hawtin

The only thing I can think of is to create a class that initializes,
manages, searches an array to print\return the particular JDialog or
JFrame info. Just make sure you do a binary search. You could hard code
or dynamically build this array at initialization of that class. It
could be loaded and initialized before you build your GUI interfaces
(hard coded) or after by dynamically building it. That is, the targeted
array for doing the binary search.

When hard coding the setName() should be a number for an index so you
can do a binary search of the array by just converting the getname() to
an integer for the binary search.. What array, structure, collection,
vector.. is up to your own discretion. You can google for this code or
look at the API's.

This is a general description. At least this entire process can all be
encapsulated into it own class and the he performance will be O(log N).
I think I would approach it this way.

Given the nature of your (rather unusual, but understandable) requirements, I
would do just that.  The performance hit will be totally neglible -- but even
if it wasn't, it wouldn't be /you/ who suffered.

   -- chris

A Listener ?

import java.awt.event.*;
import javax.swing.JButton;

import org.aspectj.lang.Signature;

public aspect ButtonsLogging {

    after(JButton button) :
        set(JButton+ *.*) && args(button)
    {
        final Signature sig = thisJoinPointStaticPart.getSignature();
        button.addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent e) {
                System.out.println("pressed "
                        + sig.getDeclaringType() + "." + sig.getName());
            }
        });
    }
}

piotr

I did this when using textfields to know which textfield currently had
focus which would dictate which attribute from an object class to
modify.  I made a custom textfield class that implemented FocusListener.
Each time focusGained() was called it set the value of a global variable
which contained the name of the field that I set during the field's
instantiating using setName(). This has worked for me for dialogs where
the # of textfields was unknown and could vary from 1 to 50 or more.

I also had a document listener for the textfields so that when a change
was detected in the fields' text I'd grab the value of my global
variable to determine which field was modified and the text in the field
was the new value for the attribute that corresponded to that field. I
found the attribute in a vector by searching for its name(from the
global variable) and assigned it the new value. Later I saved all the
attribute data back to the LDAP server.

There are probably better ways but that's just an idea that may work for
you in a bind.

You can't reliably do that. A given object could be pointed to by multiple or
no fields.  You're better off taking a stack trace at instantiation, and
logging the class and linenum that created you.  This works even when you're
an anonymous subclass or a local variable.

Don't all your buttons have labels anyway?  How do users know what they do
otherwise?  Or at least they have actions.  you can log the action class name.

You're only doing this in debug mode, at instantiation time, right?  How much
performance impact do you think this is going to have?
--
Mark Rafn    dagon@dagon.net    <http://www.dagon.net/>

Your buttons are all assigned to fields? That seems very unusual,
unless you are using a gui builder of some sort.

Is the button text, parent type, and dialog or frame title enough
information to identify the button? If you don't have a lot of tabs
or card layouts with repeated button names in them, it should be.
Otherwise, you could name every button parent in the app using
setName() (assuming names are not used for something else),
then identify buttons by button text and parent name.

Also, you can just use  Toolkit.addAWTEventListener()  to catch
all the button clicks, instead of subclassing JButton.