TheSwamp
Code Red => .NET => Topic started by: Nathan Taylor on August 23, 2006, 03:29:30 AM
-
I would like to purge a BlockTableRecord from the Database that has the IsErased property = True so I can create a new BlockTableRecord with the same name. Is it possible?
I may also have the same requirement with layers.
Regards - Nathan
-
You could try a 'save' as it wont write out the erased objects to the saved file and I think it reloads the current memory with that version. This is how the db handles objects (I think), it flags them as erased and at filing time it only files out what is not erased, I'm sure it also helps with the undo feature as well.
-
You could try a 'save' as it wont write out the erased objects to the saved file and I think it reloads the current memory with that version. This is how the db handles objects (I think), it flags them as erased and at filing time it only files out what is not erased, I'm sure it also helps with the undo feature as well.
Thanks Mick, I will give it shot although I would prefer another way.
Regards - Nathan
-
You could try a 'save' as it wont write out the erased objects to the saved file and I think it reloads the current memory with that version. This is how the db handles objects (I think), it flags them as erased and at filing time it only files out what is not erased, I'm sure it also helps with the undo feature as well.
Thanks Mick, I will give it shot although I would prefer another way.
Regards - Nathan
I ended up just taking the easy option. As the block is only a temporary item I am just adding the current time and date to the blockname.
-
no prob's, Glenn's pretty good with blocks, xref's etc. he may have some ideas or come across this problem before.
-
You should just be able to add the block again, as once something is erased, it's purgeable in this context. Have you thought of deleting everything from INSIDE the block table record as you recreating it anyway?
When you use the purge function, you pass it a list of objectids and the returned list is the ones you can safely erase...
Cheers,
Glenn.
-
told ya! :D
-
Actually, what I suggested probably won't work - I've come across this in symbol tables before and it has to do with the .NET implementaton.
I'll run some tests tomorrow to confirm.
-
You should just be able to add the block again, as once something is erased, it's purgeable in this context. Have you thought of deleting everything from INSIDE the block table record as you recreating it anyway?
When you use the purge function, you pass it a list of objectids and the returned list is the ones you can safely erase...
Cheers,
Glenn.
Thanks. I tried just adding it again but that does not work. Yes deleting everthing from inside the BTR is an option. The BTR IsErased property is set before I try to work on it.
I have a similar problem with layer table records and am just working around it by using the ActiveX API to add my layers. I will probably be about to hit the same problem with Textstyles so will probably use the same work around for that.
I am not too worried about resorting to using the ActiveX API as long I am still getting other benefits of the .NET API such as jigging.
Regards - Nathan
-
It has to do with the default indexer for symboltables.
Lets say you had this: LayerTable lt;
Now if you tried something like this: lt["SomeLayerName"] it will return the object even if it's erased.
In ARX it's like this: AcDbSymbolTable::getAt(string, bool) from memory. The bool flag is true to return erased records, false for not.
Unfortunately, the default indexer is using the version of "getAt" and passing true.
Autodesk should have built the default indexer for symboltables to take 2 arguments to match the 'getAt' function.
-
It has to do with the default indexer for symboltables.
Lets say you had this: LayerTable lt;
Now if you tried something like this: lt["SomeLayerName"] it will return the object even if it's erased.
In ARX it's like this: AcDbSymbolTable::getAt(string, bool) from memory. The bool flag is true to return erased records, false for not.
Unfortunately, the default indexer is using the version of "getAt" and passing true.
Autodesk should have built the default indexer for symboltables to take 2 arguments to match the 'getAt' function.
Thanks Glenn, I have revisited it and using Tony T's method of getting the non-erased record has resolved it.
Regards - Nathan