Model Observer Strange Behavior

Developers Ruby API
1

I am really confused about how the transaction start commit system is supposed to work when they are firing off like this. Here is the output from me opening a component, adding a single edge inside it, then closing it

Double Click Component
onTransactionStart: #Sketchup::Model:0x000226bd3c59e8
onTransactionCommit: #Sketchup::Model:0x000226bd3c59e8
onActivePathChanged: #Sketchup::Model:0x000226bd3c59e8
onTransactionStart: #Sketchup::Model:0x000226bd3c59e8
onTransactionEmpty: #Sketchup::Model:0x000226bd3c59e8

Draw single edge with pencil tool
onTransactionStart: #Sketchup::Model:0x000226bd3c59e8
onTransactionCommit: #Sketchup::Model:0x000226bd3c59e8
onElementAdded: #Sketchup::Edge:0x000226bd2ad858

Press escape to exit component
onTransactionStart: #Sketchup::Model:0x000226bd3c59e8
onTransactionCommit: #Sketchup::Model:0x000226bd3c59e8
onActivePathChanged: #Sketchup::Model:0x000226bd3c59e8
onTransactionStart: #Sketchup::Model:0x000226bd3c59e8
onTransactionEmpty: #Sketchup::Model:0x000226bd3c59e8

Why is it starting and committing the transactions for adding an edge before the edge actually gets added?

2

If I remember correctly, the order in which observers are added can affect the order of their “reaction”.
I have no idea how your code is looks like…

Another experience I have is that there are mysteries (bugs) around some of them.
But I “played” with them a long time ago.

You can check the issue tracker filtering to “observer” too:
https://github.com/SketchUp/api-issue-tracker/issues?q=is%3Aissue+is%3Aopen+observer

1 Like
3

The observers were overhauled in the 2016 release.

See this section of the API Release Notes and download and read the explanatory PDF file linked there.

1 Like
4

i read the PDF and it looks like mine is not behaving the way the PDF says it should. For loose geometry it behaves normally:
start operation>add/remove/modify>commit operation
but for geometry inside a component or group I get start>commit>add/remove/modify

class MyModelObserver < Sketchup::ModelObserver
    def onActivePathChanged(model)
      puts "onActivePathChanged: #{model}"
      $current_entities_observer = MyEntitiesObserver.new
      if Sketchup.active_model.active_path && ($current_path = Sketchup.active_model.active_path.last)
        $current_path.definition.entities.add_observer($current_entities_observer)
      else
       Sketchup.active_model.entities.add_observer($current_entities_observer)
      end
    end

    def onTransactionStart(model)
      puts "onTransactionStart: #{model}"
    end

    def onTransactionCommit(model)
      puts "onTransactionCommit: #{model}"
    end

    def onTransactionUndo(model)
      puts "onTransactionUndo: #{model}"
    end

    def onTransactionRedo(model)
      puts "onTransactionRedo: #{model}"
    end

    def onTransactionAbort(model)
      puts "onTransactionAbort: #{model}"
    end

    def onTransactionEmpty(model)
      puts "onTransactionEmpty: #{model}"
    end
  end

  class MyEntitiesObserver < Sketchup::EntitiesObserver
    def onElementAdded(entities, entity)
        puts "onElementAdded: #{entity}"
    end

    def onElementModified(entities, entity)
        puts "onElementModified: #{entity}"
      end


    def onElementRemoved(entities, entity_id)
        puts "onRemoveEntities: #{entity_id}"
    end

    def onEraseEntities(entities)
        puts "onEraseEntities: #{entities.map(&:entityID)}"
        end
end
5

Well, the changes cannot occur until the operation is committed.

See the Model#start_operation and Model#commit_operation method documentation.

But this is not to say that there are not bugs in the API. See the tracker as @dezmo said.

Also, there is a forum topic on observer callbacks out of order that resulted in a formal tracker issue being logged. (Observers firing sequence)

1 Like