Skip to content
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

OnPress is sent on TCastleButton.Enabled = false #413

Open
eugeneloza opened this issue Nov 10, 2022 · 1 comment
Open

OnPress is sent on TCastleButton.Enabled = false #413

eugeneloza opened this issue Nov 10, 2022 · 1 comment
Labels
backlog - undecided Tasks that seem low priority we are not sure whether they need to be done at all.

Comments

@eugeneloza
Copy link
Member

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.

@michaliskambi michaliskambi added the backlog - undecided Tasks that seem low priority we are not sure whether they need to be done at all. label Feb 28, 2023
@michaliskambi
Copy link
Member

The question here is "what is more natural".

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?

my-new-projecteee-0.1-src.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog - undecided Tasks that seem low priority we are not sure whether they need to be done at all.
Projects
None yet
Development

No branches or pull requests

2 participants