Opened 11 years ago

Closed 11 years ago

#1808 closed bug (fixed)

[Screen] will not close if BMenu is activated

Reported by: diver Owned by: jackburton
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by jackburton)

Click on menu in Screen preflet to select resolution. Now close this window using the mouse. Notice that Screen still in Deskbar.

Change History (17)

comment:1 Changed 11 years ago by jackburton

ALT-W doesn't work for me if the resolution menu is opened.

comment:2 Changed 11 years ago by diver

I will recheck it and post back.

comment:3 Changed 11 years ago by diver

Ok i used wrong description. You need to click Workspace count menu and close Screen via mouse. This way Screen will stay in Deskbar.

comment:4 Changed 11 years ago by jackburton

Ok I can reproduce it now. What happens is that somehow the menu doesn't get the mousedown event (and this can happen, as long as we use GetMouse() for polling).

comment:5 Changed 11 years ago by jackburton

Owner: changed from axeld to jackburton

comment:6 Changed 11 years ago by jackburton

Status: newassigned

comment:7 Changed 11 years ago by jackburton

Description: modified (diff)

comment:8 Changed 11 years ago by jackburton

Milestone: R1R1/alpha1

comment:9 in reply to:  4 Changed 11 years ago by aldeck

Replying to jackburton:

Ok I can reproduce it now. What happens is that somehow the menu doesn't get the mousedown event (and this can happen, as long as we use GetMouse() for polling).

Do you foresee any issue in converting menu tracking implementation to use mouse events hooks (if i understand correctly)? I'd like to give it a try someday.

I couldn't reproduce this bug btw, but i know the current tracking code is problematic.

comment:10 Changed 11 years ago by anevilyak

If I remember correctly, the big problem with trying to do this is that some of BMenu's API expects the menu to synchronously return which item was selected (i.e. BPopupMenu->Go()) which makes it much more difficult to use the (by definition) asynchronous Mouse* and KeyDown hooks, though this would be a much better solution.

comment:11 Changed 11 years ago by anevilyak

Ah...now I remember. See ticket #1621.

comment:12 in reply to:  10 ; Changed 11 years ago by aldeck

Replying to anevilyak:

If I remember correctly, the big problem with trying to do this is that some of BMenu's API expects the menu to synchronously return which item was selected (i.e. BPopupMenu->Go()) which makes it much more difficult to use the (by definition) asynchronous Mouse* and KeyDown hooks, though this would be a much better solution.

Ok, that's what i thought too. See BMenu::Track() also. So basically we could implement them just by looping/snoozing waiting for the return result to be ready? What do you think?

Regards

comment:13 in reply to:  12 Changed 11 years ago by stippi

Replying to aldeck:

Replying to anevilyak:

If I remember correctly, the big problem with trying to do this is that some of BMenu's API expects the menu to synchronously return which item was selected (i.e. BPopupMenu->Go()) which makes it much more difficult to use the (by definition) asynchronous Mouse* and KeyDown hooks, though this would be a much better solution.

Ok, that's what i thought too. See BMenu::Track() also. So basically we could implement them just by looping/snoozing waiting for the return result to be ready? What do you think?

Actually no, that's not possible, since the thread that mostly calls the functions is the window thread itself. Hence you cannot block it, because then no mouse hooks are called. BWindow has some weird menu related functions and member variables which must have to do with dealing with this problem. I think they are used in our code, but maybe not yet fully to what they were used in BeOS.

comment:14 Changed 11 years ago by stippi

Milestone: R1/alpha1R1

I cannot reproduce this problem at all. I am trying on real hardware and tried with various programs. In Screen, I can open any popup menu and click the window close button while the popup is still open. Screen always quits as expected. I also tried sending Screen a timed quit message from a Terminal while a popup is open.

Both BMenuBar and BMenu poll mouse messages from the history. So they should never miss button events.

How can this problem be reproduced? I am moving it out of the alpha tickets anyways.

comment:15 in reply to:  14 Changed 11 years ago by jackburton

Replying to stippi:

I cannot reproduce this problem at all. I am trying on real hardware and tried with various programs. In Screen, I can open any popup menu and click the window close button while the popup is still open. Screen always quits as expected. I also tried sending Screen a timed quit message from a Terminal while a popup is open.

Both BMenuBar and BMenu poll mouse messages from the history. So they should never miss button events.

They poll mouse messages from the _window_ history. IOW: if another window is closed by app_server's code (when clicking on the close button, for example), the BMenu client side code could receive the message later.

How can this problem be reproduced? I am moving it out of the alpha tickets anyways.

Maybe it has been fixed by your latest changes to mouse messages handling. To reproduce, I just clicked on the window close button and released very quickly, while the popup was opened.

comment:16 Changed 11 years ago by diver

I can't reproduce it anymore, please close it.

comment:17 Changed 11 years ago by stippi

Resolution: fixed
Status: assignedclosed

Thanks for the feedback! Please reopen if someone does happen do encounter it again.

Note: See TracTickets for help on using tickets.