List Field Not receiving Mouse messages unless a line is clicked?

[Kay C Lan]

On Tue, Apr 26, 2016 at 9:56 AM, Sannyasin Brahmanathaswami <brahma at hindu
.org> wrote:

>
> Certainly a newbie will be very frustrated if they want to trap for
> mouseup or down when it works for all other field types and all other
> objects.
>

OK I'll offer an alternative view. Craig has already mentioned that he's
never noticed this before, and I would suggest no-one ever does unless they
are trying to do something that is 'unusual'.

Take any menu button (option, pulldown etc), mouseDown on it, hold it down
and then slide the mouse outside the btn and release - no mouseUp is sent
to the btn.

Take a Tab button and click in the shaded area that comes attached with it.
No mouseUp is sent to the btn.

You only get your mouseUp sent to a btn if you release the mouse whilst it
is over a valid option. *

As for 'trap for mouseUp' works for 'all other field types', when I drag a
plain old vanilla field to a brand new stack, set it's script to:

on mouseUp
  beep
end mouseUp

then enter some words into the fld and then start clicking around; nothing
happens. That would be because the LC8 Dictionary says: If an unlocked
field is clicked with mouse button 1 or 2, no mouseUp message is sent. I'd
suggest that will catch out more newbies than List fields.

As for a List field, it's valid options are lines. Anything outside a valid
'line' is not a valid option, so just like buttons, and unlocked flds, no
mouseUp is sent.

You've already discovered a very simple workaround which probably suits
your use case. Other normal approaches to this type of thing I've seen are
either a 'Reset' button or a line that says 'No Selection' which makes it
very obvious where to Click to get the desired outcome. How would you reset
a single/bunch of menu button/s to a default state? Why not a consistent
approach for a List fld?

* It's a little more complex than that. You can't mouseDown in object 1 and
release it over a valid option in object 2 and get a mouseUp message in
object 2. The mouse can wonder all over the place but it needs to start and
finish in the same object for a mouseUp to fire. It's all very clever and I
suspect for good reason - it behaves as we've come to expect in 99.99% of
situations.