edit NOD entry

edit NOD entry

alex_b
Advocate Advocate
768 Views
10 Replies
Message 1 of 11

edit NOD entry

alex_b
Advocate
Advocate
Hi
I am using NOD to store program data:
NOD = Key = Subkey + AcDbObject -derived class.
All is well, but when I try to modify some of the class member values, after Save. Open, the class is gone from the dictionary and I get eWasPermanentlyErased.
Can somebody point me to an example of editing the data stored in NOD, please?
TIA

alex
0 Likes
769 Views
10 Replies
Replies (10)
Message 2 of 11

alex_b
Advocate
Advocate
Nobody done this before?
Maybe the Autodesk people?

Thanks

alex
0 Likes
Message 3 of 11

Anonymous
Not applicable
It sounds like one of the dictionaries (either the NOD or your sub-dictionary) is treating its elements as soft, which is the default. Are you calling AcDbDictionary::setTreatElementsAsHard(true) on all the dictionaries in the chain?

Andy F.
0 Likes
Message 4 of 11

alex_b
Advocate
Advocate
Yes, I am.
Maybe something else is wrong.
Could you look at the attached code excerpt?

Thanks

alex
0 Likes
Message 5 of 11

Anonymous
Not applicable
else if (es == Acad::eKeyNotFound) {
pDict = new AcDbDictionary;
AcDbObjectId DictId;
es = pNamedobj->setAt(ProgName, pDict, DictId);

/////////////////////////////
// Did you mean to set pNamedobj as hard here instead of pDict?
///////////////////////////
pDict->setTreatElementsAsHard(Adesk::kTrue);
pNamedobj->close();

AcDbObjectId rId;
es = pDict->setAt(SingleObjName, pConfigData, rId);//append the object
if (es != Acad::eOk) {//did not succeed:
pDict->close();
return es;
}
else {//create did succeed
pConfigData->close();
pDict->setTreatElementsAsHard(Adesk::kTrue);
pDict->close();
}
return Acad::eOk;
}//if eKeyNotFound

----------------------------

I see pDict being set to treat its elements as hard twice with no similar call on the NOD.
0 Likes
Message 6 of 11

alex_b
Advocate
Advocate
Andy
It's not that. I tried it and I still get eWasPermanentlyErased when trying to read the dictionary after performing a Save followed by an Open.
Actually, when opening the saved drawing, I get a Autocad message as:
Warning. One error was found during open. .....
When Recovering the drawing we get:
....
Reading handle 7F object type XElConfig
Error 67 (eDwgObjectImproperlyRead) Object discarded

Auditing Header

Auditing Tables

Auditing Entities Pass 1

Pass 1 100 objects audited
Auditing Entities Pass 2

AcDbDimStyleTableRecord: "ISO-25" Not in Table Added
Pass 2 100 objects auditedAcDbDictionary(7E)
XEl_CONFIG ePermanentlyErased Delete Entry

Auditing Blocks
.....
It seems that something is written-out/read-in incorrectly by dwgOut/InFields(), but in the debugger everything returns Acad::eOk.
Any ideas?
I attach dwgOutFields/dwgInFields code, as well as the config class member variables declarations.
Thank you

alex
0 Likes
Message 7 of 11

Anonymous
Not applicable
Hi,alexb.
I just came up with the same problem as yours. My AcDbObject derived custom object was stored in an extension dictionary. After i mofied some value and then save and close it, it would be gone and i would receive ePermanentlyErased when i reopen the file.
Have you fixed it yet? Message was edited by: xiehui.luo
0 Likes
Message 8 of 11

alex_b
Advocate
Advocate
Yes . The fix I came up with was never modify the in-dictionary object.
Instead, remove() the old object (this removes the key as well) instantiate a new object and create the dictionary entry anew, key and all.
It works for me 🙂
Maybe the Autodesk people will tell us why the
modify-in-place method won't work.

alex
0 Likes
Message 9 of 11

Anonymous
Not applicable
Yes it also works for me. But now i am looking for another way to get around this.
Have you ever tried the AcDbXRecord object? Before i revise my code to store my app data in the custom object, i stored them in some XRecord objects which resident also in the extension dictionary. They worked all right regardless of my modify,save,close and reopen operations.
Maybe i will tried to derived it from XRecord object instead.

We are doing the same thing as you mentioned int post "What the dictionary can store".
0 Likes
Message 10 of 11

alex_b
Advocate
Advocate
I am probably content with the way it works, so I wouldn't look at AcDbXrecord for this item, but see my post dwgInFields from July 4 for what seems to be a (hopefuly solvable) glitch.
And BTW, happy 4th July to our American friends.

alex
0 Likes
Message 11 of 11

Anonymous
Not applicable
Hi, alexb,I'm sure you must have done something wrong.
I am doing exactly what you are trying to achieve, and at the beginning i came up with the same problem as yours. Then I create another class derived from AcDbObject it worked all right just like the built-in AcDbXRecord, and no eWasPermanentlyErased was received. After that i succeeded to create several other AcDbObject custom class which also resident in the NOD, and they all worked fine.
So i am pretty sure we had made some mistake, but the problem is i can't find out what the mistake was.
0 Likes