http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6499857
I submitted a fix. 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. 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.
-- Miguel
Alexander Potochkin <[EMAIL PROTECTED]> 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.
>
>
