question about accessing the "Undo memory"

situation:
I erase all instances of a given block
I run the following deleteblock routine.(just a temp routine to demonstrate
the problem)

although no instances exist, the definition is still referenced

If i close and reopen the dwg the def is not referenced and it can be
purged(vla-delete)

My assumption is that the reference is contained in the "undo memory" or
whatever that is called.

Is there any way other than closing and reopening to selectively flush an
object from the "undo memory"?
probably not, just thought I'd ask

Thanks
Mark

--------------------------------------
printout on textscreen:
(after erasing all instances of block)
DELETEBLOCK

No inserts of PORCH-NORTH-BEAMS-PLAN exist in dwg
Failed to delete PORCH-NORTH-BEAMS-PLAN
Automation Error. Object is referenced

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

after closing and reopening
--------------------------------------

Command: deleteblock

No inserts of PORCH-NORTH-BEAMS-PLAN exist in dwg
Successfully deleted PORCH-NORTH-BEAMS-PLAN

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


here is the deleteblock routine.
the weird function names are just my toolbox versions - hopefully obvious
from the name what they do

(defun c:deleteblock()
(adcfLoadList
(list
'adcfGet-BlockDef
'adcfGet-ActiveDoc
))

(setq blkname "PORCH-NORTH-BEAMS-PLAN"
blkobj(adcfGet-BlockDef(adcfGet-ActiveDoc) blkname )
)

(setq blkset(ssget"x"(list(cons 2 blkname))))
(if(not blkset)
(progn
(princ(strcat "\nNo inserts of " blkname " exist in dwg"))
(if
(null
(vl-catch-all-error-p
(setq res
(vl-catch-all-apply
'vla-delete
(list blkobj)
)
)
)
);null
(princ(strcat"\nSuccessfully deleted " blkname))
(princ(strcat"\nFailed to delete " blkname "\n"
(vl-catch-all-error-message res)))
);if
);progn
(progn
(princ(strcat"\nFound " (itoa (sslength blkset)) " inserts of " blkname))
)
);if
(princ)
)

 

What version? I just tested this in 2002 and it worked as expected:

Command: deleteblock

Found 1 inserts of car

Command:
Command: e ERASE
Select objects: 1 found

Select objects:
Command: deleteblock

No inserts of car exist in dwg
Successfully deleted car

Command:

 

You are dealing with two separate things, one is the block insertion,
and the other is th block reference. The reference is a completely separate
item, so even if you erase all of the insertions, that does not delete the
reference from autocads block tables. Has nothing to do with the undo
buffer/memory. You can think of it this way: the reference stores all of
the entity information about the block, which takes up as much space as it
would to have drawn all of the things that compose it, as well as an entry
for the name of the reference; the insertion is just treated as a single
entity which calls back to the drawing with whatever name you told it that
it was supposed to be (this saves gobs of space since the reference is the
only object that has all of the drawn entities in it). As a defense
mechanism, autocad will not let you purge a reference, unless all of the
insertions who are calling to it are erased, otherwise you would have what
they call an "undefined" block, which can cause all kinds of problems.
Hope this explains how block references work in a drawing. External
references work on the same theory, but instead of the data about the
entities that make up the block being stored within the working drawing,
they are instead stored in an external drawing file, and then referenced in
upon loading of the working drawing.

 

With all due respect, the poster already fully understands
the difference between a block and a block reference. I
think you may not have understood the problem he's having.

He is trying to delete the block (definition) object, when
there are no references to the block found in any layout.

Normally, AutoCAD will allow a block object to be deleted
if there are no references to it, but in this case, it isn't.

 

Can you do a DXFOUT of the file, at the point where
attempting to delete the block fails? UNDO memory
should not affect this, because you could not undo
the erasure of any references before you undo the
deletion of the block.

However, if you suspect that this may not be the
case, then issue UNDO/Control/None followed by
UNDO/All, and that should cause AutoCAD to discard
undo information up to that point.

 

According to the routine he was using, it was only deleting the insertions
of the block only. So I explained why doing that still leaves the
reference. The routine does not attempt to remove the definition at all. I
drew my conclusions from that.

 

You might want to take another look at it.

The routine he posted doesn't delete any insertions
of the block, it only checks to see if there are any
insertions, and if there aren't, it deletes the block
(definition) object.

 

*BZZT* Wrong answer.......
The above gets the Block definition from the block table.
And the following attempts to delete it:

 

Sorry Tim,
I guess my function names aren't as self-explanatory as I thought they were.
(adcfGet-BlockDef(adcfGet-ActiveDoc) blkname )

returns the vla-object referring to the block definition in the block table
of the currently active document
the routine didn't actually erase any inserts
they were erased manually before running this routine
this temp routine was just demonstrating that even without insertions there
were references being held by acad.

You're right that often times beginners confuse block refs with block defs.
(Just happens that is one of the few things I do understand!)


Thanks for trying anyway.
Mark

 

2005
Thanks for checking


Mark

 

UNDO memory

ha!
good point
silly me
I just couldn't think of what else would hold onto the def.
I just tried it in a blank dwg, create simple block, erase, run routine,
deletes just fine.
but in 'real' dwgs that have been worked on for a while and where various
blocks have been created, i get the weird effect.
hmmmm...what could it be....
I'll try the dxfout next time i get one that won't delete.
What is that going to tell me?

 

my bad, mistook one of the functions, and got cornfused.

 

Thats the one i mistook, sorry guys.

 

OMG, I'm on a roll and can't get off!
(help it's a kaiser)

 

that what happens when you get old, and the eyes start deceiving you

 

I know that one too well, unfortunately

 

Could it be that the block you are trying to purge is a nested block in one of you others ones? Just and idea.

Tim

 

Good thought.
However, the fact that closing and reopening the dwg allows the delete
suggests that's not the case in this instance.
That's what originally made me think about the undo buffer...which t.t.
elegantly pointed out would not be the case either.

Thanks for giving it some thought.
Mark

one of you others ones? Just and idea.

 

The fact that you can reopen the drawing and purge
the block, would suggest that there is something in
the drawing that's referencing the block, and that is
being purged or discarded when drawing is saved,
and reopened.

For example, an unreferenced anonymous block that
contains an insertiion of the block that can't be
purged, will prevent you from deleting it, but when
AutoCAD saves/reopens the draiwng, it automatically
purges the unreferenced anonymous block, and the
block you want to purge then becomes unreferenced.

 

Hmmm.
Wonder what would have created an unreferenced anon block?
I can add a block def search for the block ref to make sure(in my goofy
little temp func).
....thinking out loud....would a foreach on the block collection catch anon
blocks?
I'll try...just never use anons for anything so not sure off hand.
Thanks for the ideas.
....back to the ...<computer>...drawing board

Mark