There are 2 problmes there:
- onToolStateChanged is almost never called when using Paint Tool. I triggered it once, but I cannot reproduce.
- the only time it did, the state was 0.
see also http://forums.sketchup.com/t/when-using-rotate-tool-in-ontoolstatechanged-state-never-equals-1-bug/25704 for a likely related bug.
Well, the observer code “under-the-hood” was revamped in the last release. It appears that all the observer calls are now being queued up, and called after the current operation is done.
I noticed this when testing the other issue you posted on the RotateTool. All the state change observer calls are “dumped” at the end of the rotate operation. Which, yes, makes the
ToolsObserver just about worthless now.
We had long [years] ago (before the observer engine overhaul was conceived,) asked that the
ToolsObserver be fixed, expanded, and extended to Ruby tools. (It has always returned “Rubytool” as a name for all non-native tools, and never included the id or state functionality for API tools.)
I think that when it comes to most other extension authors (and remember that the SketchUp team is also one, as they have several important “core” extensions that use API tools,) … I think that they decided that most authors would not want other coders messing with, nor interfering with their tools. It could create a support nightmare scenario.
So, this observer really only “works” with native tools, and has always had a bunch of quirks (call them bugs, if you must.) Historically, when an extension author asked how to code some workflow, that integrated the native tools via the
ToolsObserver, and then ran into a problem,… historically they’d be told it would better for them to program their own API tool, mimicking the behavior of the native tool.
So, metaphorically, you may be “beating a dead horse”.