Observers and undo question

thomthom

Doing any model changed in an observer event is like opening a can of worms. In worst case scenario you can make SU crash - which is very likely. Messing up the Undo/Redo stack is another.

Dan Rathbun

There was a similar post perhaps last week on this subject. We noted the API warnings in that post as well.
See: Bug Splat on erase!
He was able to overcome his Splat! by "cheating" the undo stack (see his last post.)

Are you wrapping your transform ?:

begin
  model.start_operation("Brett's Xform")
  #
  ### transform here
  #
  model.commit_operation
rescue Exception => e
  model.abort_operation
  puts("Error #<#{e.class.name};#{e.message}.>")
  puts(e.backtrace) if $VERBOSE
end

Brett McAllister

@dan rathbun said:

There was a similar post perhaps last week on this subject.

Are you wrapping your transform ?:

begin
>   model.start_operation("Brett's Xform")
>   #
>   ### transform here
>   #
>   model.commit_operation
> rescue Exception => e
>   model.abort_operation
>   puts("Error #<#{e.class.name};#{e.message}.>")
>   puts(e.backtrace) if $VERBOSE
> end

No I haven't.
I haven't used any rescue's within my coding, the example you provided,what does the backtrace $VERBOSE do?

Brett McAllister

It's odd, if I trigger the transformation with the tool observer no problem with undo's, redo's ,if I use the entities observer no crashes, but no undo.
Bizarre.

Dan Rathbun

The model edits between the model.start_operation and model.commit_operation are wrapped up into one undo operation with the given name in the menu. There are also some other optional tweeker arguments (listed as "tricky".)

The begin .... rescue ... end block is for standard safety (highly recommended by Google,) as otherwise if an error occurs, the model could become corrupted. The model.abort_operation call in the rescue clause can "reset" the model back (so you don't have a partial group edit, or corruption.)

P.S. See: Bug Splat on erase!
He was able to overcome his Splat! by "cheating" the undo stack (see his last post.)

Brett McAllister

@dan rathbun said:

The model edits between the model.start_operation and model.commit_operation are wrapped up into one undo operation with the given name in the menu. There are also some other optional tweeker arguments (listed as "tricky".)

The begin .... rescue ... end block is for standard safety (highly recommended by Google,) as otherwise if an error occurs, the model could become corrupted. The model.abort_operation call in the rescue clause can "reset" the model back (so you don't have a partial group edit, or corruption.)

P.S. See: Bug Splat on erase!
He was able to overcome his Splat! by "cheating" the undo stack (see his last post.)

Sorry, misunderstood yes I wrap my operation's with model.start and model.commit
Dan from your experience what particular sketchup methods would you recommend using the rescue clause in?, I haven't really struck to many issues with bugsplats or errors but if certain methods throw the odd fault I will insert a few.

I had a look at the post you pointed out,the observer class I have coded is just an standard instantiated class not a tool. this observer runs in the background and reacts to other tools.

thomthom

@brett mcallister said:

I had a look at the post you pointed out,the observer class I have coded is just an standard instantiated class not a tool. this observer runs in the background and reacts to other tools.

Scott from Google recommended using the Tool Observer to make model changes instead of Entity/Entities observers because the Tools observer is more predictable.

Dan Rathbun

@brett mcallister said:

Dan from your experience what particular sketchup methods would you recommend using the rescue clause in?

Oh.. any File operations that don't automatically close the file, perhaps the SU API TextureWriter class, any Import or Exporter.
Maybe the LoadHandler class.

Dan Rathbun

@thomthom said:

Scott from Google recommended using the Tool Observer to make model changes instead of Entity/Entities observers because the Tools observer is more predictable.

I thot he recommended using the ModelObserver#onTransactionCommit() ??

At least you said that he did:
@unknownuser said:

(http://forums.sketchucation.com/viewtopic.php?f)":1nqhthbw]Other notes
Another thing I learned was that doing modifications to the model on observer events can cause lots of problems.

•If a script is doing something which trigger an event that modifies the model it will break the undo stack. I also seem that it can make SU unstable. You could potentially cause infinite loops.
•After consulting with Scott it seems that queueing up a list of modifications to be done to the model and executing the list on ModelObserver.onTransactionCommit is the most reliable way to do it.

Although I've never seen a [ Code ] example posted (hint.. hint..)

thomthom

It's been a bit back and forth. I think it might be a combo - depending on what you do. Even they find the topic troublesome.