I hate to add another special case, but with the way the BMenu* classes are designed, I see little in the way of alternatives. If we're a BMenuField's menu bar, then we should invoke the menu item regardless of where in the bar we click. This problem was visible in ticket #1877, where basically you could click only on the portion with text, because that was the size of the menu item, where the rest of the contained menu bar was considered dead space. Thus we now check if we're an instance of BMenuField's special menubar class, and if so we unconditionally select the item instead of a hit test. Fixes the aforementioned bug. If someone has a better approach, I'm all ears.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27271 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Rene Gollent
2008-09-01 19:33:50 +00:00
parent dd114a0c3f
commit 7fb33cd07d
+7 -1
View File
@@ -21,6 +21,8 @@
#include <MenuPrivate.h>
#include <TokenSpace.h>
#include "BMCPrivate.h"
using BPrivate::gDefaultTokens;
@@ -470,7 +472,11 @@ BMenuBar::_Track(int32 *action, int32 startIndex, bool showMenu)
if (Window() == NULL || !window->Lock())
break;
BMenuItem *menuItem = _HitTestItems(where, B_ORIGIN);
BMenuItem* menuItem = NULL;
if (dynamic_cast<_BMCMenuBar_*>(this))
menuItem = ItemAt(0);
else
menuItem = _HitTestItems(where, B_ORIGIN);
if (_OverSubmenu(fSelected, ConvertToScreen(where))) {
// call _Track() from the selected sub-menu when the mouse cursor
// is over its window