I believe last time I checked I was able to use the above on a control or container.
This morning I wanted to use this behavior to temporarly block interactions but it wasn’t working.
As always, I first thought I did something wrong in my script . Finally, ended-up creating this very simple PG and surprise, it looks like these have no effect anymore.
Besides, I also noticed this helper when hovering the property, explaining that ‘isPointerBlocker’ is FALSE by default EXCEPT on buttons, radio, checkbox, input, slider… Where I believe, it’s likely the other way round, isn’t it?
Yep, it seems like this is not working as expected!
Not sure what “raise pointer events but not react to them” means, but i would expect the callback not to be executed.
I’ll see what we can do about it
Oh, wait. I got it.
This is the correct behavior. The button animation does not trigger, but the events are being raised.
Well, ok. Not sure why because ‘readOnly’ should be ‘readOnly’ the way I understand it.
But then if ‘isPointerBlocker’ would also act the same, how am I supposed to block my pointer (events) interactions? And I’m pretty sure (about 99%) I used this before for blocking events.
Oh, pointerBlocker means that pointer events will not bubble to the 3D scene.
What you can do is check for the button state in the callback you have defined and not react if it it sread only, or simply disable the button by setting ìsEnabled = false`
Thank you, yes. I believe ‘isEnabled’ is the one I used. Just forgot about it
The comment for the helper still remains though. I believe the word ‘except’ should be removed because I believe the controls listed are the ones that are no pointer blockers.
OK @RaananW I might have marked it as a solution a bit too early. Although the solution with the button state callback would work, I’d like to understand why:
- When using the ‘isEnabled’ property, the control automagically turns grey.
- Why would a property named ‘isReadOnly’ set on a GUI element would still trigger a pointer event.
- Why would both ‘isPointerBlocker’ and ‘isReadOnly’ act the same in the aspect of pointer events.
This is all not very clear to me. I hope it is for you, is it?
Thanks, your explanations are very good and overall make sense (as always ).
However, I still do not understand why there is nothing except a callback on a button state to simply block/stop all pointer events on a given control or container (except for isEnabled and next having to tweak this to make it so that it keeps with its color or to set the color I want). May be it’s just me.
Anyways I’m gonna use the callback and check state method for my case and for now.
Thanks again for your reply and for your dedication to our user experience and have a great day
Edit: Forgot to say and I just thought about this: Since I didn’t use a button, but a rectangle and a textBlock and since the textBlock is actually a blocker by default and is on top of the container in the hierarchy, I think I’m gonna just twist this by making my tb the size of my container and set the tb to ‘isPointerBlocker’. How fancy is that?