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 <[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.
>
>
