Re: Sticky popup menus

Donald Arseneau <asnd@triumf.ca> writes:

> Brian <bgriffin@model.com> writes:
> > problem. What's happening is that the menu gets posted such that an active
> > menu entry is under the mouse pointer as a result of the <ButtonPress>
>
> Yes, I know that is exactly what is happening. And I call that a timing
> problem!

But I shouldn't claim to know everything that is happening.

Which invocations of tk_popup is this patch intended to fix
the stickyness? I had thought that it would indeed make them
all sticky, but damage the ability to dismiss them. But trying
it out, it only seems to make a limited class of popups sticky,
namely those posted rooted at the pointer location exactly.

Is this bug report made in some particular context that I
didn't catch?

I see that the patch fixes the stickyness of popups coded like:

bind all <ButtonPress-3> {
    tk_popup .menu [winfo pointerx %W] [winfo pointery %W]
}

but using

tk_popup .menu [expr {[winfo pointerx %W]+10}] [expr {[winfo pointery %W]+10}]

gives a non-sticky popup with or without the patch, whereas

tk_popup .menu [expr {[winfo pointerx %W]-10}] [expr {[winfo pointery %W]-10}]

causes accidental selection, with or without the patch.

But maybe I am just looking at the wrong problem.

By the way, that MenuInvoke bound to any "button" release
is nasty when you try to use the mouse wheel :-(

-- 
Donald Arseneau                          asnd@triumf.ca