<Swing Dev> Bug 6499857: JMenuItem.getRootPane() returns null
Alexander Potochkin
Alexander.Potochkin at Sun.COM
Mon Sep 24 09:46:35 UTC 2007
Hello Miguel
> 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.
Ok
Thanks
alexp
>
> -- 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.
> > >
> > >
> >
> >
>
>
More information about the swing-dev
mailing list