Hey TT
"Well, I'm sure everyone would agree that using Open() and Close() (or Dispose) that way is going to become a problem if the code fails, so I guess it's about how one approaches the problem, and whether they plan for failure or always think about what'll happen in the event of a failure, or maybe they're the type that blissfully presumes that their code can't fail, and so they don't have to worry about what happens (e.g., what state the drawing is left in) if it does.
"
I don't agree, the using statement's Dispose is automatically called even when an exception is thrown. Also, there is a Cancel() method on an Opened entity which undoes the changes. This is the same function that a a StartOpenCloseTransaction.Abort() calls.
"The OpenCloseTransaction was originally a kludge that was implemented entirely in managed code (it simply cached the managed wrappers it previously created in a Dictionary, keyed to their ObjectIds, and returned them when you called GetObject()). The reason it was created was because the code that scanned the current selection to update the ribbon was taking way too long. Subsequently, the OpenCloseTransaction was reimplemented in native code, but was still not integrated into the transaction management system."
Hmm you must be listening at my office door or something?
The reason that OpenCloseTransaction was implemented was not because of what you say at all, where did you hear that!? The reason we implemented it was because StartTransaction() cannot be used in Event callbacks without great care being taken, also, it's slower than Open/Close. Therefore, so as not to break the transaction model that all have adopted, we wrapped Open/Close in the "transaction" model to give StartOpenCloseTransaction.
"That may be true for relatively-simple command implementations that are 'self-contained' and have no dependence on other shared/reusable code libraries. However, if you do make use of shared/reusable code libraries as do I, then you'll almost certainly have a much bigger mess on your hands. For example, if you use helper classes with methods that currently call ObjectId.GetObject() or TransactionManager.GetObject(), they will have to be completely refactored to take a Transaction as a parameter, because Autodesk didn't seem to think there was any need for a means to access a currently-active OpenCloseTransaction through a Database."
If you using a transaction inside of your library/helper functions, personally, I would never do that, I'd absolutely use Open/Close or StartOpenCloseTransaction in a self contained way. First of all, it's faster, second of all it's not relying on external components being setup, and third it will work in all contexts making it more portable and, less susceptible to change (like TT found).
Kerry, the messages you see when using Open/Close when you compile - quick history lesson - originally, VB.NET did not have a using statement so we adopted the Transaction model for all .NET code and marked Open/Close as Deprecated/Obsolete. Later on, .NET developers became more and more advanced eventually finding the various issues that using raw Transactions brings (slower, cannot be used in Events, cannot be used with HandOverTo, etc etc) so we removed the Deprecated text on Open/Close and made it 'for advanced use only' (hmmm, looks like we accidentally missed a few, sorry about that). We didn't want to make people change their code, so we implemented the OpenCloseTransaction in a Transaction way. It's true you can't use ObjectId.GetObject() by why would you do that when it's not actually using raw Transactions.
One last point, if you call OpenCloseTransaction.Abort() it rolls back any changes by calling the Open/Close Object.Cancel() function - it works almost exactly the same as a raw Transaction under normal circumstances - "Golden Delicious Apple" vs "Granny Smith Apple"?!
"Apples-Oranges"
Yes, Apples-Oranges - but they are still both fruit are they not!!?
Guys, I'm not on here to confuse you all, I want you to succeed - that's my job!!! I think I have been very clear what the differences are between open/close, normal transactions and openclosetransactions. I have also been very clear about when to use Dispose() (I recommend that if you are not sure then, Dispose "always!!!") If you have any specific questions, then why not post them to our AutoCAD .NET forum
http://forums.autodesk.com/t5/NET/bd-p/152 - my team are monitoring those much more closely now and we'll be glad to help you guys.