[Screen] will not close if BMenu is activated

[diver]

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

[jackburton]

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

[diver]

I will recheck it and post back.

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

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

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

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

[anevilyak]

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

[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

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

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

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

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

[diver]

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

[stippi]

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