If I am writing a library of tools to draw things, that library may be used from modal or modeless forms.
I would not want to put the document locking in the library, or would I?
Should I just be safe and always lock the document before drawing something?
Should I add a "running from modeless" param to every function to allow locking?
Its tricky because if I don't put in library, the tools that call the library must know when to lock.
Its obvious sometimes, but not always. Any advice on structuring this?
Yes, you need locking if you modify items within a loaded document.
No, you don't need locking if the command itself has the attribtue for locking/exclusive access.
No, you don't need locking if you are just reading some objects from your loaded document
No, you don't need locking if you modify some objects in a database (not loaded) in editor.
And the last point is the decission (at least for me) to not do a lock in every lib-function as in most function calls I transfer an objectid or an entity or a database as parameter, but never the document .... as I want my lib also working on just db-objects (and not loaded as documents).
I do the locking (and some init-sequence for a global error-handler/-messaging system) at the very early start of a function and the .dispose of it at the end.
- alfred -
thx for reply.
It seems odd to me, so far, that we must deal with locking.
I would expect that when we attempt to modify the database, it tries to lock it automatically.
I think what you mentioned about running on a database not open in the editor is the key.
You need a way to stop the regular interaction of the UI with a loaded drawing to draw stuff.
Seems like that could be handled in the background too though.
I have not seen enough examples that take advantage of not locking the document to see why its left up to us.
Any obvious reasons that come to mind?
Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register