OK, I think I get it - you want to use the cantSelect property to address the issue of the disabled property not properly disabling controls (i.e. still triggers other mouse messages than mouseUp/Down), right?RCozens wrote: ↑Sat Mar 25, 2023 5:19 pmI must admit it did occur to me that including the cantSelect property in my request might trigger that response, Andy. I really don't know what the Pointer Tool is used for beyond what I use it for, which is to be able to select a control when testing/debugging without triggering a mouseUp handler. If it has other uses that impact end users, then I need to rethink my position.
But from my perspective, the Pointer Tool provides developers a means for using the mouse during testing/debugging in ways that differ from the Browser Tool's capabilities. If during testing I want to look at or change the properties or script of a control whose cantSelect property is true, I must currently gain access to the control via the Project Browser or the Message Box. Allowing a developer to select a control whose cantSelect is true has no more more effect on the end user's experience than allowing that developer to click on a control without triggering mouseUp.
I've never used cantSelect as anything but a means to prevent some controls from being selected when I move stuff around with the pointer tool. I admit I use it very rarely, but it seemed to me it would lose all purpose if the one function of it - "can't select" - was bypassed. But yes, it can be said to have additional functions.
Still, when I develop and want to prevent mouseEnter/Leave etc to trigger in a control (disabled or not) when I pointer tool it, I would just put a leading "if the tool is not "browse tool" then pass mouseEnter" in it's script.