Model attributes and importing
-
I'm using the model's attribute dictionary to store some large xml data which is then referenced throughout the rest of the model's entities.
I'm wondering if there's a right way to access the model's attribute dictionary during the import process? I'd like to be able to save out a .skp file that fully attributed, and then import that into a new file, and be able to merge the attribute dictionary for the saved out .skp file into the model for new file.
Is there a way to do this?
Thanks,
Josh -
What have you tried?
If you wrote attributes to a model (Model A) - saved it. Then created a new model (Model B) and imported it the attributes from (Model B) is stored in the definition of the imported model. It's a rather easy process - so I wonder what the reason for the question is. You had errors, or you did not know where to find the imported attributes?
[off:3kzplvyw]Since you say you store a large XML data I'd recommend you clear the imported XML data after you merge in order to keep model file-size down.[/off:3kzplvyw]
-
Was the question how to detect when a model is imported?
-
Sorry if I wasn't clear.
So, I'm first creating model A and setting attributes on it, using Sketchup.active_model.set_attribute. Then I'll save this out.
Then I'll create a new model, model B, and import model A's .skp file into it. Sketchup.active_model therefore returns B after the import.
I've got entities in the new model that reference data in the model A's attribute_dictionary.
What I'd like to do is somehow, during the import process, merge model A's attribute_dictionary into model B's.
To add a little background, the XML chunks are used to define metadata for individual entities. Many entities share common metadata so what I've done is create a model level database to store the actual XML and then just have the individual entities store an index. This dramatically cut down the .skp file size.
The only issue that I'm having now is with the import. One thing that I thought about doing was instead of storing the database at the model level, just create another dedicated entity to store it, that way it would always be available after import.
Hope that made sense... Thanks for your help!
Josh -
How is it imported? Via the user doing File > Import? Or via your plugin using
Sketchup.active_model.import
? If the latter then it's easier - as you know exactly when the new model is added.
But in any case - when you import a model there will be a newComponentDefinition
in yourmodel.definitions
list which is your imported model. You then read your attributes from this definition. -
Thanks thomthom! That is exactly what I needed to know!
Right now users are just going through the SketchUp GUI File, Import to do their work. I'm going to look at the observers, perhaps DefinitionsObserver.onComponentAdded to see if I can do my merging there.
Thanks again!
Josh -
@joshb said:
Thanks thomthom! That is exactly what I needed to know!
Right now users are just going through the SketchUp GUI File, Import to do their work. I'm going to look at the observers, perhaps DefinitionsObserver.onComponentAdded to see if I can do my merging there.
Thanks again!
JoshBeware! UI import is not the only thing that might import a model. If you react to an observer event you can crash SketchUp. You may also interfere with some other operation.
Setting attributes is something that can be undone. And starting an operation in the middle of another one will interfer and break the first one. So if you react to an observer event and modify anything - you might break the undo-stack, you might break an operation of another plugin or native function - or you might even crash SketchUp.
My recommendation for observers is to only read data. If you need to react with model changes, cache it for a later time when you know it's safe to modify your model. For instance, you detect a model import, you cache what definition that was and wait with the merge until your plugin need to access any of your data.Another thing: be very careful what your observers do. Make them do as little as possible. Events can trigger in the thousands in some scenarios and then it doesn't take much to bog down a model.
Refer to this list of observer issues which I've been trying to chart: http://www.thomthom.net/software/sketchup/observers/
Advertisement