raygui
raygui copied to clipboard
`GuiToggle()` always returns 0
https://github.com/raysan5/raygui/blob/45e7f967e62088b9fec02ac38c07d4b67d6466b0/src/raygui.h#L2025-L2071
Not sure if it's a bug or not. The documentation seems to have changed from the version used with the raylib-python-cffi, but those docs made it seem like it should return true when active.
raylib-python-cffi is probably out of date. All the controls were changed to return ints as status values (i.e. 1 or 0). In this case the status value is always 0. You should use active to get the toggle state.
Actually this does seem inconsistent; GuiMessageBox for example returns the clicked index instead of using a pointer. Maybe this needs to be redesigned to be more consistent.
@SirNate0 @Anut-py Latest raygui 4.0 release was a big redesign of the library moving all controls data from return values to function parameters and return values were left for internal control states values required by users. This is still under design trying to find a common pattern for all controls on what kind of info should be returned (i.e. Mouse states over control, focus state, specific required states to be exposed...)
Help and feedback on this improvements are welcome!
@SirNate0 @Anut-py Latest
raygui 4.0release was a big redesign of the library moving all controls data from return values to function parameters and return values were left for internal control states values required by users. This is still under design trying to find a common pattern for all controls on what kind of info should be returned (i.e. Mouse states over control, focus state, specific required states to be exposed...)Help and feedback on this improvements are welcome!
I also noticed this, (in the old behavior it was something like this "return 1 when clicked", the newer version broke some code of mine)
Would be nice if the Gui-Elements returns 1 when clicked or interact with, some sort of "onChange"-Event.
they are also "render-only" Gui-Elements with int as result. (like GuiGroupBox, GuiLabel, ...)
those can also return 1 when clicked, maybe enable this feature via macro (?)
For GuiToggle, it can return 1 when clicked:
// Check toggle button state
if (CheckCollisionPointRec(mousePoint, bounds))
{
if (IsMouseButtonDown(MOUSE_LEFT_BUTTON))
{
state = STATE_PRESSED;
result = 1;
}
else if (IsMouseButtonReleased(MOUSE_LEFT_BUTTON))
{
state = STATE_NORMAL;
*active = !(*active);
result = 1;
}
else state = STATE_FOCUSED;
}
For something like GuiToggleGroup, it can be "number of GuiToggle interact": result += GuiToggle(bounds, items[i], &toggle); .
GuiScrollPanelcan return 1 when scrolled.GuiComboBoxalso didn't return anything, return 1 when clicked oractivegot changedGuiTextBoxMultireturns an boolean (butGuiTextBox()returnsint)GuiDummyRecalways returns 0 ???GuiListViewEx/GuiListViewresult ???, return 1 when clicked, return 2 when scrolled ... (?)GuiColorPaneldidn't return anything, return 1 when change color (?)GuiWindowBoxcan return different values. "clicked-in-box" (2), close window (1), ...
If some value changed or the user interact with the Gui-Element, I can do something like this:
if(GuiButton(...)) { ... }
if (GuiToggle(...)) {
// do stuff with change toggle value
}
if (GuiTextBox(...)) {
}
// some special cases ...
if (GuiDropdownBox(....)) {
case 1:
// item got selected (clicked)
break;
case 2:
// clicked out-of-box, "close" DropdownBox
break;
}
I'm sure enums can help as results:
typedef enum {
TEXTBOX_CLICKED = 1
} GuiTextBoxResult;
@furudbat Thanks for the review! Actually, I would like to find a consistent convention between all controls in that regards.
For example:
typedef enum GuiControlResult {
RESULT_NONE = 0,
RESULT_FOCUSED = 1,
RESULT_CLICKED = 2,
RESULT_SCROLLED = 3,
RESULT_CUSTOM01 = 4,
RESULT_CUSTOM02 = 5,
} GuiControlResult;
But every control has to be carefully analized to see what are the possible internal states that could be returned. It would be nice to unify the possible return values but also allow per-control custom return values.
Your controls list with a potential return state is a good start.
Opened a separate issue to review.