The deactivate events needs to handle the model changes in an operation

Developers Ruby API
1

Hi,
I have the following code for the deactivate.

      def deactivate(view)
        @st = 0
        @pt = []
        lay = Sketchup.active_model.layers.add('Wall')
        lay.visible = true
     end

My extension denied and I receive the following message.
“The deactivate events needs to handle the model changes in an operation.”
Would you please help me with it? Can the following code solve my problem?

      def deactivate(view)
        Sketchup.active_model.start_operation "MAJ Wall"
        @st = 0
        @pt = []
        lay = Sketchup.active_model.layers.add('Wall')
        lay.visible = true
        Sketchup.active_model.commit_operation
     end
2

The second snippet looks better. Generally, all model changes should be made in an operation.
When the user goes to Edit and read the command name for Undo, it should be clear what action they made to trigger it so they know what it undoes.

@tt_su may want to comment too.

1 Like
3

Can we step back once and talk about why you need to add this upon deactivate? What’s the workflow/use-case? Wondering if this can not be done as part of the tool’s earlier interaction?

Doing model changes in events that isn’t direct user input, like mouse click or key presses, are normally unexpected. For instance with observers we require that they make transparent operations such that they chain onto the external event they react to.

If you really need to do something in deactivate I think it’s much the same as with observers. I’m presuming your tool already have done some model changes, and this is some cleanup? In which case I’d made this a transparent operation:

      def deactivate(view)
        Sketchup.active_model.start_operation("MAJ Wall", true, false, true)
        @st = 0
        @pt = []
        lay = Sketchup.active_model.layers.add('Wall')
        lay.visible = true
        Sketchup.active_model.commit_operation
     end

But in general, I’d recommend avoiding this pattern. If you can give some more context we can help out.

1 Like
4

Thank you for your attention. We can use a 2D plan and draw a wall. Then need to draw a window. The problem is 2D plan is under the wall and the user cannot see it. For solving this problem, in the MAJ Window plugin, by first click, we hide the finishing and interior layer, by second click we transparent the wall so the user can see the 2D plan. Users can make a window by 2 next click. If the user terminates the plugin by pressing the space key after 2nd click, finishing and interior layers are hidden and wall material is changed to transparent material. We need to return the wall situation in deactivating it.

5

In that case I would upon deactivate commit the operation to cleanup as transparent (using the fourth paramters of model.start_operation).

That will chain the cleanup operation to the previous commit making the experience for the end user feel like a single operation that can easily and predictably be undone.

2 Likes