-
-
Notifications
You must be signed in to change notification settings - Fork 313
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
Controls don't consider mouse down
and mouse up
positions
#339
Comments
This could be a bit tricky, actually it is difficult to implement it in an immediate mode UI, it would require some kind of static variable registering where the press was initiated... In my tools I take care of that at user side, where I can create that kind of static variables. |
You could totally add a |
mouse down
and mouse up
positions
Saw that the other day here. tsoding uses raylib in his project. He is explaining cancellability of UI interactions and the problem he encountered when he releases the mouse over an other UI element. He fixed it by introducing active UI element IDs. Could such a concepts also be used in Raygui? I guess ImGui also use such a concept. |
@mashhoodalvi Maybe but it should be investigated... as commented I try to avoid/minimize global states as much as possible... |
Two new globals have been added to raygui that could be used to address this kind of issues: static bool guiControlExclusiveMode = false; // Gui control exclusive mode (no inputs processed except current control)
static Rectangle guiControlExclusiveRec = { 0 }; // Gui control exclusive bounds rectangle, used as an unique identifier |
It's possible to toggle a checkbox by pressing down the mouse outside the checkbox, dragging the mouse over the checkbox, and releasing the mouse. It's generally preferable for checkboxes to require both the mouse down event and the mouse up event to both occur within the checkbox's bounds. This is also an issue for other raygui controls, like buttons and sliders.
Screen.Recording.2023-10-02.at.4.51.02.PM.mov
This issue is particularly annoying in interfaces where dragging is part of the user interactions - the user could be dragging something and then unintentionally trigger controls when the mouse is released. Take this 3d program for example:
Screen.Recording.2023-10-02.at.4.56.46.PM.mov
(yes in this example you can manually;y work around around the issue, but that's work the end user is doing to get a control to work the way it should've worked in the first place)
The text was updated successfully, but these errors were encountered: