Web dialogs stealing focus within my tool.
-
There is a difference between your code calling a key handling callback, and the SketchUp engine doing it.
The SketchUp engine bubbles the keyCode up to the application, (something that often causes the exit from a custom RubyTool.) The API does not have an "official" way to sen keystrokes to SketchUp, but there are some platform dependant ways. On PC, you use the
Win32OLEclass and sendKeys() method from Windows Scripting Host (WScript). -
I've used the Win32 for this in the past:
https://bitbucket.org/thomthom/tt-library-2/src/9ff3a5f08604ed477eb4b17fd63612bfc42832dd/TT_Lib2/sketchup.rb?at=Version%202.9#cl-88Never found a OSX solution though.
-
To make this script 140% complete you probably need to send those key events directly to the Sketchup main window as Dan says and also make the javascript function check that no form input is currently focused.
However this seems to solve my issue and the only thing you need to do in my plugin to be able to use all Sketchup shortcuts is to either click in the main window (just as before) or close the web dialog containing the tool settings which automatically activates the select tool.
-
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+).
-
@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.
-
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
-
@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).
-
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). -
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).
-
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 -
@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?
-
@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_bubbleflag (trueby default for backward compatibility,) that the SU engine checks inToolclass instances.Basically the engine would do a check like:
bubble = tool.respond_to?(:key_bubble) ? : tool.key_bubble : trueWe need to concentrate the talk on keystrokes. Other events just complicate the issue.
-
You can already return true/false in the key event to prevent some propagation.
-
@tt_su said:
You can already return true/false in the key event to prevent some propagation.
In Ruby ?
-
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. -
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.
-
Dang it! That is news to me. Did ya'll hire someone to to be a TechWriter for the API? (Ya' need to badly.)
Advertisement