In order to monitor the deleted ComponentInstances, I added a DefinitionObserver. But when I deleted the component, I found that I could only know the definition of the ComponentInstance I deleted, and could not obtain instance information. For example, the persistent_id of the instance. And I can delete other content related to this instance through the ID. Of course, I have also considered traversing all instances of this definition, but I think that will make my program very slow. I am very eager to get a solution to this problem.
After reading the API documentation, my initial idea was that this instance was a Sketchup:: ComponentInstance. It inherits the method persistent_ id.But in the end, I got such an error report.
If what I wanted is impossble. Could please tell me what message I can get by definition and instance when I use DefinitionObserver. Perhaps through this information, I can generate some ideas that can achieve the functions I need.
To my knowledge the answer is no. There’s been discussions to add an observer that fires before delete so you can read data on what is being deleted.
At first glance, “before action” observer callbacks would seem to be a useful thing. But since the pending action is tied to the state of SketchUp and the model, I think there would need to be clearly defined limits on what could be done by the callback. Otherwise model database corruption and crashes might result! The analysis to find those limits could be pretty tricky.
If possible, I hope you can share the link to the post. I want to see if it can be helpful in achieving my target function. Thank you.
What you said is indeed very reasonable. It is indeed impossible for us to trace back the deleted data. Otherwise, it will cause the model database to crash. But in my opinion, when you involve the observer, you must have given the observer a certain function. If we only know what I deleted is a componentInstance and the definition , the observer’s design would not be very meaningful.
The only workaround is likely a combination of:
(1) Cache the persistent IDs of the instances, in say an attribute dictionary attached to the definition object, and then in the deleted callback you’d iterate the definition’s instances collection finding the ID that has no instance.
dict = definition.attribute_dictionary(ID_CACHE)
# Assuming dictionary has peristent_id keys:
deleted_id = dict.keys.find do |key|
definition.instances.none? { |inst| inst.persistent_id == key }
end
# Do something with the deleted_id ...
# then remove that deleted_id from the cache:
dict.delete_key(deleted_id)
… and (2) store important data at a higher level (rather than attached to the individual instances.)
The attribute dictionary shown above can be a nice place “higher” than the instance to store the data since it will exist until the definition no longer has instances and is purged from the DefinitionList collection.
An alternative, is to store persistent data even “higher” attached to either the DefinitionList collection or the model itself.
Just make sure that your dictionary names are uniquified by prefixing with your author namespace name and extension name.
Yeah, you’re right. Your ideas have indeed given me great inspiration.
I think there is some kind of read only state used by the Overlays API but I don’t know the details there.