Widgets "eating" mouseevents?

[Paul Dupuis]

On 6/15/2017 9:10 AM, Mark Waddingham via use-livecode wrote:
> On 2017-06-15 14:37, Klaus major-k via use-livecode wrote:
>> Hi friends,
>>
>> I know that widget ignore "mouseevents" (up/down/move etc.) if not
>> explicitley scripted in them.
>> OK, but is it neccessary that they also "eat" mouseevents? I hope not!
>>
>> Example: card script:
>> on mousemove x,y
>>   put x && y into fld 1
>> end mousemove
>>
>> Works until you e.g. place a "browser widget" onto the card.
>> No info in field 1 while the cursor is over the widget.
>
> Widgets do need to post events they want script to receive (including
> mouseMove) so they have to be coded to allow this - we're still
> figuring out the best way for this to work to make things more uniform
> and to cut down on code in the widgets people write.
>
> In regards to the browser widget, then that's a separate issue. It is
> a native control, so the engine doesn't get a look in at the events it
> gets at present (I have a vague idea how we might get this to work -
> but it is still a little vague at present!).

I would argue that for widgets to really be accepted as any other
control, they need to accept and pass through, if no handler is present,
a "standard" set of LiveCode messages. Various LiveCode controls have
messages that most users expect are specific to the control - menupick
or scrollbarDrag for example.Then there are a set of messages most, if
not all, LiveCode users expect any control to accept and pass if no
handler is present - mouseEnter, mouseWith, mouseLeave, mouseDown,
mouseStillDown, mouseUp (and probably some more).

Obviously, we could learn LCB and edit every widget we use to add our
own events, but I see this overhead as a barrier that will deter widget
adoption. Please consider defining a set of standard messages all LC
controls accept and pass and enabling Widgets to do the same.