So, are the deleted entities in observer calls unusable ?
Like: onComponentRemoved(definitions, definition)
definition is basically unusable, for example I wanted to get_attribute for some specific info so I can delete it properly from my other structures.
This is forcing me to keep a map/array of entity and custom info.
I wonder why the entity is not actually deleted after this call to the observer is completed…
The fact that observers cannot make changes to the model without “opening a can of worms” is in my view a fundamental flaw in the implementation of observers in the SketchUp API.
Design is fundamentally about iteratively manipulating the relationships between objects. There are thousands of potential applications where, if the user moves adds or deletes an object (beam, duct, wall or space), the relationship or connection to other objects needs to automatically change. This is by far the most useful potential for observers, yet none of it seems possible in the current implementation.
Ironically, one of SketchUp’s great strengths is how it automatically changes, adds or deletes faces in response to action by the user upon edges. (Add this fundamental weakness of observers to the list of my previous posts about the weakness of attribute dictionaries and dynamic components.)
Yeah, I am aware that in-observer code might damage the scene/crash SU, but that is easy to protect from the C++ core SU side, if one really wants that.
At least I would like access to the deleted entity attributes, because I store custom info in those, and I need that to act upon deletion of the entity (in my case I store a persistent ID, good thing the new SU has persistent IDs so I can drop it soon).
In my C++ project I always delete the object after observers are called. The user KNOWS that onDeleteThing is called since they write the actual function override of the observer. They have the object in its full form, non deleted, but the user knows it will be deleted after it leaves the observer callback, so she/he can prepare other object relations having the soon-to-be-deleted full info at hand.
Do you have examples of other API implementations of observers that work the way you desire?
There is a fundamental challenge with observer events in the middle of a running operation - any change the observers make can invalidate the original premise of the original operation running. That is why operation events are sent when the active operation has been allowed to complete - in order to ensure API users that when they create an operation an perform changes and computations to the model it’s allowed to complete without interference.
One could perhaps debate read-only model access to observer events, but there is no easy facility for that in SketchUp at the moment.
We have many extensions on the warehouse that react with model changes to observer events. do you have a specific case scenario in mind? (Probably best as a new topic.)
Protecting from crashes is one part - but also ensuring that an operation is allowed to complete is also important.
That is a common scenario that occur. That’s where my previous comment about the possibility of read-only access.
I still dont understand what can the user do wrong with an entity that’s about to be deleted ? Even if the user keeps the ref somewhere or refs of entity’s parts, its the user’s fault. I can crash SU in any way.
And if you refer to the completion of an operation, I still dont see any problem, the entity is about to be deleted, but first just let me have full access to it, BEFORE you delete it, it’s my fault if I reference it in new objects being created.
And about observers, this is stupid really, then just take them out of the API anyway since they’re pretty useless if I cannot do whatever I want with the scene when something happens, regardless of what happens.
Useless observers, debug what? probably debugging your own SU core C++ code…
“Note that the observers related to transactions (aka undoable operations) are primarily for reporting and debugging. Performing any edit operations of your own (such as modifying the model) inside the observer callback should be avoided, as it could cause crashes or model corruption.”