eLockViolation (ObjectARX 2015)

[joaoljr]

I'm having an issue with the code below:

AcAxDocLock acDoc;
Acad::ErrorStatus lockEs = acDoc.lockStatus();
AcDbObjectId objId;
acdbGetObjectId(objId, acEntity);
Acad::ErrorStatus openEs = acdbOpenObject(pEnt, objId, AcDb::kForWrite);

When I debug this, I see that lockEs is set to Acad::eOk, but openEs is set to Acad::eLockViolation.

Now, if I tried this variant:

AcApDocument* pDoc = acDocManager->curDocument();
acDocManager->lockDocument(pDoc, AcAp::kAutoWrite, NULL, NULL, false);
AcDbObjectId objId;
acdbGetObjectId(objId, acEntity);
Acad::ErrorStatus openEs = acdbOpenObject(pEnt, objId, AcDb::kForWrite);

The acdbOpenObject() call woked just fine, i.e., openEs is set to Acad::eOk!

Is that a bug in Autocad 2015? Or is there anything that could cause an eLockViolation when opening an object for write other than an unlocked document? Note that I have already confirmed that the current and active documents are the the same. Also, using kProtectedAutoWrite won't do the trick.

Thanks,

Joao

[artc2]

The first one locks the AcDbHostApplicationServices::workingDatabase, whereas the second one locks the current document's database. They should be the same, but if something has changed the workingDatabase, it is possible for them not to be the same.

[maisoui]

And AcAxDocLock is for COM wrapper (doc -> This class provides document locking for custom objects that implement COM wrappers.). If you are coding into an ARX, you have to use the second one.

Regards,

[Anodl]

Hi Joao,

try this

AcDbObjectId objId;
acdbGetObjectId(objId, acEntity);
AcAxDocLock acDoc(objId);
Acad::ErrorStatus lockEs = acDoc.lockStatus();
Acad::ErrorStatus openEs = acdbOpenObject(pEnt, objId, AcDb::kForWrite);

Arnold

[joaoljr]

Hi Arnold

That did not work either... strange enough, I found the problem can be reproduced when the command is launched from a menu bar option, but not when I directly type it or use a toolbar button. The application is using the document and command reactors to execute some other complex logic in parallel, so that could be causing some interference. I tried to isolate the test code above on a small ARX and load just that, but the issue did not reproduce.

As I mentioned in the original post, the curious thing here is that the document lock operation is always succesfull, but somehow the eLockViolation is still returned sometimes. so it seems something else is causing that...

Regards,

Joao

[tbrammer]

Hi joaoljr,

did you check artc2's idea? Is your acdbHostApplicationServices()->workingDatabase()  the same as the

acDocManager->curDocument()->database() ?

Otherwise you're successfully locking a different AcDbDatabase that the one you try to open from. That would explain it.

@maisoui:  You wrote "AcAxDocLock is for COM wrapper"

Yes, that's what the docs say. But I think it's usage is not limited to COM wrappers.

We have a lot functions that modify the current DB that are called from modeless dialogs. So we need locking to avoid lock violations.

We always do this with an  AcAxDocLock lock;  - and it works fine.

I have to admit that we didn't try AutoCAD 2015 yet. I hope it doesn't make a difference...

Cheers

--Thomas