Topic: Make a block un-purgable?

[Lee Mac]

Try to purge this.

The layer is referenced by the dimension arrowhead block so it obviously won't be purged 

[nobody]

This is interesting... in a way it would provide a means to permanently stamp a drawing to the owner. Kinda cool.

[kruuger]

all above can be 'killed' by LAYDEL
k.

[roy_043]

You can add a entry to the NamedObjectDictionary, or the ExtensionDictionary of ModelSpace, etc..(Something that will always be in a drawing and never removed like ModelSpace) with the ObjectId of the BlockTableRecord and with a HardPointerObjectId typecode(340).

This can also be done through Lisp. Example (without error checking):

Code - Auto/Visual Lisp: [Select]

1. ; (TestExtDict (car (entsel)) "Circ")
2. (defun TestExtDict (enameToConnectTo blockName / )
3.   (dictadd
4.     (vlax-vla-object->ename
5.       (vla-getextensiondictionary
6.         (vlax-ename->vla-object enameToConnectTo)
7.       )
8.     )
9.     "PurgePreventor"
10.     (entmakex
11.       (list
12.         '(0 . "XRECORD")
13.         '(100 . "AcDbXrecord")
14.         (cons
15.           340
16.           (vlax-vla-object->ename
17.             (vla-item
18.               (vla-get-blocks (vla-get-activedocument (vlax-get-acad-object)))
19.               blockName
20.             )
21.           )
22.         )
23.       )
24.     )
25.   )
26. )

I am interested in learning more about the 'Xdata' method as I can't get (my stab at) it to work.
I am attaching a .dwg file.
The drawing contains a block definition "Circ".
The block record of the block has Xdata attached.
There are two text entities:
1. One with an Xdata reference to the handle of the "Circ" block record.
2. The other with an extension dictionary created with the above code.

Text entity #2 functions as a purge preventor.
Text entity #1 does not.

[Marc'Antonio Alessi]

Try to purge this.

The layer is referenced by the dimension arrowhead block so it obviously won't be purged 

It is obvious only if dimension style name is STANDARD...

Better: only if dimension style name is the first entry in the dimension style dictionary.

[Pepe]

Don't know, maybe it should be like killing fleas with cannonballs (as we say in Spain), but... What about a persistent reactor that re-built the block after purging it... 

Regards.

[roy_043]

Don't know, maybe it should be like killing fleas with cannonballs (as we say in Spain), but... What about a persistent reactor that re-built the block after purging it... 

Regards.

It's an interesting thought, but for my needs it is indeed a canonball.
(And correctly restoring entities from elists can be tricky. I am thinking of associative dimensions and hatches and also of fields...)
The 'dictionary method' from my previous post actually works just fine.
I am however still interested in the 'Xdata method' since my application already relies on Xdata.

[irneb]

I think the "xdata" idea would be to place a Database-Handle (code 1005) in the xdata of something like Layer 0 / Model Space to point to the handle (code 5) of the block definition. But still, your xdata might be purgeable through registered apps.

[roy_043]

I think the "xdata" idea would be to place a Database-Handle (code 1005) in the xdata of something like Layer 0 / Model Space to point to the handle (code 5) of the block definition. But still, your xdata might be purgeable through registered apps.

I have done just that in the drawing attached to one of my previous posts. It may work in AutoCAD but it doesn't in BricsCAD.

[irneb]

Well, then you've got your answer. XD only works for this in AC, not BC.

Anyhow, what's the idea behind making your block un-purgeable? Is it some form of "copyright-watermark" you want to "embed" into the DWG? If so, even if you can get such working, what's to stop someone from copy-pasting the actual linework to another DWG without your "watermark"? Such copyright's never worked on anything inside of any software, no matter how hard the best people have tried - if someone wants to steal it they'll find a way to break the copyright. Take Sony's DVD's for example, arguably the "best" copyright protection in the entire DVD industry, yet nearly every DVD cloning software cracks that in an instant - Sony's fought for more than a decade now and they're still loosing the battle.

If it's simply a situation of you want a block always to be available, then make a wblock of it into a folder on your support paths. That way if you wish to insert it, acad/bc would simply find the file and load it in as a block. You'd not even notice that this happens, so no need for anyone to do anything different than they're doing already. Not to mention, if you need to update the block later - a simple wblock overwriting the old DWG file would be all that was needed.

Sorry, but that's the only 2 reasons I can see that anyone would want to make a block non-purgeable. IMO neither reason is good enough to go through all this hassle and probably causing issues later on (as suggested by dgorsman) like bloat going into your DWG after some time of using such. Perhaps you've some other reason which I can't imagine at this time though.

[roy_043]

If you look at block definitions as (source) containers for (geometrical) data there can be good reasons for making such definitions unpurgable in certain contexts (read: as long as their target entities are in the drawing). I believe AutoCAD's dynamic block implementation uses a form of purge prevention.

I am however surprised that gc 1005 can work:

http://exchange.autodesk.com/autocad/enu/online-help/browse#WS1a9193826455f5ff18cb41610ec0a2e719-7946.htm
1005 xdata group codes have the same behavior and semantics as soft pointers

http://exchange.autodesk.com/autocad/enu/online-help/browse#WS1a9193826455f5ff18cb41610ec0a2e719-7948.htm
Hard references, whether they are pointer or owner, protect an object from being purged. Soft references do not.

[irneb]

If you look at block definitions as (source) containers for (geometrical) data there can be good reasons for making such definitions unpurgable in certain contexts (read: as long as their target entities are in the drawing). I believe AutoCAD's dynamic block implementation uses a form of purge prevention.

Well, in such case I'd advise you use dictionaries attached to those target entities which include "hard pointers" to the block definition (as you've noted the xdata only provides soft pointers). This would be similar (if not exactly the same) as adesk has done for dynamic blocks.

The benefit of this would be that even copy-pasting one target entity to a new drawing, should take the block definition with it. So you shouldn't need to re-run your code on the new DWG to have it "locked" in there as well.

[TimSpangler]

That is exactly what I was thinking.  Insert @ 0,0 scale to a minute scale on layer "defpoints" then make it invisible.

make it invisible

Ugh, please NO.  Along with making the block attribute only with the attributes hidden, or making it dynamic with a visibility state with all graphics turned off, blocks that cannot be found follow the "out of sight, out of mind" principle.  They accumulate and before you know it, your drawings (and blocks) have thousands of inserts.

Isn't that the point?  This is what the OP was asking for, No?


I would also have a "cleanup" routine to rid a drawing of all of that type of stuff as well.  Part of our cleanup makes everything "invisible", visible again.