<Swing Dev> Bug 6499857: JMenuItem.getRootPane() returns null

[Miguel Munoz]

Alex,

  I got this message when I submitted it: Your suggested bug-fix has been assigned an internal review ID of:
 1070487
As for the rest of the email, I'm still investigating. However, I've discovered that the JPopupMenu's parent is set to null when I call getRootPane from a JMenuItem, but it has a parent when I call it from a JButton. I don't know where it's value gets set yet, but I'm investigating. 

-- Miguel Muñoz


Alexander Potochkin <Alexander.Potochkin at Sun.COM> wrote: Hello Miguel

> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6499857
> 
> I submitted a fix. 

Sorry, I can't find the fix

How did you submit it ?

> The fix works for JMenuItems, but when I look at the 
> documentation, I see that other components may also be added to JMenus, 
> and the fix won't work for them. But after experimenting, I discovered 
> that, if I add a JButton to a JMenu, the bug doesn't show up. So the bug 
> only affects JMenuItems that are added to a JMenu.
> 
> This raises an interesting question. Is there a better fix for this? 
> Right now, JMenuItems are added to menus through a special mechanism, 
> and other JComponents are added through the standard mechanism, but they 
> both work as menu items. 

Do you mean JMenu.add(JMenuItem) comparing with JMenu.add(JComponent) ?

Their implementation looks almost identical

> Furthermore, getRootPane() works for items 
> added through the standard mechanism. This raises an obvious question: 
> Would JMenuItems work fine if added through the standard mechanism? If 
> so, that would be a better fix, and here's why:
> 
> There are a few related bugs. For example, bug 4231737 (which has the 
> mysterious designation of RFE) is caused by 
> JOptionPane.getWindowForComponent(Component parentComponent), which 
> calls itself recursively like this:
> 
>   return JOptionPane.getWindowForComponent(parentComponent.getParent())
> 
> (with other code to end this cycle cleanly.)
> 
> Looping on parent.getParent() is a common thing to do, and shows up in 
> these four methods in SwingUtilities:
> 
> Window getWindowAncestor(Component c) 
> Window windowForComponent(Component c) 
> Component getRoot(Component c) 
> JRootPane getRootPane(Component c)
> 
> I'm sure a few developers have also written this loop. And all of these 
> fail for JMenuItems for the same reason getRootPane() fails.
> 
> So I am currently investigating why getRootPane() works for a JButton 
> added to a menu, and I'm looking at how hard it will be to make 
> JMenuItems work through the standard mechanism instead of the custom 
> one. (I realize this is probably a long shot.) If that works, it would 
> be a better fix, because it would fix all four of the methods above, as 
> well as every individual developer's parent=parent.getParent() loop.

It would be really great to investigate all of that questions

Thanks
alexp

> 
> -- Miguel
> 
> 
> */Alexander Potochkin /* wrote:
> 
>     Hello Miguel
> 
>      > The problem is simple. The getRootPane() method calls
>      > SwingUtilities.getRootPane(Component c). That method loops on a
>     call to
>      > getParent, like this:
>      >
>      > for( ; c != null; c = c.getParent()) {
>      > if (c instanceof JRootPane) {
>      > return (JRootPane)c;
>      > }
>      > }
>      >
>      > The trouble is that anything placed on a menu doesn't belong to the
>      > standard hierarchy. JMenus use a JPopupMenu, and JPopupMenus
>     don't have
>      > a parent, they have an invoker.
>      >
>      > An obvious fix would be to override getParent() in JPopupMenu to
>     call
>      > getInvoker() and return that. This doesn't work. The getInvoker()
>     method
>      > returns a Component, but getParent() returns a Container. I can work
>      > around this, but it breaks the menu code.
>      >
>      > The fix is to complicate the loop on c = c.getParent(), by
>     checking for
>      > JMenuItems and handling them differently. This slows the loop
>     down, so I
>      > don't want to do that in Swing Utilities, because there's no need
>     for
>      > the more complicated loop for most components. Instead, I plan to
>      > override getRootPane() in JMenuItem.
> 
>     This sounds like a good idea
> 
>      >
>      > This is complicated by the fact that not all JMenuItems are broken.
>      > JMenus are subclasses of JMenuItem, and they have a valid parent
>     (unless
>      > they're a submenu). But that should be easy to work around.
>      >
>      > I'll have some code in a day or two. I'll include a test program.
>     Are
>      > there any constraints I should know about for the test program?
> 
>     We use jtreg harness for our regression tests
> 
>     http://openjdk.java.net/jtreg/index.html
> 
>     It might look a bit messy,
>     but actually it's quite simple to write a test with jtreg
> 
>     In your case, I imagine, you'd check JMenuItem.getRootPane()
>     and throw RuntimeException if it is null just like with JUnit
> 
> 
>     Thanks
>     alexp
> 
>      >
>      > -- Miguel Mu�oz
>      >
>      >
>      > On Sep 20, 2007, at 6:55 AM, Alexander Potochkin wrote:
>      >
>      >> Hello Miguel
>      >>
>      >>> I plan to fix bug 6499857. There are a couple of approaches, but I
>      >>> think I know the best way to fix it. Has anybody else looked at
>     this?
>      >>
>      >> Currently no one works on this fix
>      >> so you are welcome to start with it !
>      >>
>      >> Thanks
>      >> alexp
>      >>
>      >>> -- Miguel Mu�oz
>      >>> ___________________
>      >>> There are 10 kinds of people: Those who know binary and those
>     who don't.
>      >>
>      >
>      > ___________________
>      >
>      > There are 10 kinds of people: Those who know binary and those who
>     don't.
>      >
>      >
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070924/e7096ee0/attachment.html>