Pushing and popping a tool works in many but not all cases

ymalaika

Hello. I'm creating a camera manipulation tool and am looking to replicate this standard SketchUp behavior:

If I am in the middle of a push/pull, and I activate the orbit tool, change the view, and then hit ESC to cancel, the original push/pull resumes operation at the state it was at. It also recovers to its previous state if from the view tool I directly reactivate push/pull using a hotkey, toolbar, or menu.

One way I've found to do this is to call

Sketchup.active_model.tools.push_tool( mynewToolObject )

instead of

Sketchup.active_model.select_tool( mynewToolObject )

Curiously, this works as desired when using drawing tools like Rect, Line, etc., but not entirely for manipulation tools like push/pull, move, etc. For manipulation tools, if they are mid operation, push_tool() will return false and my tool never gets its activate() call. The manipulation doesn't get interrupted.

If the manipulation tool is not dragging something, however, everything works as expected.

I see there's a Tool.suspend() and Tool.resume(), but these appear to be more like onSuspend() and onResume(), meant for handling that external event when called by SU. It's way cleaner and better encapsulated if an individual Tool need not be aware of the stack it's in, and that appears to be the API intent...

Does anyone have experience doing this or perhaps know of any other plugins that I should reference?

Thanks in advance,

-Y. Malaika

thomthom

hmm.... I've been using push and pop tools, but never tested it during the operation of existing tools. That's some interesting observations you made there.

( Tool.suspend() and Tool.resume() doesn't exist - only the on* events you mention later. There isn't even a Tool prototype class. )

AdamB

I gave up using select_tool as it doesn't play well with other plugins.

BTW If you want to know what method selectors are being fired at your Instance that are not implemented, just add:

def respond_to?(msg) result = super puts "unhandled respond_to(#{msg})" unless result result end

So add that to a Tool and see every method invocation you're ignoring!

Dan Rathbun

@adamb said:

So add that to a Tool and see every method invocation you're ignoring!

Except for the mouse movement callback.
If you don't use it, the console will get filled with messages, so bypass them.
Insert a short-circuit line in the respond_to?() overridden method:

return nil if [:onMouseMove].include?(msg)

ymalaika

I've decided to abandon the tool route. By running outside the tool stack I am able to change the view asynchronously, so the user can navigate without having to explicitly invoke or change tool modes. It's a much more fluid experience, and with the exception of a few minor cases that I think I can work around, it doesn't disrupt tool operation.

Thank you for the useful tips, everyone. This is a really fantastic forum!