lock document always?

[JamesMaeding]

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?

[Alfred.NESWADBA]

Hi,

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.

my 2c

- alfred -

[JamesMaeding]

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?

thx