The Pointer Tool does not recognize a button's disabled property

[RCozens]

Greetings all,
The attached stack demonstrates that mouseEnter and mouseLeave handlers for a disabled button are triggered if the Pointer Tool is selected.
I see this as a genuine bug; but discretion cautions me to post this to the Forum before filing a bug report in case I'm missing something.
Cheers!
Rob

[dunbarx]

Rob.

I see where you are coming from, that is, a disabled control ought to be seen but not heard.

But the dictionary is very clear that a disabled control cannot receive mouse clicks or keyboard presses. It says nothing about such things as "mouseEnter". In other words, it may not make sense, yet may not be considered a bug.

Craig

[dunbarx]

And I see now what you are on about, at least a little; the browse tool does not invoke those messages in a disabled control. That makes the whole idea of disabling rather more twisted.

If not a bug, it surely stinks.

Craig

[stam]

Confirmed on a different stack.
But whether that constitutes a bug is debatable - like many things in livecode there's more than one way of looking at things.
I mean it's pretty minor issue having to guard against mouseEnter/Leave messages in disabled state (eg if the disabled of me then exit to top, or some such).

But in the scenario where the button must be disabled but you still want to implement some action on mouseEnter/Leave even if 'disabled', then that gets trickier... so arguably the current implementation gives more flexibility. Arguably...

[RCozens]

Craig, Stam, et al<

So a bug or a "feature"?

It's certainly a distraction: even now that I'm aware, I still do a double take when messages pop up where I don't expect them. The first few times this occurred I spent some time trying to track down what was triggering it.

Anyway, thanks for checking it out.

Rob

[FourthWorld]

The button's disabled property will prevent browser tool messages. And its cantSelect will prevent pointer tool interactions, effectively locking it to browse mode regardless of the current tool. Try setting both disabled and cantSelect and see if that does what you need.

[dunbarx]

Richard.

The dictionary is silent on the idea that certain messages can be enabled or disabled depending on the state of "cantSelect" and the current tool. It deals mainly with direct user actions like clicking on it or dragging across it.

I do not blame the dictionary for neglecting these sorts of esoteria.

Craig

[RCozens]

Try setting both disabled and cantSelect and see if that does what you need.

Hi Richard,

Thanks for your suggestion. The current configuration works fine for the user experience I desire; the issue only arises when I toggle between the Browse Tool and the Pointer Tool during testing & debugging. I could, of course, turn cantselect on and off whenever I toggle the disabled property, and may do so if I find the issue too annoying.

After further testing today I would note that this issue also arises with disabled fields. It's not a major issue because I'm just displaying help messages; but if someone else had more complicated mouseEnter/mouseLeave handlers, having them rum unexpectedly might cause bigger problems.


i find it difficult to believe this is a feature, not a bug.

Rob

[RCozens]

I could, of course, turn cantselect on and off whenever I toggle the disabled property, and may do so if I find the issue too annoying.

Actually, this will not work for me: If I am testing/debugging, I may indeed want to select the button to retrieve its properties or script.

Rob

[dunbarx]

Rob.

If you are testing/developing, add a little something, like holding down the optionKey.

Craig

[RCozens]

So a bug or a "feature"?

I decided to skirt this issue by submitting an enhancement request instead of a bug report.
My submission is blocked because I have not entered the Windows version #, which I have no opportunity to enter.
Step 4 of the submission process ("I can see this bug in") only sporadically displays the O/S piulldown after I select "IDE", and after selecting Windows it does not display the version pulldown.
What's a mother to do??
Rob

[RCozens]

Ignore my last comment: by changing my pulldown responses and reentering them I was successful.

Bug 24150 - Pointer Tool should respect a control's disabled property but ignore its cantSelect property.

Rob

[Klaus]

Some time ago there was a discussion on the LC mailing list about whether "mouseenter" and "mouseleave"
in a button script should be triggered also with the pointer tool selected. IT ACTUALLY DOES!
And finally "they" came to the conclusion that this is in fact a feature and not a bug.

I still don't get it...

[SWEdeAndy]

Bug 24150 - Pointer Tool should respect a control's disabled property but ignore its cantSelect property.

Say what?! What would be the point of the cantSelect property if the pointer tool was allowed to ignore it???
That's basically the only thing I use cantSelect for - to prevent the pointer tool from selecting the control. E.g. when 'rectangle-selecting' several controls in complex layouts, and making sure certain controls don't get accidentally included in the selection and moved or deleted.
The control can still be easily selected in the project browser when needed.

[RCozens]

Say what?! What would be the point of the cantSelect property if the pointer tool was allowed to ignore it???

I 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.

Cheers!

Rob