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.