.NET
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

when is erased really erased?

8 REPLIES 8
Reply
Message 1 of 9
Anonymous
410 Views, 8 Replies

when is erased really erased?

In some code Im porting from Arx to .Net I have one class
whos purpose is:
1. Get a list of attributes for a revision block.
2. If there are not 6 attribute defs for the block, consider it bogus
3. If there is a bogus block def, delete it and any references to it.
4. If there is NO block def (or we deleted it), create a new block definition
with attributes.
5. Insert a block REF into current paper space.

This all works fine in my Arx version, but I hit a snag in the .Net version.
If I delete a "bogus" block definition, then create a "good" one, all is well
at this point. However, as soon as I try to open the new definition to iterate its
attributes I get an eWasErased exception. Even if I wrap the accessing code in a
"if blocktableHAS" construct, which returns true, it still fails.
Im assuming here that after deleting the "bad" definition, a flag was set in
the blocktable saying this guy was erased, but when I recreated a definition with
the same name, this flag is not cleared. Or that the "transaction(getobject)" is
returning an erased record, rather than the record I just created.
The code works fine, on the other hand, if there was no "bad" definition erased
or it was a "good" defintion in the first place.
Is there some way around this behavior??

Thanks, Perry
8 REPLIES 8
Message 2 of 9
Anonymous
in reply to: Anonymous

This is a result of a bug in the API, where the default indexer
for the SymbolTable class (the base class of the BlockTable),
returns erased entries.

The only way around it in 2006, is to iterate the entire
table manually, open each entry that's not erased, and
then at the Name property.

This was addressed in 2007, BTW.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com

"perry" wrote in message news:5168680@discussion.autodesk.com...
In some code Im porting from Arx to .Net I have one class
whos purpose is:
1. Get a list of attributes for a revision block.
2. If there are not 6 attribute defs for the block, consider it bogus
3. If there is a bogus block def, delete it and any references to it.
4. If there is NO block def (or we deleted it), create a new block definition
with attributes.
5. Insert a block REF into current paper space.

This all works fine in my Arx version, but I hit a snag in the .Net version.
If I delete a "bogus" block definition, then create a "good" one, all is well
at this point. However, as soon as I try to open the new definition to iterate its
attributes I get an eWasErased exception. Even if I wrap the accessing code in a
"if blocktableHAS" construct, which returns true, it still fails.
Im assuming here that after deleting the "bad" definition, a flag was set in
the blocktable saying this guy was erased, but when I recreated a definition with
the same name, this flag is not cleared. Or that the "transaction(getobject)" is
returning an erased record, rather than the record I just created.
The code works fine, on the other hand, if there was no "bad" definition erased
or it was a "good" defintion in the first place.
Is there some way around this behavior??

Thanks, Perry
Message 3 of 9
Anonymous
in reply to: Anonymous

Tony Tanzillo wrote:
> This is a result of a bug in the API, where the default indexer
> for the SymbolTable class (the base class of the BlockTable),
> returns erased entries.
>
> The only way around it in 2006, is to iterate the entire
> table manually, open each entry that's not erased, and
> then at the Name property.
>
> This was addressed in 2007, BTW.
>
Glad they fixed it!
I thought about iterating the whole block table, but instead
how I got around it was just saving the ObjectId of the new
blockdef and opening it directly.
Perry
Message 4 of 9
Anonymous
in reply to: Anonymous

Tony Tanzillo wrote:
> This is a result of a bug in the API, where the default indexer
> for the SymbolTable class (the base class of the BlockTable),
> returns erased entries.
>
> The only way around it in 2006, is to iterate the entire
> table manually, open each entry that's not erased, and
> then at the Name property.
>
> This was addressed in 2007, BTW.

I tried the code in 2007 and am still getting erased records.
not sure yet if this function is returning erased records....
Btr = (BlockTableRecord)trans.GetObject(bt["MYNEWBLOCKDEF"], OpenMode.ForRead, false);
but I know this one is
if (bt.Has("MYNEWBLOCKDEF"))
and my code is hitting that first. This is a major hassle that didnt happen with Arx.
If I delete a block def, then recreate it, is there some way to tell the database to
update flags concerning erased records?
Has anyone made custom wrappers for the (pBlkTable->has()) pBlkTable->getAt() arx
functions?
Message 5 of 9
Anonymous
in reply to: Anonymous

Sorry, I was mistaken.

The issue is not fixed in R17. Perhaps they don't see it
as an issue, and if that's the case, I strongly disagree.

The change that was made was to the iterator, which
will skip erased records. You use the iterator when you
use foreach() on the symbol table.

It looks like they didn't fix it, but rather screwed it up
even more.

This kind of API design leaves me with serious questions
about Autodesk's sincerity with regards publicly consumable
APIs, and seems to be another aspect of the "looks good
on paper" mentality.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com

"perry" wrote in message news:5173604@discussion.autodesk.com...
Tony Tanzillo wrote:
> This is a result of a bug in the API, where the default indexer
> for the SymbolTable class (the base class of the BlockTable),
> returns erased entries.
>
> The only way around it in 2006, is to iterate the entire
> table manually, open each entry that's not erased, and
> then at the Name property.
>
> This was addressed in 2007, BTW.

I tried the code in 2007 and am still getting erased records.
not sure yet if this function is returning erased records....
Btr = (BlockTableRecord)trans.GetObject(bt["MYNEWBLOCKDEF"], OpenMode.ForRead, false);
but I know this one is
if (bt.Has("MYNEWBLOCKDEF"))
and my code is hitting that first. This is a major hassle that didnt happen with Arx.
If I delete a block def, then recreate it, is there some way to tell the database to
update flags concerning erased records?
Has anyone made custom wrappers for the (pBlkTable->has()) pBlkTable->getAt() arx
functions?
Message 6 of 9
Anonymous
in reply to: Anonymous

Tony Tanzillo wrote:
> Sorry, I was mistaken.
>
> The issue is not fixed in R17. Perhaps they don't see it
> as an issue, and if that's the case, I strongly disagree.
>
> The change that was made was to the iterator, which
> will skip erased records. You use the iterator when you
> use foreach() on the symbol table.
>
> It looks like they didn't fix it, but rather screwed it up
> even more.
>
> This kind of API design leaves me with serious questions
> about Autodesk's sincerity with regards publicly consumable
> APIs, and seems to be another aspect of the "looks good
> on paper" mentality.
>
I'd have to stongly agree with your disagreement.
The aformentioned code function I outlined earlier is not
something I do a lot of, but I want it to work when I do.
Its certainly an issue for me. Autodesk must be aware of this
and Im sure for their guru's, it would not be terribly difficult
to fix. They should issue a "hotfix" for this.
Makes me wonder what other functions in their net api
"just dont work", or if its even worth it to try any serious
development in .net.
Message 7 of 9
Anonymous
in reply to: Anonymous

I think you need to read my post again.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com

"perry" wrote in message news:5174667@discussion.autodesk.com...
Tony Tanzillo wrote:
> Sorry, I was mistaken.
>
> The issue is not fixed in R17. Perhaps they don't see it
> as an issue, and if that's the case, I strongly disagree.
>
> The change that was made was to the iterator, which
> will skip erased records. You use the iterator when you
> use foreach() on the symbol table.
>
> It looks like they didn't fix it, but rather screwed it up
> even more.
>
> This kind of API design leaves me with serious questions
> about Autodesk's sincerity with regards publicly consumable
> APIs, and seems to be another aspect of the "looks good
> on paper" mentality.
>
I'd have to stongly agree with your disagreement.
The aformentioned code function I outlined earlier is not
something I do a lot of, but I want it to work when I do.
Its certainly an issue for me. Autodesk must be aware of this
and Im sure for their guru's, it would not be terribly difficult
to fix. They should issue a "hotfix" for this.
Makes me wonder what other functions in their net api
"just dont work", or if its even worth it to try any serious
development in .net.
Message 8 of 9
Anonymous
in reply to: Anonymous

Tony:

> I think you need to read my post again.

Then he might agree even more strongly with your disagreement. 😉
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com
Message 9 of 9
Anonymous
in reply to: Anonymous

Oops. Right. It's I that's not reading or at least,
getting the dis-agreements messed up 🙂

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com

"Owen Wengerd" wrote in message news:5176020@discussion.autodesk.com...
Tony:

> I think you need to read my post again.

Then he might agree even more strongly with your disagreement. 😉
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report

”Boost