-
-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Popup menu right click behavior #439
Comments
Until better solution
|
Thanks a lot ;-) |
I'll keep this open as I would like to fix that in the core library eventually! |
I have a little problem here, I can make subsequent calls to OpenPopup() recreate the popup but that would break cases of people calling OpenPopup every frame.. Of course that later pattern already had issues and wasn't recommended so breaking it more severely may be desirable? I'm just not sure of the side effects in real codebases. Plan B is to add an additional parameter to OpenPopup Looking into this. |
My 2 cents is that you current version logic is good, so an additional parameter for "special cases" like popup menu looks to be the less destructive and more flexible one. If needed, later you can just switch the default value of this flag ! |
EDIT So while BeginPopupContextItem() could query the Hovered information in another way it would introduce some inconsistency with the api - e.g. the underlying button wouldn't appear hovered but right-click still functions? I'll need to think about different use cases a little more. |
I made it work for I think it's mostly useful for those two cases and a little less so for |
Added the following comment to
I think it is reasonable to say that the function is an optional helper and more intricate behaviour can be assembled by doing it manually. I added declared OpenPopupEx() in imgui_internal.h now because I don't want to take the decision right away of whether adding the additional boolean flag is a future proof solutions (boolean rarely are). I could either decide that OpenPopupEx() become public API (as is, or with modifications) either add a new entry point aside from Let me know! |
should be:
Will turn that into a public thing later. |
… more specific behavior. Will enable improvements for popups/context menus and drag'n drop. (relate ~#439, #1013, #143, #925) The legacy confusing IsItemRectHovered(), IsWindowRectHovered() can be completely removed now. Changed IsWindowHovered() behavior with default parameter: it now return false is the window is blocked by a popup. Demo: Added tests for those two functions.
…duced IsItemHovered() flags to allow reopening another context menu (over same or not same item) with right-click. (#439) (+1 squashed commits)
… a popup stack from truncating the whole stack. This is done by properly refocusing the lower level popup. (~#439)
FYI @ghost @thennequin the current version has this supported by |
…ContextVoid(), OpenPopupOnItemClick() all react on mouse release instead of mouse click. Note that they don't use the full ButtonBehavior() or tracking aabb on both click and release. Applications I've tried seems to behave inconsistently there but on-release-without-tracking is both fairly common and doesn't require extra code for the id tracking. (~#439)
Dear journal, Interestingly, today I noticed that this old commit in 63e4677, effectively changing It's quite convenient as I was trying to solve a small puzzle when custom context menu handling in Tables, and the fact that |
Hi
I try to open a context menu, the first time I "right click" it open, so it is ok.
The next time I right click at another position, the current menu stay open and the menu does not re-open at the new position. How to fix that ? It should be the default behaviour (Just try with a right click on your browser by example).
The text was updated successfully, but these errors were encountered: