Hi Dave,
> I hope you don't mind if I use bits and pieces of your
> explanation in the API documentation I am writing?
Sure, feel free to use it!
> The bit about the binders automatically calling 'update'
> helps clarify how the binders operate quite a bit <...>
Also I should mention that there are a few of varieties of binders, there is one that goes on HTML elements in the UI, which are set up with a bindingx="" attribute.
Then there's one that can be set up with moi.ui.bindUIToInput(), which hooks up a UI control to a factory input, and handles copying the control's value to the input and calling update() on the factory when the control's value has changed.
Also the point picker has its own binding methods where you can tell it to connect to a factory input, and when the pointpicker has a new point from a mouse move, it sends the point (or the point + cplane frame, or just the cplane frame) to the factory input and calls update().
quote:
- In order to be displayed on the screen, all geometry must be in the geometry database.
- It is possible to create, maintain and use geometry that is not displayed to the user (i.e. not in the geometry database).
- Factories can work with any geometry objects, whether or not they are in the geometry database.
Yup, that's all correct!
Or should be anyway - the last one should be correct but let me know if you run into instances with a particular command where it does not seem to work properly. One thing is that objects do not get their ID guid assigned to them until they are added into the geometry database. So it could be possible that something is sensitive to that, but it is not supposed to be.
> Now, the big question: when/how are geometry objects destroyed?
They are reference counted just like you suspected.
So you never really explicitly destroy it, but if you remove it from any list that was holding a reference to it, your script will then hold the last reference and the object will be destroyed when your script itself gets garbage collected or terminated.
> Based upon this assumption, adding geometry to the geometry
> database automatically keeps geometry alive, because it become
> part of one or more lists that the database manages.
Yup, that's correct - the geometry database list holds a reference count open on the objects in it.
> Sub-objects are kept alive by lists maintained by parent objects.
Yup.
> Geometry that is not in the database is kept alive by being part of
> one or more ObjectLists maintained outside of the database.
Yup, or you can also have an individual object all by itself referenced by script - the script engine itself will keep an open reference count on the object in that case.
> Destruction of geometry not in the database can be accomplished
> by the removal of the geometry objects from all ObjectLists being
> maintained by a script (talking from a scripting perspective).
Yup, the object itself will be destroyed when the last reference is released.
- Michael
