Web dialogs stealing focus within my tool.

Aerilius

Would there be a way for SketchUp to modify WebDialogs to "continue bubbling up" from the document root to the SketchUp main window?

I've implemented something similar to jolran's method that sets a Tool class variable for the status of the ctrl, shift and alt keys (Select Entity tool in Ruby Console+).

tt_su

@aerilius said:

Would there be a way for SketchUp to modify WebDialogs to "continue bubbling up" from the document root to the SketchUp main window?

That would be a great feature. I'd love to see some improvements to the Tool class and in particular the WebDialog class.

If people can flesh out use cases and scenarios that's be of great help to determine the shape of these improvements.

eneroth3

Sidenote: when using paint bucket tool and the main window is focused the mouse cursor changes wen pressing and releasing modifier keys as expected. When the material browser is focused the mouse cursor changes when pressing down a key BUT NOT when releasing it. However the mouse cursor updates as soon as you move the mouse so the tool seems to know that the modifier keys aren't hold down, it's just the cursor that doesn't update.

Tested in SU 2013 and 2014 on Windows7

jiminy-billy-bob

@tt_su said:

If people can flesh out use cases and scenarios that's be of great help to determine the shape of these improvements.

In Layers Panel, I wanted to allow users to use their SU shortcuts even if my dialog was focused (Except the ones I trap).

Aerilius

Scenario 1:
When a webdialog is designed to be used in parallel with the currently selected tool (any replacement for a native inspector dialog, like layers panel), not consistently workig shortcuts interupt the user's workflow.

Scenario 2:
When a webdialog is used as toolbar to launch a tool, the tool won't get modifier keys until you have clicked at least once into the drawing (and maybe you didn't want to do that click).

eneroth3

I've been thinking about an implementation. In some cases the developer might not want this so it shouldn't always be enabled (and it could break existing plugins). What about an extra argument for creating web dialogs that by default is false?

There could also be a check on the web side that prevents the key event from being sent to SU in case an input or textarea element is focused.

One scenario where the developer don't want to send the key events to Sketchup (except for the obvious one of writing in a form) could be custom shortcuts within the web dialog (save, reload etc).

Dan Rathbun

It would be alot simplier if there was a UI::send_keys() module function very similar to (or wrapping) this Windows Scripting Host function:
http://msdn.microsoft.com/en-us/library/8c6yea83(v=vs.84).aspx
.. in fact here is a C++ implementation:
http://www.codeproject.com/Articles/6819/SendKeys-in-C

Aerilius

@eneroth3 said:

In some cases the developer might not want this so it shouldn't always be enabled.

Absolutely right!

The event bubbling concept in the HTML DOM allows to "cancel" further bubbling, if your event listener has already "fullfilled" the event and there is nothing left that you want to happen (otherwise the next, outer event handlers would get the event and act on it). Expanding this concept from WebDialogs to the SketchUp window could be done re-use something with which developers are familiar, without adding new API methods or arguments.

No matter how it would be realized, it would really be useful for us developers if SketchUp could incorporate this feature.

Would it make sense to allow this for different kinds of events, or should it filter out all except keyboard events?

Dan Rathbun

@aerilius said:

Expanding this concept from WebDialogs to the SketchUp window could be done re-use something with which developers are familiar, without adding new API methods or arguments.

How can a feature be added, without adding some interface to the SketchUp API ? Impossible.

There needs to be some key_bubble flag ( true by default for backward compatibility,) that the SU engine checks in Tool class instances.

Basically the engine would do a check like:
bubble = tool.respond_to?(:key_bubble) ? : tool.key_bubble : true

We need to concentrate the talk on keystrokes. Other events just complicate the issue.

tt_su

You can already return true/false in the key event to prevent some propagation.

Dan Rathbun

@tt_su said:

You can already return true/false in the key event to prevent some propagation.

In Ruby ?

tt_su

Aye.
One of them things not mentioned in the docs I think. (On our list to fix.)
I came across it once when I noticed odd behaviour with key events and realized it depended on the return value of my last statement in the onKey events.

eneroth3

At least on windows you can prevent ALT from focusing the menu when used in a tool. Either true or false (can't remember) as return value from the onKeyDown method prevented the default behavior.

Dan Rathbun

Dang it! That is news to me. Did ya'll hire someone to to be a TechWriter for the API? (Ya' need to badly.)