Web dialogs stealing focus within my tool.

[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.)