Dears,
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?
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?
The GUI elements are a whole package, including default colors and other fun stuff (like the effect when you click on them)., The disabled state makes the button gray. You can change this behavior, of course, but this is what we (the team) thought would make sense when the button is disabled. similar to the way disabled button in HTML works.
Good question! poor naming on our part TBH. what is meant by “isReadyOnly” is that the effects that happen when pointer events are raised (hover, leave, click and so on) or not influencing the button. Poor naming. BUT, since we support back-compat, we can’t really change it.
They don’t. isPointerBlocker is not doing more than block the events to the 3D scene (or better yet “further down the event tree”). so if you have a button and a sphere behind it, and both have a pointer down callback registered, setting isPointerBlocker = true will not trigger the click on the sphere, if the button was clicked.
Having said that if I misunderstood or if what i said is not truly the case, I will be happy to debug 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?
. Finally, ended-up creating this very simple PG and surprise, it looks like these have no effect anymore.
).
