You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TCastleButton.OnPress is sent even to enabled=false
As OnPress/OnRelease are called from inherited Press function which happens before checking for Enabled
For some reason it doesn't send onRelease in exactly the same situation though, maybe because of VisibleChanged in SetEnabled?
All in all it results in unexpected behavior: The button is disabled but sends OnPress event, and doesn't send OnRelease which makes the button "pressed" until clicked again.
The text was updated successfully, but these errors were encountered:
With the current approach "a button that has Enabled=false" behaves exactly the same as "non-interactive UI, like TCastleRectangleControl". Attaching the test.
More explanation:
The OnPress and OnRelease events, like Press and Release methods, exist in all UI controls, including things that don't have any Enabled and don't usually react to any input, like TCastleLabel or TCastleRectangleControl. So they report when you press or release something (key, mouse) over given UI control, ignoring any conditions "is something interactable".
OTOH the OnClick, which is specific to TCastleButton, and should be used to detect clicks on a button, of course honors Enabled properly.
So the general advise is use OnClick to detect when user clicks on button; never use OnPress / OnRelease for this purpose .
As for release behaving differently: There is no difference in my tests. The disabled button will send OnRelease just like it sends OnPress. What is different (and what you maybe observed) is reporting of release events when you move mouse outside of the UI area between "mouse down" and "mouse up".
When a control Press method returns true (like TCastleButton with Enabled=true) then this control "captures" subsequent mouse events (mouse move, mouse release). So an enabled button will receive Release call (and thus generate OnRelease) regardless of whether the mouse was released over the button or not (and it will generate OnClick only if mouse was released over button).
When a control Press method returns false (like TCastleButton with Enabled=false, or anything else like TCastleLabel or TCastleRectangleControl that leaves Press unhandled so by default returning false) then the control doesn't capture mouse (as the container considers "this control is not interested in this mouse event"). So it will receive Press( and thus generate OnRelease) only if mouse was released over control.
This "capture" mechanism is done using internal TCastleContainer.FCaptureInput, it was inspired by X windows mechanism capturing mouse events in similar way, from what I recall :)
All in all
on one hand, I agree it may be untuitive that OnPress / OnRelease are generated by buttons with Enabled=false.
However, it is intuitive if you realize "all UI controls generate OnPress / OnRelease, regardless of their class or enabled state".
If we start to disable events on non-enabled buttons, we'll have to think e.g. what to do with OnUpdate, OnMotion on disabled buttons. Should they stop working too?
TCastleButton.OnPress is sent even to enabled=false
As OnPress/OnRelease are called from inherited
Press
function which happens before checking forEnabled
For some reason it doesn't send onRelease in exactly the same situation though, maybe because of VisibleChanged in SetEnabled?
All in all it results in unexpected behavior: The button is disabled but sends
OnPress
event, and doesn't sendOnRelease
which makes the button "pressed" until clicked again.The text was updated successfully, but these errors were encountered: