Tony,
Thank you for that insightful explanation! I see now how my apparent solution only suited the case of COPY vs PASTECLIP, and since it was only applying the overrule to non transaction resident objects it would not apply to any of my own routines which religiously use the transaction model. This also reminds me of my recent discovery (Thank you Owen and Jeff!) that my vertical product wraps a transaction around my commands and the particular behavior
Noticing that when we perform PASTECLIP the object is transaction resident during the jig, and when we insert the object a new instance is created which is non transaction resident raises a couple questions for me:
-Is the transaction mechanism being used here as an easy way to undo the underlying BlockTableRecord cloning that must occur in the background for a new block definition to be inserted into the database in the event the user cancels the operation?
Probably yes, since there's no other simple way to roll back the insertion of the external file.
-Is the reason driving COPY command functioning outside of a transaction an artifact of older functionality, while PASTECLIP being a newer function is handled by newer methods?
I suppose it could be, but I can't give you a definitive answer. There may also be an internal form of transaction that can't be seen from the API that could be in use. Or it could be as simple as using UNDO/Begin and UNDO/End like most LISP scripting does to achieve the same kind of transactional behavior.
When you mention using dictionaries to sort this out I'm picturing the dictionary call not being a part of the Close() override, but rather a document level event handler which would switch the affected DB and manage the respective properties for each document (seed value, database, tag, etc.) when the current document is changing, and changing those values handled by the Close() method to suit. Is this how you would handle it?
No. Changes can be made to any open database, without it having to be active. So, an overrule needs to be prepared to deal with objects from any database, regardless of whether the database is the active database or not. The easiest way to do that is to use a Dictionary<Database, T> where T is the database-specific data, or some class that contains it, and just lookup the entry on each call. There's some overhead there, but not nearly as much as there is for multiple overrules, each servicing only one database.
I never would have anticipated this one small situation posing this significant of a problem! A$C is also the prefix of any dynamic block which has modified properties. The only definitive way I can think of at this point to determine if this is a PASTECLIP operation would be to see if that was the running command. There must be a simpler way...
A$C isn't the prefix of dynamic blocks with modified properties. Those are anonymous blocks matching the pattern "*Unnn". Although it may be the name that an XREF-BIND operation gives to blocks, that still shouldn't be a problem since the BlockName property of the AttributeReference is not the name of the block containing the attribute, it's the name of the block which the block containing the attribute is inserted into. IOW, it will almost always be the name of the model space or a paper space block.
I tried the code on both regular and dynamic blocks, and it seems to work fine here.
