Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / GUI / March 2005

Tip: Looking for answers? Try searching our database.

JMenu handling

Thread view: 
Mr Smith - 28 Feb 2005 09:24 GMT
Hello,

For JLists and Jtables, you can have for example Integers as data, a renderer who render a text from the Integer, and when the user select an item, you know wich Integer have been selected.

But what about JMenuItem ? There is no renderer from what i've saw... I've tried to keep a Map (JMenuItem -> Integer) but JMenuItem are not comparable (so no TreeMap).

How do you do that?

TIA
John McGrath - 28 Feb 2005 13:15 GMT
> For JLists and Jtables, you can have for example Integers as data, a
> renderer who render a text from the Integer, and when the user select an
> item, you know wich Integer have been selected.
>
> But what about JMenuItem ? There is no renderer from what i've saw...

No.  The whole point of a renderer is to save resources.  You could have
any number of cells in a table or items in a list.  If each item was a
fill-fledged component, a large table would be very expensive.  So these
components uses the component returned by the renderer to paint the cell.
That generally means that just a few components are used no matter how
large the table is.

Since a JMenuItem does not have many cells or items, there would be no
point to having renderers (well sort of - see note below).  Of course, you
can customize the painting by just overriding the paintComponent() method.

> I've tried to keep a Map (JMenuItem -> Integer) but JMenuItem are not
> comparable (so no TreeMap).
>
> How do you do that?

If you want to associate a property with a Swing component, consider using
putClientProperty().

====================
Note:
  I actually think it would have made a lot of sense to design AWT and
Swing components so that they used a pluggable Renderer to perform the
painting.  If that were done, complex components like JTable and JList
would have used the exact same Renderer mechanism to render individual
cells that components used to render the entire component.  That would
have been a lot cleaner than having a renderer that returns a Component
that is sort of placed in the cell to perform the rendering.

However, the painting mechanism for AWT was designed with Java 1.0, and
the need for separate renderers did not come along until Swing was added
in Java 1.2.  There were some good reasons not to change the way that
painting was done for Swing, since it was built on AWT.  I suspect that
things might have been different had the AWT designers thought of the
requirements that Swing would have.

Signature

Regards,

John McGrath

Mr Smith - 01 Mar 2005 16:06 GMT
> > For JLists and Jtables, you can have for example Integers as data, a
> > renderer who render a text from the Integer, and when the user select an
[quoted text clipped - 3 lines]
>
> No.  The whole point of a renderer is to save resources.  You could have

thx for the tip

> any number of cells in a table or items in a list.  If each item was a
> fill-fledged component, a large table would be very expensive.  So these
[quoted text clipped - 5 lines]
> point to having renderers (well sort of - see note below).  Of course, you
> can customize the painting by just overriding the paintComponent() method.

well, in fact i have done a sub class of JCheckBoxMenuItem, and i have overloaded "getText()", wich seems to work, no need for paintComponent().

> > I've tried to keep a Map (JMenuItem -> Integer) but JMenuItem are not
> > comparable (so no TreeMap).
[quoted text clipped - 3 lines]
> If you want to associate a property with a Swing component, consider using
> putClientProperty().

Hummm... i'm not familair with that, don't have time to learn it right now.

> ====================
> Note:
[quoted text clipped - 12 lines]
> things might have been different had the AWT designers thought of the
> requirements that Swing would have.

not sure what i think about that ;)

thx for your help
John McGrath - 01 Mar 2005 16:12 GMT
> > If you want to associate a property with a Swing component, consider
> > using putClientProperty().
>
> Hummm... i'm not familair with that, don't have time to learn it right
> now.

There is not much to learn.  You store the property in the Swing
component, and then retrieve it when you need it:

  menuItem.putClientProperty( "name", new Integer(1) );
   :
  Integer value = (Integer) menuItem.getClientProperty( "name" );

Signature

Regards,

John McGrath

Mr Smith - 02 Mar 2005 08:38 GMT
> > > If you want to associate a property with a Swing component, consider
> > > using putClientProperty().
[quoted text clipped - 8 lines]
>     :
>    Integer value = (Integer) menuItem.getClientProperty( "name" );

thx for the sample code, i thought there was some kind of callback to setup when the property was changed...

in fact, it seems really simple

i've already done my MenuItem, so next time i will try this :)


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.