Start/commit_operation

Jim

One thing you do not want to do with start_operation and commit_operation is nest them - that is, make sure you always commit or abort an operation before starting a new one.

Dan Rathbun

See code post: [Code] wrapping operations

sdmitch

I have given up trying to figure out why .start_operation/.commit_operation inclusion in my Bolt Maker plugin causes periodic bug splats. Even when that didn't happen, the undo capability was the same as if it wasn't included so no gain for the pain. The only commonality of the bug splats seemed to be that the first entity selected was a group with "Head Type:Cap" selected.

If you can figure it out, I would love to hear from you.

Dan Rathbun

My standard advice would be to always develop and test with ALL other 3rd party plugins unloaded. May be that some other plugin's observers are causing the splats.

TIG

Why not put
@ent.erase_entities(@guide1) if @guide1 @ent.erase_entities(@guide2) if @guide2 @ent.erase_entities(@guide3) if @guide3 @mod.commit_operation self.reset()
Inside the begin section where it belongs.
The .abort_operation in the rescue section already removes these temporary guides as everything is undone.
Both the else and ensure sections could then be left empty, because you can end the rescue code with self.reset() too...

LarsG

Start/commit operation has today cost me many hours.

I'm developing a plugin writting in c++ that calls some sketchup functions and one them
is to print some 3d text on a group. That worked fine before I put a start / commit operation
around it then I suddenly couldn't use objects only a command later.
They would be referencing nilClass.

I haven't been able to figure out what it changes, especiallly since disabling the ruby garbage collector didn't
change anything.

( and sorry if my terminology is confusing, ruby is new to me, and Sketchup API (especially when going c++ -> ruby -> sketchup c++ ) is a mystery )

LarsG

whoops, writing that out made me think of something...

Learn To Think... solved my problem, quite stupid mistake that was well hidden.

I believe that if an operation goes wrong after start_operation then other objects will be deleted,
possible all objects created since start_operation.

In my case it was add_3d_face("") which made it so, haven't tested with other functions.

sdmitch

LarsG, That was exactly my situation. Everything worked perfectly but the simple addition of a start/commit block caused references to deleted entities.

Dan Rathbun

@larsg said:

I believe that if an operation goes wrong after start_operation then other objects will be deleted,
possible all objects created since start_operation.

That is what is supposed to happen, and why you should use a begin .. rescue .. end block around your operation, with a call to model.abort_operation() inside the rescue clause, so that a ref to the operation does not remain on the undo stack.
You can also do other recovery code within the rescue clause, so as to prevent actions on deleted entities, or close a logfile handle, etc.

See code post: [Code] wrapping operations

LarsG

First
I guess like the poster I don't really have a point with this rant except to warn others who
is as clueless as I about both neccessary and good practices working with Ruby Sketchup.
As usual when I read your posts, thank you, I find a gold nugget, it is sometimes just hard
to to know that you need it.

Second
I see that it is good and and I agree it makes sence that it works that way..
My irritation points are that:

As far as I know my add_3d_text didn't output any error beside returning a nil
value, a return value you seldom use.

There was (AFAIK) no type of exception raised either.

The documentation is as usual very short and doesn't mention it actually undoing any work,
the work might as well have been undone by a call to abort_operation not automatically.