Re: Menu bug?
Re: Menu bug?
- Subject: Re: Menu bug?
- From: Bill Cheeseman <email@hidden>
- Date: Sat, 15 Mar 2003 11:51:16 -0500
on 03-03-15 11:12 AM, John Louch at email@hidden wrote:
>
> Correction: I was only testing the role of one of the UI elements, which is
>
> AXMenu. When I test the role of the other, it is AXMenuItem. Yet they both
>
> seem to represent the same UI element. That's apparently why they don't
>
> compare as CFEqual, and my workaround fails if I also test for the role of
>
> the other.
>
>
>
> This happens with both Cocoa and Carbon targets.
>
>
I believe this is a bug, I opened on to cover this case. Coco and Carbon
>
share the same menu system. So they will have the same results.
In devising a workaround in my app until this is fixed, I wonder which is
the best way to go. Should I ignore the spurious menu item in the menubar
when looking up through the parents, or should I insert a spurious menu item
in the menubar when looking down through the children? I guess it's always
easier to ignore something that is there than to create something that isn't
there, so I'll probably ignore a menu's parent if its parent menu item's
parent is the menu bar.
The "spurious menu item in the menu bar" feature is mirrored all the way
down the tree of nested submenus, so I assume this is reflecting some
underlying reality in the menu system. It seems that every menu has a paired
menu item with the same name, all the way through the hierarchy. It seems to
reflect the notion, in a submenu system, that every menu item is also
potentially a menu (in the sense that it might have submenus).
But I don't know why this would be extended to the top level of menus in the
menu bar, which will never be menu items in the traditional, non-technical
sense of the word (although, for example, Interface Builder thinks the menu
widgets you install in a menubar are menu items).
The thing that looks most like a "bug" here occurs only at the top, menu bar
level. Below that level, both the AXChildren-looking-down and the
AXParent-looking-up trees have duplicate matching menus and menu items. It's
only at the menu bar level that there is a lack of parallelism: looking up,
you see menu items in the menu bar, but looking down you only see menus in
the menu bar.
I can see how this discrepancy could have come about. At deeply nested
levels, the parent of a menu item is always a menu, and the parent of a menu
is always a menu item with the same name (that is, a menu that acts like a
menu item). When working up the tree, the code doesn't look ahead to see if
it's almost at the top, so when it gets to the menu in the menu bar it just
goes ahead and creates a parent menu item, as usual, without realizing that
it has reached the menu bar. Then when it looks for that menu item's parent,
it suddenly finds the menu bar and it's too late. But, going down from the
menu bar, everybody knows that its children are menus, not menu items, so it
doesn't create the spurious menu item. (This is all just speculation, of
course.)
Menus have other problems with their parents, anyway (they can't see their
parents when the menu isn't open), so I think I'll just always ignore the
spurious parent menu item if its parent is the menubar. At least when trying
to compare parents and children.
I wonder how GUI scripting deals with this?
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.