OnTransactionStart/Commit oddities?

Dan Rathbun

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?

thomthom

Ugh! The only workaround I can find at the moment is a nasty filthy timer hack.

<span class="syntaxdefault"><br />class ToolModelObserver </span><span class="syntaxkeyword"><</span><span class="syntaxdefault"> Sketchup</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">ModelObserver<br />    <br />    def initialize</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> tool </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">      </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">tool </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> tool<br />      </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">delay </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> 0<br />    end<br />    <br />    def onTransactionStart</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> model </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#puts 'onTransactionStart'<br /></span><span class="syntaxdefault">      UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">stop_timer</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">delay </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    end<br />    <br />    def onTransactionCommit</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> model </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#puts 'onTransactionCommit'<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#@tool.onModelChange( model )<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># (!) onTransactionStart and onTransactionCommit mistriggers between<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#     model.start/commit_operation.<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># Because of this its impossible to know when an operation has completed.<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># Executing the cache on each change will slow everything down.<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># For now a very ugly timer hack is used to delay the trigger. It's nasty,<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># filthy and only works in SU8.0+ as UI.start_timer was bugged in earlier<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># versions.<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># Simple tests indicate that the delayed event triggers correctly with the<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># timer set to 0.0 - so it might work even with older versions. But more<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># testing is needed to see if it is reliable and doesn't allow for the<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># delayed event to trigger in mid-operation and slow things down.<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># Since the event only trigger reading of geometry the only side-effect of<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment"># a mistrigger would be a slowdown.<br /></span><span class="syntaxdefault">      UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">stop_timer</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">delay </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">      </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">delay </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">start_timer</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> 0.001</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> false </span><span class="syntaxkeyword">)</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">{<br /></span><span class="syntaxdefault">        </span><span class="syntaxcomment">#puts 'Delayed onTransactionCommit'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;Just&nbsp;to&nbsp;be&nbsp;safe&nbsp;in&nbsp;case&nbsp;of&nbsp;any&nbsp;modal&nbsp;windows&nbsp;being&nbsp;popped&nbsp;up&nbsp;due&nbsp;to<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;the&nbsp;called&nbsp;method&nbsp;the&nbsp;timer&nbsp;is&nbsp;killed.&nbsp;SU&nbsp;doesn't&nbsp;kill&nbsp;the&nbsp;timer&nbsp;until<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;the&nbsp;block&nbsp;has&nbsp;completed&nbsp;so&nbsp;a&nbsp;modal&nbsp;window&nbsp;will&nbsp;make&nbsp;the&nbsp;timer&nbsp;repeat.<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxdefault">UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">stop_timer</span><span class="syntaxkeyword">(&nbsp;@</span><span class="syntaxdefault">delay&nbsp;</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">        </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">tool</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">onModelChange</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> model </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">        model</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">active_view</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">invalidate<br />      </span><span class="syntaxkeyword">}<br /></span><span class="syntaxdefault">    end<br />    <br />    def onTransactionUndo</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> model </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#puts 'onTransactionUndo'<br /></span><span class="syntaxdefault">      </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">tool</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">onModelChange</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> model </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    end<br />    <br />    def onTransactionRedo</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> model </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">      </span><span class="syntaxcomment">#puts 'onTransactionRedo'<br /></span><span class="syntaxdefault">      </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">tool</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">onModelChange</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> model </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    end<br />    <br />  end </span><span class="syntaxcomment"># class ToolModelObserver<br /></span><span class="syntaxdefault"> </span>

I don't like it, in fact, I hate it. It opens up for worms. But so far it seem to kind of work.
I'd be happy for a cleaner workaround.

scottlininger

Hey Thomthom,

In general, the Observers all work at the core Sketchup level, not at the API level, so you'll get a mess of events that are created from SketchUp's internal messaging mechanism, often in ways that appear bizarre from the outside. When we first started putting Observers into the product we knew that they'd be hard to work with in some cases, and you've delved into a complex example.

I wish I had a simpler one to offer, but I think your timer method looks like a reliable workaround.

thomthom

Thanks for chiming in Scott. Do you however think it would be possible to have an event implemented that triggers when a new item in the undo stack is added? When an operation has fully completed.

thomthom

Side note, can the behaviour to what actually happens be described in the API docs? As it stands now they refer to model.start/commit_operation, which enforces the assumption I made.

Dan Rathbun

OK I GET IT.

I was reading the API docs wrong, and misled myself !

A transaction is a single item, in the operation's list of "things to do." (Just as a transaction on a bank account statement, is a single activity item, for the reporting period.)

SO... We need then:

Firstly... identifying operations by Stringname is problematic, because they need to be localized. It would be nice if Model#start_operation() returned an Integer id.
It may be helpful perhaps if this id, can then be passed to Model#abort_operation() and Model#commit_operation(), within complex conditional statements, so as to tell the Sketchup engine exactly which operation to act upon.

.. and callbacks:

onOperationPreStart( model, op_id, op_name ) callback, that fires immediately BEFORE the operation makes the FIRST of it's transactions.
onOperationComplete( model, op_id, op_name ) callback, that fires AFTER the operation's LAST transaction is complete.

Dan Rathbun

.. I suppose I forgot the following callbacks:

onOperationPreAbort( model, op_id, op_name ) callback, that fires immediately BEFORE the operation aborts the FIRST of it's completed transactions.
onOperationPostAbort( model, op_id, op_name ) callback, that fires AFTER the operation has undone the LAST of it's completed transactions.
onOperationPreUndo( model, op_id, op_name ) callback, that fires immediately BEFORE the operation begins to undo it's completed transactions.
onOperationPostUndo( model, op_id, op_name ) callback, that fires AFTER the operation has undone the LAST of it's completed transactions.
onOperationPreRedo( model, op_id, op_name ) callback, that fires immediately BEFORE the operation begins to redo the operation's transactions.
onOperationPostRedo( model, op_id, op_name ) callback, that fires AFTER the operation has redone the LAST of it's completed transactions.

It may be possible to consolidate these "Operation" Observer callbacks, into a smaller set, by adding an opflag parameter to the first two proposed callbacks (in my previous post):

opflag values:

-2   # an ABORT operation
-1   # an UNDO operation
 0   # a NEW operation
 1   # a REDO operation

I suppose it easier to use a conditional acting on opflag within only two callbacks, rather than have to write 8 separate callbacks.

Anyone else agree ??

thomthom

Dan Rathbun

Yes the more I think about it, 2 Operation callbacks with an opflag parameter makes more sense, less documentation to maintain in the API pages... easier to program.

Simplest all around.