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

Peter M. Brigham pmbrig at gmail.com
Tue Apr 26 08:40:23 EDT 2016


Much of this is spelled out in the dictionary under "listBehavior":

--------
If a field's listBehavior property is set to true, and the user clicks a line, the entire line is highlighted. The Up and Down arrow keys move the selection up or down.

Normally, the mouseUp and mouseDown messages are sent to the field as usual. However, if the user clicks below the last line of text in the field, a mouseRelease message is sent instead of mouseUp.

You use the hilitedLine property to determine which line the user clicked. The field's hilitedLine is set to the new line before the mouseDown message is sent, so there is no way to determine the previously-selected line.

If the field's autoHilite property is set to false, a clicked line does not highlight, regardless of the listBehavior setting; the field does not behave like a clickable list in this case. However, you can set the hilitedLine of the field even if the field's autoHilite is false.

Note: Setting the listBehavior of a field to true will automatically set the field's dontWrap property to true, as a list field cannot have text wrapping. Setting the dontWrap of a list field to false has no effect.
--------

I actually seldom use list fields because of these anomalies (anomalies if you compare them to normal field behavior). I usually script my own behavior in the field script. But the way list fields work is actually fairly rational once you understand it.

-- Peter

Peter M. Brigham
pmbrig at gmail.com


On Apr 26, 2016, at 5:01 AM, Kay C Lan wrote:

> 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.
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list