aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes Override JComboBox toString() behavior? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Override JComboBox toString() behavior?" Watch "Override JComboBox toString() behavior?" New topic
Author

Override JComboBox toString() behavior?

Cy Bird
Greenhorn

Joined: Feb 18, 2003
Posts: 16
Rather than solid dataobjects, I've got a generic class that is used to by all of my data... rather than explicit getters and setters there is a getPropery("field") method that returns me what I want.
Problem is on a JComboBox. I was using toString() when I was populating with solid objects. Now, toString() could mean anything.
Is there a way to overide either the comboBox or the model to tell it to display what I want? To make it configureable?
Thanks.
Avi Abrami
Ranch Hand

Joined: Oct 11, 2000
Posts: 1134

Hi Cy,
Pardon me if this is a silly suggestion, but have you thought about subclassing "JComboBox" (or the "model") and overriding the "toString()" method (perhaps :-)
Hope this helps.
Good Luck,
Avi.
Dana Hanna
Ranch Hand

Joined: Feb 28, 2003
Posts: 227
Personally, I'd go back to the data objects. It makes more OO sense. However, it is very easy to implement a model or renderer for you generic class.
Ashish Mahajan
Ranch Hand

Joined: Feb 19, 2003
Posts: 77
Hi Cy,
As Dana said. A custom renderer is what u r looking for. Also as he suggested consider going back to classes/objects those real fundas of OOPS


The best teams have no specialists, only general contributors with special skills
Ashish Mahajan
Ranch Hand

Joined: Feb 19, 2003
Posts: 77
Hi Cy Bird,
Just wondering, have u considered going back to OOPS funda yet.
The pattern that u r using is a "Singleton Pattern" and should be used when there should be a single instance of any class. Typically such classes r managers in the design. They manage resources and defines commn protocol betn different objects.
Some e.g. :- A manager managing print services, ApplicationManager keeping registry of applications running in an multi Application environment. etc.
Do u know doing this for every objects will be horrible to maintain large projects. The major prob with this pattern is that generally such classes object reference should be got thru a public static method. So to give subclasses change to override behaviour such classes should look up environment variable like System.getProperty("myclass") to initiate the instance. In ur case then all the classes should have to look up the environment.
Hope u'll reconsider ur design decision.
Sincerely,
Ashish
Cy Bird
Greenhorn

Joined: Feb 18, 2003
Posts: 16
Thanks for the replies... I ended up extending JComboBox. My new comobbox now holds a map of all my elements. The ID is the key, and the value is my my custom bean. Very similar to the hard objects, just a little lighter and more cusomizable. The only reason we're going this way (we're using DynaBeans btw) is for memory purposes. Our app has to run on really slow machines and we have a lot of gui-rich features. Just trying to eliminate some weight...
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Override JComboBox toString() behavior?