[haiku-development] Re: BMenu click behaviour
- From: "Chris Peel" <chrispeel.mail@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 20 Nov 2013 06:09:27 -0800 (PST)
This is an issue I've had when developing applications for Windows. My
expected behaviour is that clicking the popup button opens the menu and then
closes it on a second click - effectively acting as a toggle.
Many Microsoft products display this behaviour but it is not easy to replicate
with the standard Win32 API, hence why many 3rd party products simply reopen
the menu on subsequent clicks.
I found a workable solution was to disable mouse input to the owning window and
then handle a mouse click hit test which dismisses the menu, enables the window
again and eats the click message. Selecting an item from the menu simply
enables the owning window as the menu is dismissed anyway.
I don't know if any of this helps, or how easily it transfers to Haiku; just
thought I'd share my experience.
Chris
—
Sent from Mailbox for iPhone
On Wed, Nov 20, 2013 at 11:32 AM, Stephan Aßmus <superstippi@xxxxxx>
wrote:
> Hi,
> Am 20.11.2013 um 11:35 schrieb Julian Harnath <julian.harnath@xxxxxxxxxxxxxx>:
>>
>> I've been looking into a bug which crashes Gobe Productive whenever you
>> click twice on one of its toolbar popup-menu buttons (i.e. click on the
>> button again while the popup-menu is already open -> crash).
>>
>> The problem is in BMenu -- when you call BMenu::Show() twice, it crashes
>> (view gets added twice which calls into debugger()). The second click
>> on a popup menu in Gobe running on Haiku causes Show() to be called a
>> second time.
>>
>> I checked how it works in BeOS. With a little test application I
>> verified that it also crashes when BMenu::Show() is called twice, so
>> Haiku is not different in this regard. However, when a BMenu is shown
>> on BeOS, you cannot click on anything else in the window until the menu
>> is closed again. That is why clicking twice doesn't crash when running
>> Gobe on BeOS: the second click doesn't register.
>> On Haiku, when a menu is open, you can still directly click other UI
>> elements (click goes through).
>>
>> So, questions...
>> - is this different behaviour intentional? (I assume yes, in the end
>> click-goes-through seems more useful.)
>> - if yes, should we fix it by allowing BMenu::Show() to be called more
>> than once, i.e. ignore further calls when the menu is already open?
> A third option may be that the menu is forced to close /before/ the click
> registers. But in this particular case, it is hard to achieve the optimal
> behavior. I've worked on these type of controls in another context. The user
> expectation is for the popup to close when they press the button again that
> opened in the first place. And I also find it better that clicks register
> elsewhere additionally to closing such popups. However, in Gobe Productive,
> the behavior would result in either the menu staying open (making
> BMenu::Show() robust), or the menu opening again (when the menu is forced to
> close, but the click registers).
> Maybe… if clicks /near/ popup don't register and just close, but clicks
> farther away close and do register. That might actually make sense, but can
> also feel inconsistent. However, considering that the effects of the click to
> close the menu is easier seen when the click was near but does not register,
> maybe it's an OK solution that would also reinstall the correct behavior for
> Gobe Productive.
> Best regards,
> -Stephan
Other related posts:
