determining which widget is focused object

[rodneyt]

Assume following scenario. User has two browser widgets on a card. User could interact (scroll, click, move pointer within) in either widget. What is the best way to determine which widget is focus of user interaction?

It's not possible to use standard Livecode object events - e.g. I understand that the focusedObject and mousewithin don't work with widgets.

I have tried surrounding the widget with a rectangle graphic object. Even if the rect is in front (bring to front) it will not receive mousewithin events if there is a widget within the bounds of the rectangle. I.e. the widget will grab all events.

Can someone tell me the best way to determine if a widget has the user's focus (other than perhaps polling the mouse position).

Possible solution might be to monitor browser widget events as a proxy, and as soon as any event is detected you'd be able to tell the widget is focused. But this would still have some lag so is not ideal.

Surely there is a better way - interested in thoughts from others who are using browser widget.

[Bernard]

MouseMove and MouseEnter work but only when using the pointer tool, not the browse tool.

on mouseMove
put the long id of target()
end mouseMove

MouseDown etc. appear not to register with the widget.

But if you place the mouse over the widget and ctrl+m/cmd+m to get the MB to focus then

put mousecontrol()

shows that the engine knows the mouse is within the widget. It's all a bit rum.

[stam]

if trying to determine which object is clicked on, the target will work with widgets (typically in the container of the widget i'll have a mouseDown handler that tests for the name of the target)
On other occasions i've checked the location of the mouse (eg if the mouseLoc is within the rect of widget myWidget)
At least this has helped with some stuff i've used it with, not sure if that helps you as such...

[dunbarx]

Even if the rect is in front (bring to front) it will not receive mousewithin events if there is a widget within the bounds of the rectangle. I.e. the widget will grab all events.

Is this so? I have never used a widget, but how does LC know there is one underneath another standard control? Do widgets always exist on top of everything, regardless of the layer? In other words, do widgets even have a layer property?

Craig

[rodneyt]

MouseMove and MouseEnter work but only when using the pointer tool, not the browse tool.

on mouseMove
put the long id of target()
end mouseMove

MouseDown etc. appear not to register with the widget.

Yeah - interesting, but that's really much help. When in point tool mode the widget is effectively not executing.

[rodneyt]

Even if the rect is in front (bring to front) it will not receive mousewithin events if there is a widget within the bounds of the rectangle. I.e. the widget will grab all events.

Is this so? I have never used a widget, but how does LC know there is one underneath another standard control? Do widgets always exist on top of everything, regardless of the layer? In other words, do widgets even have a layer property?

Craig

Appears so. of course if you made the gap between the rect object and the widget great enough it might register mouse within before the mouse passes out of detection (ie enters the "event horizon" of the widget out of which no information escapes). But that doesn't work for me.

The only workable solution I can see is a combination of watching all browser widget events (as a proxy for detecting user interaction) and perhaps also periodically polling the mouseLoc to see if within the rect of widget. This is really not ideal. I think the engine should be able to tell the widget is focus of user interaction. Will file as a feature request. It shouldn't be this hard for a developer to figure out what the user's interaction context is.

[Bernard]

There are multiple bug reports (going back some years) about the vagaries of standard messages not being registered for widgets. One of them links to a Forum discussion on the subject, but the Forum link is broken. I remember seeing some discussion on this but couldn't remember where. I suspect it wast on the Forum.

https://quality.livecode.com/show_bug.cgi?id=17424

https://quality.livecode.com/show_bug.cgi?id=21210
https://quality.livecode.com/show_bug.cgi?id=21480
https://quality.livecode.com/show_bug.cgi?id=22719

MouseMove and MouseEnter work but only when using the pointer tool, not the browse tool.

on mouseMove
put the long id of target()
end mouseMove

MouseDown etc. appear not to register with the widget.

Yeah - interesting, but that's really much help. When in point tool mode the widget is effectively not executing.

[PaulDaMacMan]

I realize that I'm several years late to this thread, but I wanted to note for future passers-by that the comments here and bug reports about this 'problem' are basically misinformation...

An Extension Builder Widget does NOT send any events at all by default, and they aren't meant to.

The Extensions author must write handlers that 'post' messages back to the scriptObject, forwarding them in response to touch, mouse, scroll-wheel and other events messages received by the Widget module.

The widget author can mirror the standard engine messages (Exp. in LCB: post 'mouseDown' to tScriptObject) or they can create their own custom messages for their widget: (Exp. LCB: post '"knobTurnClockWise" && tDegrees to tScriptObject). The standard handlers in LCB are defined like so:

Code: Select all

handler OnMouseDown( in pButton as Number)
   post "mouseUp" && pButton
end handler

... OnMouseUp, OnMouseStillDown, OnMouseLeave, and more can be implemented in a widget or not.

On the other hand a Widget might be designed as non-interactive , for use purely a mechanism for displaying some information, and therefore may not be meant to send or receive any messages. So it makes sense NOT to automatically enable a base set of messages sent for widgets (of course some sort of template with these basic handlers filled out is helpful).

For a widget to be able to receive keyboard focus it seems that 'traverOn' must be set to true.

Code: Select all

set the traversalOn of widget "MyKeyboardWidget" to true