OnTransactionStart/Commit oddities?

thomthom

Test with plain SU8 installation - using Jim's observer test suite:

(One Face with four edges in model)
attaching #<ObserverTests::ModelObserver:0xb06051c> to #<Sketchup::Model:0xb06128c>
Activate Move
Initial Click
-onTransactionStart:#<Sketchup::Model:0xb06128c>
Move Cursor
Second Click
onTransactionCommit:#<Sketchup::Model:0xb06128c> -onTransactionStart:#<Sketchup::Model:0xb06128c> onTransactionCommit:#<Sketchup::Model:0xb06128c> -onTransactionStart:#<Sketchup::Model:0xb06128c> onTransactionCommit:#<Sketchup::Model:0xb06128c> -onTransactionStart:#<Sketchup::Model:0xb06128c> onTransactionCommit:#<Sketchup::Model:0xb06128c>

Expected result would be just one onTransactionStart and onTransactionCommit.

I really thought the ModelObserver could be used to detect the start and end of an undoable operation. But it seem to trigger as often as the EntitiesObserver.

thomthom

Tested in SU 7.1.6860 : Same as SU8

Tested in SU 6.4.265 : Works as expected! One onTransactionStart and one onTransactionCommit

This looks to be a regression bug.
One that's turning out to be very troublesome...

thomthom

However, this didn't work as expected under SU 6.4.265

Sketchup.active_model.start_operation('test')
-onTransactionStart:#Sketchup::Model:0x10c1f660
onTransactionCommit:#Sketchup::Model:0x10c1f660
true
Sketchup.active_model.active_entities.add_cpoint [10,10,10]
-onTransactionStart:#Sketchup::Model:0x10c1f660
onTransactionCommit:#Sketchup::Model:0x10c1f660
#<Sketchup::ConstructionPoint:0x10c1bdf0>
Sketchup.active_model.active_entities.add_cpoint [20,10,10]
-onTransactionStart:#Sketchup::Model:0x10c1f660
onTransactionCommit:#Sketchup::Model:0x10c1f660
#<Sketchup::ConstructionPoint:0x10c1bb20>
Sketchup.active_model.commit_operation
-onTransactionStart:#Sketchup::Model:0x10c1f660
onTransactionCommit:#Sketchup::Model:0x10c1f660
true

Dan Rathbun

So this is perhaps why the poster, over at GG was having problems ??
GoogleGroup: "transaction model question"

Would my idea of a "manual" callback be a valid workaround ?? (If not as I've shown, perhaps moving the call after the commit call?)

thomthom

I was trying to use the observer because I wanted to catch any actions performed while my tool is active. It draws a UI based on the model geometry so I need to refresh when the geometry changes. And I wanted to catch events where a custom action from outside my plugin was triggered.

Dan Rathbun

Does the disable_ui flag have any difference in the effect ??
Also.. I wonder about the transparency flags.

But it does seem like a bug. We would want them to trigger only once, per operation, per model.

Dan Rathbun

@thomthom said:

... I wanted to catch any actions performed while my tool is active. ...

And that stickin' ToolsObserver still will not fire for Ruby tools, right?

thomthom

@dan rathbun said:

Does the disable_ui flag have any difference in the effect ??

I tried both. Same results.

@dan rathbun said:

And that stickin' ToolsObserver still will not fire for Ruby tools, right?

onActiveToolChanged triggers, but not onToolStateChanged.
Besides, many actions are not triggered by a tool.

Once more I seem stomped by observers. I swear, they'll be the bane of me.

Dan Rathbun

@thomthom said:

@dan rathbun said:

And that stickin' ToolsObserver still will not fire for Ruby tools, right?

onActiveToolChanged triggers, but not onToolStateChanged.

As I remember, onActiveToolChanged didn't give us any useful data.
The tool_id just says 50000 (or similar,) for ANY Ruby tool, and "RubyTool" for the tool_name.
I wish they would fix this...

@thomthom said:

Once more I seem stomped by observers. I swear, they'll be the bane of me.

I suppose the built-in Standard Ruby Observer class won't work ether huh?

TIG

Some 'transparent' tools like Zoom or Pan don't trigger.
Other native-tools do trigger... BUT some have names not exactly equivalent to what you might expect.
Plugin tools all return the same value/name !

thomthom

I can't find any combination of methods or observers that will let me know reliably when an operation has been committed.

Guess it time to brush the dust of that old State of Observers list again...

Dan Rathbun

@thomthom said:

I can't find any combination of methods or observers that will let me know reliably when an operation has been committed.

You want the Start of the OP, and the finish of the OP ??

TIG

...onChange half-works, ...onCommit doesn't ?

thomthom

@dan rathbun said:

@thomthom said:

I can't find any combination of methods or observers that will let me know reliably when an operation has been committed.

You want the Start of the OP, and the finish of the OP ??

I want to catch the commit of an operation so I know I can rebuild the geometry cache I use to draw my tool's UI.

Dan Rathbun

OK, so are you the one writing the operation ?? or is this one of Sketchup's normal undo operations ?

Chris Fullmer

Bummer Thom, I just played with the oncommitaction observer yesterday for the first time and I did not encounter any oddities, but I did not test it more than just drawing a few lines.

thomthom

@dan rathbun said:

OK, so are you the one writing the operation ?? or is this one of Sketchup's normal undo operations ?

I want to catch any operation. By me, by other plugins, by SU's native commands. I'm writing a custom Select tool and therefor any operation might occur while the tool is active - and I need to know when it does.

thomthom

@chris fullmer said:

Bummer Thom, I just played with the oncommitaction observer yesterday for the first time and I did not encounter any oddities, but I did not test it more than just drawing a few lines.

Did you draw a few lines between start/commit_operation ? and the observers triggered only once?

Chris Fullmer

I didn't attach a startaction observer. I only cared about actions finishing. And in the end I decided I really wanted to watch for entities being added to the model, so I moved away quickly from the transaction observers.

thomthom

Yea, its the completion of an operation I'm interested in as well. It's just that I noticed it mis-triggers just like the end does.

@chris fullmer said:

And in the end I decided I really wanted to watch for entities being added to the model, so I moved away quickly from the transaction observers.

But do you want to be notified for each entity being created - before the operation has fully completed?