Here is the exact code with a couple of additions I tried.


-Added a event handler for ObjectClosed.
-Added after first Transaction

ed.WriteMessage("\n" + ad.UnmanagedObject.ToString());
ed.WriteMessage("\n" + ad.IsDisposed.ToString());
ed.WriteMessage("\n" + ad.Tag);
//ad.LockPositionInBlock = true;///// Boom


Notice how checking IsDisposed works because just checking managed wrappers properties


Checking its Tag property works.
AcDbAttribute::tag

This function returns a pointer to a copy of the tag string for the attribute. The tag string is the identifier you see if you explode the AcDbBlockReference that owns the attribute, so that the attribute reverts back to the AcDbAttributeDefinition that was part of the original reference's block definition.
The caller of this function is responsible for deallocating the memory used by the returned string. The acutDelString() global function should be used for this purpose.
The tag string is used for DXF group code 2.

Notice it is just using the Intptr for its address to marshal back a string.


Now ad.LockPositionInBlock will go boom since it tries to modify the object.


The line ad.Erase is where it goes booms but can be fixed with adding
tr.GetObject(ad.ObjectId, OpenMode.ForWrite); or ad.ObjectId.Open()


The word Dispose gets used and thrown around alot and usually is understood as releasing unmanaged memory, but I think it is a big NoNo to delete a object in ObjectARX and just call Close because they keep the objects in memory.
So it might better to think of Dispose and Transactions as just opening and closing objects instead of memory management.


So from what I can tell is Clone and other methods work because they just use the address(GetImpObj, DisposableWrapper.UnmanagedObject) to go get some information and marshal it back to you.


Erase is trying to modify an object and there is where I get a BOOM!


Also the ObjectClosed event fires for me during Commit as the code below shows some message boxes.

Thanks for that, I didn't know how to use the ObjectClosed event before this example...

I put your code into my compiler and didn't do anything aside from changing line 109 so it would compile, uncommenting line 47 where you lock the position in the block, and commenting out line and 70 where you reopen ad for write. Everything worked...  What version are you using?? Any add ons?

changed line 109 to:

Editor output after running:
Command: TRANSACTIONTESTING

Select attribute to add:  (BTW I never thought to simply check ad.IsDisposed)
Nothing Selected.

Select attribute to add:
Select block to append attribute:
693813248
False
MYTAGRegenerating model.
Regenerating model.


I'm even more confused at this point, I've read through the ARX documentation and everything there seems to agree with what you're telling me but it's not what I'm seeing

2013 Vanilla flavour but this machine Design Suite(MEP, Revit, and crap like SkecthBook Designer that f**ks up all your dynamic blocks with wipeouts being stretched--sotty for the rant)

I thought a ObjectId or using the UnmanagedObject property would be valid until its database is destroyed which it is not ,but how your getting around not closing it or modifying it without opening it, I have no idea.


Does the ObjectClosed Event fire?


Wonder if OpenedForModify event fires before you erase it.


I really do not know,
Speaking of dispose earlier and to add another point I have code that plays different fart sounds for dispose.
A  loud, hard, quick trumpet sounding fart for when I explicitly call dispose on it, and a long slow squeaker if called in Finalization method
Which makes complete sense to me so it goes to show they could be doing anything they want in Dispose call.

Hugo, Jeff,

What version are you using?  I'm trying to wrap my head around why things are working here if they object is apparently closed with the transaction .  If this is something version dependent then my code will be failing on different versions of AutoCAD... I can see how it would make logical sense that as the transaction was disposed the objects opened for write would be downgraded to read only to prevent any modification later.  Can anybody explain what is going on here?

Cheers

Only the outer-most transaction actually closes an object (or cancels it if the transaction is aborted). Inner or nested transactions are only markers that tell the transactionmanager what objects belong to what transactions. If you open an object for write in a transaction, the object stays open for write until the outer-most transaction is comitted or aborted. You will find that objects that are opened for read may still be usable after the outer-most transaction they were opened in has ended, but that is undocumented behavior that should never be relied on.

So that said, me experiencing objects which are still writable after a transaction is an anomaly that shouldn't happen   :blank:
I'm going to try to figure out why this is happening... I have written several functions that use this methodology...

How does that translate to your GetObjects extension method or the standard ObjectId.GetObject method? Do I need to use those inside a transaction to increase the stability of my code on different platforms?

So that said, me experiencing objects which are still writable after a transaction is an anomaly that shouldn't happen   :blank:

I don't think you understood Tony's explanation. If you modify a database resident object, and AutoCAD does not close with a fatal error, then the object is open, period. Either it was opened directly, or it belongs to an open transaction. It sounds like the latter in your case. It doesn't have to be a transaction that your code started. You're probably using a vertical that starts a transaction every time a command executes. If you are, your code will fail in vanilla AutoCAD.

Thanks for explicitly pointing out some versions will create a transaction implicitly... I was going to try to add an event to top transaction being opened and closed and see if that happens at the start and end of every routine.

In our office we run mechanical 2012 and also CADWORX on regular autocad 2012

So that said, me experiencing objects which are still writable after a transaction is an anomaly that shouldn't happen   :blank:
I'm going to try to figure out why this is happening... I have written several functions that use this methodology...

I didn't say writeable, I said that objects that were opened for read can still be accessed after the outer-most transaction they were opened in has ended. As far as I know, if an object was obtained from a transaction using OpenMode.ForWrite, the transaction will close the object when it ends (the outer-most transaction, that is), and you shouldn't be able to modify any object after that happens.

How does that translate to your GetObjects extension method or the standard ObjectId.GetObject method? Do I need to use those inside a transaction to increase the stability of my code on different platforms?

Use those as opposed to ..... ?