I only want to monitor model.entities. If the user adds a group or component where new entities are created, then I don't care about them. It is the normal behavior of the plugin. It may sound absurd but makes sense in the context of the plugin functionality.

Yes, I'm sure. The entities I want to monitor are always added to Sketchup.active_model.entities.

@thomthom said:

What if something is contained in a group/component?

I don't understand what you mean. I have an internal list of entity IDs (they are groups), and if the modified entity ID is inside this list, I show a message box.

@thomthom said:

"Save" - saving a reference to the material object?

Yes, and the transformation one.

@thomthom said:

And all of these message boxes - all they do is display a message? Nothing that is done depending on how the user interacts with the messagebox?

Nothing. Just messages.

Ok, I have three types of observers:

Type 1 < AppObserver

Attached to Sketchup. It defines:

-onQuit, that asks the user to save certain structure of my plugin

-onNewModel, that does the same as onQuit plus hiding the plugin toolbar

-onOpenModel, that does the same as onNewModel

Type 2 < EntitiesObserver

This one is attached to Sketchup.active_model.entities at the beginning of the code. It defines:

-onElementModified, that checks if the modified entity is included in an internal list. In that case, shows a messagebox.

Type 3 < EntitiesObserver

This is attached to some special entities in my application. I have to save the transformations that the user performs on them. It defines:

-onElementModified, that saves the transformation and material of the modified entity

-onEraseEntities, that shows a messagebox

-onElementRemoved, that shows a messagebox

Ok, they ARE the problem.

I have just checked what happens if I don't attach an observer to Sketchup.active_model.entities, and everything is fine with *_operation.

But I still have bug splats when closing SU. I bet this problem has to do with the other EntitiesObservers...

By the moment I need this observers, so I will have to resign myself until the observers run smoothly...

By the way, your overview was so useful to me some weeks ago (I was struggling with another bug). It is a great job

Thank you

thomthom: I have a command that resets the plugin, which users may use. By the moment I'm not worrying about the undo stack, but this is a future task...

But I have just realized one thing:

Sometimes, when I close SketchUp after using my plugin, I get a bug splat. Maybe it is probably due to the same reasons, I mean, when closing SU, the current operation commits, isn't it?

I didn't give it importance at the beginning, because I couldn't reproduce the conditions in which the bug arised... The fact is that, now I realize, everything is OK if I don't delete entities. I have always thought that the bug was some consequence of using EntitiesObservers.

I have some groups.entities in my plugin with this kind of observers attached, but these groups aren't the ones I delete inside the previous affected code. When I need to erase them (outside this code), I check if they have an attached observer and in that case I first remove the observer and then I erase the group.

I have also an EntitiesObserver attached to Sketchup.active_model.entities, which only defines the onElementModified method. This method only does something when the modified entity ID is inside an internal list (there are few entities inside this list).

These observers don't make changes inside the model. Anyway, might them be the source of all my problems?

Dan and Jim: No, I'm not deleting entities as I iterate over the C++ collection. I delete the entities using object attributes, that is, I have something like this:

class Shape

  attr_accessor ;group

  ...

  def erase()
    Sketchup.active_model.entities.erase @group
  end

end

At certain moment, I need to erase all the shapes, so I iterate over MY array of shapes:

shapes.each { |s|
  s.erase
}

thomthom: OK, I didn't know that heavy scripts often prevent the UI to refresh.

By the moment I'm happy with this behavior. Moreover, I have been told to refresh the UI, so the user can see the steps the algorithm is taking (how the entities are added and erased): I don't need to preserv performance any more. Everything is ok (no bug splats at all) when I don't use start_operation and commit_operation.

In case I need to preserv performance again, I will make use of the begin.. rescue.. endidea

Thank you very much

Hello,

I am developing a backtracking algorithm in which I call the method intersect_with of Entities. Can I have any clue about its implementation?

The fact is that I need a quicker version of this method (given that it is called inside a backtracking algorithm, it can be invoked many times). I have been told to re-implement the method, just in case there is a more efficient way to do it... But probably now it's implemented in the best possible way (maybe with the help of Computational Geometry, or perhaps using the SU merging capabilities).

Another question in the same topic: when the receiver entities object of intersect_with is INSIDE an entity (for example, a face and its edges contained in another face), the method intersect_with doesn't work (the intersection is nil). I have to call it with the receiver object and the argument swaped, so the first is surrounding the second instead of being surrounded. Can I get the intersection without making these two checkings for every entities object?

Thanks in advance,

Ada

Thank you for your answers

thomthom: No, my code is not verifying the entities. I will fix this, but by the moment I answer your questions:

Q: does it splat if you do not use start_operation? No.
Q: Does it splat if you set the disable_ui flag to false? No.

It only splats when I set the flag to true and I have to delete entities inside the affected code (I have checked this). But now I have noticed a stranger behavior: the view does not refresh until the end, even if I do not put the start_operation and commit_operation callings surrounding the code. I mean, after the backtracking algorithm I can see the result, but I need to put an active_view.refresh calling each time I modify the entities inside the code if I want to see the partial solutions. Does SU refresh the view periodically or just when the entities are changed? I'm a little confused. Anyway, with this behaviour I don't need setting the disable_ui flag to true, so my problem disappears...

TIG: It splats with or without the Outliner window rolled-down.

Hello,

I am developing a plugin in which, at certain moment, I need to switch off the view refreshing, due to performance reasons. So I surround the affected code with Model.start_operation (with the flag disable_ui set to true) and Model.commit_operation. The problem is that I'm getting bug splats when doing the last call (the commit_operation one). Everything is ok until then.

Any idea? The callings are not inside observers. I have some of then in my application, but they don't trigger during the execution of the affected code. I add and delete entities massively (the code is a backtracking algorithm), but as far as I know this is not supposed to be a problem...

Thanks in advance,

Ada