Hi Dave, I'm not sure if I answered this question:
quote:
Finally, another question I have is whether factory methods can only work on 'committed' geometry, or can they also work on any valid geometry passed to them. I've been assuming they can work on any geometry, but would like to have that point clarified.
But I may need some clarification - which factory methods are you referring to here, do you mean a custom method that a particular factory implements like those special ones on Trim, or do you mean one of the regular methods common to all factories?
So one thing to note is that geometry itself does not really have a "committed" state, it's actually the factory that has that state.
When a factory is being used in an interactive command, the newly created geometry (created during a call to .update() ) is actually added to the geometry database as well, otherwise it would not show up on the screen. But when you do a factory.commit(), it then knows not to remove that geometry during the cleanup stages when a command exits, otherwise that geometry is removed if a factory is torn down before a commit() happened.
If you do a factory.calculate(), then that generates a list of output objects but does not process them in any of the other ways that happen during the normal interactive update/commit/cancel type stuff. That's so you could potentially use those objects for other intermediate calculations instead of forcing them to be displayed on the screen.
So the results of .calculate() are not added automatically to the geometry database. But you should be able to use them for inputs into other factories, however if you need them to be selected and show up in the geometry database you will need to add them to the geometry database yourself.
Geometry does have a flag for whether it is "in the database" or not in the database list, but that's a different thing than a factory's committed state.
- Michael
