Observers and undo question
-
Hi guys
Just trying to finish of a plugin I have been working on and struck an issue.
I am transforming a collection of vertices which is triggered via the entities observer using the onElementModified method.
The issue I am getting is that once the vertices are transformed you can no longer undo or redo anything.
The undo just repeats it's self but nothing changes.
Would this be an issue with my code or is it just another observer issue.Regards
Brett
-
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.
-
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
-
@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? -
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. -
The model edits between the
model.start_operation
andmodel.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. Themodel.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.) -
@dan rathbun said:
The model edits between the
model.start_operation
andmodel.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. Themodel.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.
-
@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.
-
@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. -
@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 onModelObserver.onTransactionCommit
is the most reliable way to do it.Although I've never seen a [ Code ] example posted (hint.. hint..)
-
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.
Advertisement