Can I start transactions inside the Application.Idle event without bothering the redo buffer?

[stefanome]

My addin creates some geometries and stores some metadata in the NOD.

If the user deletes the geometries, stale metadata remains in the NOD, so I have created an housekeeping event that ever 30 seconds checks for and deletes any stale data.

The checking for requires starting a transaction.

Most of the times there is nothing to delete and the transaction is aborted.

Sometimes there is something to delete and the transaction is committed.

It looks like the redo buffer is lost every time a transaction is started, regardless of whether the transaction is committed or not.

Is there a way to do some housekeeping that requires starting a transaction without resetting the redo buffer?

Here is how the event works:

public class MyAddin: IExtensionApplication
{
    public void Initialize()
    {
        Application.Idle += OnIdle;
    }
}

public static void OnIdle(object sender, EventArgs e)
{
    if (_dwg == null || !_dwg.Editor.IsQuiescent) return;
    if ((DateTime.Now - lastOnIdleExecution).TotalSeconds < 30) return;
    lastOnIdleExecution = DateTime.Now;

    // delete grid global properties entry for grids that have been deleted
    using var trans = Dwg.TransactionManager.StartTransaction();
    // check for stale data and delete+commit only if necessary
}

[daniel_cadext]

That’s kindof the whole idea behind transactions.

Transactions aren’t required, you can do things without using a transaction, you just have to manage disposing

Not sure if this exposed to .NET, but maybe you can toggle AcDbDatabase::disableUndoRecording

[stefanome]

---

@daniel_cadext wrote:

Transactions aren’t required, you can do things without using a transaction, you just have to manage disposing

Hmm... interesting.

Unfortunately I have a bunch of helper methods that rely on a transaction being there. They manage both a global dictionary and entity dictionaries, and the first time they are used they create the dictionaries.

So, in order to work without transaction, I will need to either get the OnIdle to not use those helper functions (which is the best way to create unmaintainable code and hit a wall of bugs the first time I modify those helper functions) or to add an optional WithoutTransaction argument to those functions (or to abort if the transaction doesn't exist and the dictionary is not found).

This will require some heavy refactoring of functions that are used everywhere, and right now I don't have the time for it.

Thank you for the pointer, I will keep it in mind when I will find the time to work on it.

For now I will modify the timer to do the cleanup once every 30 minutes.

[ActivistInvestor · Accepted solution]

So long as AutoCAD is in a quiescent state, I would expect that the code wouldn't screw-up undo, but it would most-likely result in the changes you make being treated as a separate undoable action, requiring the user to issue an extra 'U' to undo back to the point before the changes were made. You could try using an OpenCloseTransaction instead of a regular transaction to see if that has any effect, but your code would also have to lock the document.

This executes your code inside the handler of a registered command, but will also most-likely result in a separate UNDO group, but you can give it a try and test to see what happens:

public static void OnIdle(object sender, EventArgs e)
{
   if(_dwg == null || !_dwg.Editor.IsQuiescent) return;
   if((DateTime.Now - lastOnIdleExecution).TotalSeconds < 30) return;
   lastOnIdleExecution = DateTime.Now;
   var docs = Application.DocumentManager;
   docs.ExecuteInCommandContextAsync(unused =>
   {
      using(var tr = new OpenCloseTransaction())
      {
         // check for stale data and delete+commit only if necessary
         tr.Commit();
         return null;
      }
   }, null);
}

[stefanome]

Thank you for your pointer.

It's Friday night and I will try this on Monday.

---

@ActivistInvestor wrote:

So long as AutoCAD is in a quiescent state, I would expect that the code wouldn't screw-up undo

---

I just wanted to point our that the undo is not screwed up, it's the redo. But I imagine that you understood that, and you just shortened "undo/redo" into "undo".

[ActivistInvestor]

Yes, when I said undo I meant both undo and redo. And it is the latter of that usually gets messed up.

Regarding @daniel_cadext's comment, when you use an OpenCloseTransaction, you aren't using transactions. An OpenCloseTransaction really isn't a transaction in the same sense as that returned by StartTransaction().

It uses the open/close mechanism and so it just calls AcDbObject::close()/cancel() on each object from Commit()/Abort().

[daniel_cadext]

"which is the best way to create unmaintainable code and hit a wall of bugs the first time I modify those helper functions"

Yep, using onidle is a bit kludgy.  A better option might be to use events, or use ObjectOverrule to cleanup on erase

[ActivistInvestor]

---

@stefanome wrote:

---

@daniel_cadext wrote:

Transactions aren’t required, you can do things without using a transaction, you just have to manage disposing

Hmm... interesting.

Unfortunately I have a bunch of helper methods that rely on a transaction being there. They manage both a global dictionary and entity dictionaries, and the first time they are used they create the dictionaries.

So, in order to work without transaction, I will need to either get the OnIdle to not use those helper functions (which is the best way to create unmaintainable code and hit a wall of bugs the first time I modify those helper functions) or to add an optional WithoutTransaction argument to those functions (or to abort if the transaction doesn't exist and the dictionary is not found).

This will require some heavy refactoring of functions that are used everywhere, and right now I don't have the time for it.

You don't have to go through all of the refactoring.

As I explained above, an OpenCloseTransaction really isn't a transaction, so when you use that in place of the Transaction returned by StartTransaction(), you aren't using transactions at all. OpenCloseTransaction uses the  native equivalents of ObjectId.Open(), DBObject.Close() and DBObject.Cancel(), and was designed precisely for the situation you have, as it allows you to avoid using regular transactions that interfere with undo/redo.

[_gile]

---

@stefanome wrote:

---

Unfortunately I have a bunch of helper methods that rely on a transaction being there. They manage both a global dictionary and entity dictionaries, and the first time they are used they create the dictionaries.

[...]

This will require some heavy refactoring of functions that are used everywhere, and right now I don't have the time for it.

---

In addition to @daniel_cadext and @ActivistInvestor replies, if you use an OpenCloseTransaction, the refactoring would be passing this 'transaction' as argument to the hepler methods because it is not considered a 'TopTransaction'.

[stefanome]

All my commands (including the OnIdle event) start by using my EntityProperty class to check some global info stored in the drawing. Some commands will also generate new info, other commands (including the OnIdle event) will only read existing info.

Here is one of EntityProperty's members:

public static Dictionary<string, object> GetGlobalProperties(Document dwg)
{
    var dbDict = dwg.Database.GetNOD().GetOrCreateNamedDictionary(GlobalDictName);
    return DbDictionaryToDictionary(dbDict);
}

Here I call @_gile's very own Database.GetNOD, which calls ObjectId.GetObject, which calls Database.GetTopTransaction, which relies on a transaction.

Then, I call DBDictionary.GetOrCreateNamedDictionary, which again calls Database.GetTopTransaction.

I see one two-step approach, which includes some heavy refactoring:

1. Rewriting all Gilles' extensions and creating a read only version that doesn't use transactions

2. Adding the second readOnly argument too all the methods of my EntityProperty class, something like GetGlobalProperties(Document dwg, bool readOnly=false), and then, if readOnly==true, using the new readOnly extensions

Can you suggest a better approach?

I saw @daniel_cadext's suggestion: "use ObjectOverrule to cleanup on erase", but it feels wrong running some code every time any object in the drawing is erased. If the user deletes thousands of entities with one single click, I would run my checks thousands of times, and the checks could be slow.

Perhaps I could use the ObjectOverrule to set a global somethingHasBeenErased=true, then use the OnIdle to only do its job, including risking of breaking the redo buffer, only if somethingHasBeenErased==true?

[ActivistInvestor]

I generally make it a rule to avoid dependence on the top transaction. Most if not all of the methods I write that use transactions will take a transaction as an argument so that I can pass them a regular transaction or an OpenCloseTransaction, depending on the situation, which will dictate which type of transaction is needed or required.

As far as watching for Erasure of objects, you could use the events of DBObject which are reactors that are attached to individual objects, so you do not get notified about every object in the database, only the ones that you attach the event handlers to.

[stefanome]

---

@ActivistInvestor wrote:

I generally make it a rule to avoid dependence on the top transaction. Most if not all of the methods I write that use transactions will take a transaction as an argument so that I can pass them a regular transaction or an OpenCloseTransaction, depending on the situation, which will dictate which type of transaction is needed or required.

---

This would require refactoring Gilles extensions, but (1) I would have only one version (vs one read only plus one read and write) and (2) It would be clear what I do when I do it.

---

@ActivistInvestor wrote:

As far as watching for Erasure of objects, you could use the events of DBObject which are reactors that are attached to individual objects, so you do not get notified about every object in the database, only the ones that you attach the event handlers to.

---

Do you mean I should setup the event on the objects (1) when I created them and (2) when I open a drawing, by scanning the drawing for already existing objects?

This would  require one scan at drawing opening, much better than what I'm doing now, that is one scan every few minutes in the OnIdle event.

[_gile]

You do not need to re-write all the extension methods.

You can simply write 'classical' code to acces to DBObjects from an OpenCloseTransaction:

public static Dictionary<string, object> GetGlobalProperties(Document dwg)
{
    var db = dwg.Database;
    using (var tr = db.TransactionManager.StartOpenCloseTransaction())
    {
        var nod = (DBDictionary)tr.GetObject(db.NamedObjectsDictionaryId, OpenMode.ForRead);
        DBDictionary dbDict;
        if (nod.Contains(GlobalDictName))
        {
            dbDict = (DBDictionary)tr.GetObject(nod.GetAt(GlobalDictName), OpenMode.ForRead);
        }
        else
        {
            nod.UpgradeOpen();
            dbDict = new DBDictionary();
            nod.SetAt(GlobalDictName, dbDict);
            tr.AddNewlyCreatedDBObject(dbDict, true);
        }
        return DbDictionaryToDictionary(dbDict, tr);
    }
}

Or no transaction:

#pragma warning disable 0618
        public static Dictionary<string, object> GetGlobalProperties(Document dwg)
        {
            var db = dwg.Database;
            using (var nod = (DBDictionary)db.NamedObjectsDictionaryId.Open(OpenMode.ForRead))
            {
                DBDictionary dbDict;
                if (nod.Contains(GlobalDictName))
                {
                    dbDict = (DBDictionary)nod.GetAt(GlobalDictName).Open(OpenMode.ForRead);
                }
                else
                {
                    nod.UpgradeOpen();
                    dbDict = new DBDictionary();
                    nod.SetAt(GlobalDictName, dbDict);
                }
                return DbDictionaryToDictionary(dbDict);
            }
        }
    }
#pragma warning restore 0618

[stefanome]

I had never seen the ObjectID.Open, then I noticed that the IDE is reporting it as obsolete and it says I should use GetObject. I haven't tested, but I assume they are equivalent (maybe you are using Open simply because you are used to the old way).

Then I noticed that the Autodesk ObjectId.GetObject does not use a transaction while your extension ObjectId.GetObject<T> does. I think this had created some confusion in my head, but now the fog is starting to clear up.

So I decided it was time to revisit the documentation. I studied it 2 years ago, then other priorities pulled me away, then I just restarted working with Autocad and I felt I knew enough, just because my commands were working well. Now that I am more familiar with the Autocad APIs in general, I will be able to better understand how transactions and object opening work.

I already found out that I missed tons of Dispose: the documentation says I should dispose an object "Always with newly created database objects, objects derived from DBObject, that are not added to the database", and I have functions like this Polyline extension that don't Dispose:

public static int IsPointInside(this Polyline polyline, Point3d point)
{
    if (!polyline.Closed) throw new ArgumentException("Impossible to check if a point is inside an open polyline.");

    // return 0 if the point is on the polyline
    var closestPoint = polyline.GetClosestPointTo(point, false);
    if (closestPoint.IsEqualTo(point)) return 0;

    // return 1 if the point is inside, -1 if it's outside
    var length = polyline.Length + point.DistanceTo(polyline.StartPoint);
    var ray = new Line(point, point + new Vector3d(length, length * 0.1234, 0)); // using an unusual angle the chances of hitting a vertex are very low (and we are ignoring that occurrence... for now)
    var intersections = new Point3dCollection();
    polyline.IntersectWith(ray, Intersect.OnBothOperands, intersections, IntPtr.Zero, IntPtr.Zero);
    return intersections.Count % 2 == 0 ? -1 : 1;
}

Thank you all for your support.

I will take some time to study, digest, experiment, and finally proceed with the changes.

[ActivistInvestor · Accepted solution]

You would have to add handlers for the events when a drawing file is opened, and when you create new instances of those objects. Don't remove the handlers from the objects when they are erased because they could eventually be unerased and usually, handling erase also requires handling unerase.

[_gile]

---

@stefanome wrote:

I had never seen the ObjectID.Open, then I noticed that the IDE is reporting it as obsolete and it says I should use GetObject. I haven't tested, but I assume they are equivalent (maybe you are using Open simply because you are used to the old way).

---

The two codes I posted are equivalent. The OpenCloseTransaction is a wrapper for the Open / Dispose way which ensure the the DBObjects opened with or added to the OpenCloseTransaction are disposed when the transaction is disposed (this is why I use a 'using statement' for all objects opened with ObjectId.Open).

I'm not 'used to the old way', I simply wanted to show how to doi it without a Transaction as suggested by @daniel_cadext in reply #2.

#pragma warning disable 0618

Is used to disable the "Obsolete, For advanced use only" warning.

---

@stefanome wrote:

Then I noticed that the Autodesk ObjectId.GetObject does not use a transaction while your extension ObjectId.GetObject<T> does. I think this had created some confusion in my head, but now the fog is starting to clear up.

ObjectId.GetObject does use the TopTransaction and will crash AutoCAD if there's none top transaction (ObjectId.GetObject<T> just throws an exception).

The extension methods I've shared are just helpers to simplify the writing of certain common tasks in the usual situation where a top transaction exists. They do not dispense with the need to know how to open or create DBObjects in the classic way, as described in this section.

[ActivistInvestor]

---

@_gile wrote:

---

@stefanome wrote:

I had never seen the ObjectID.Open, then I noticed that the IDE is reporting it as obsolete and it says I should use GetObject. I haven't tested, but I assume they are equivalent (maybe you are using Open simply because you are used to the old way).

---

The two codes I posted are equivalent. The OpenCloseTransaction is a wrapper for the Open / Dispose way which ensure the the DBObjects opened with or added to the OpenCloseTransaction are disposed when the transaction is disposed (this is why I use a 'using statement' for all objects opened with ObjectId.Open).

I'm not 'used to the old way', I simply wanted to show how to doi it without a Transaction as suggested by @daniel_cadext in reply #2.

---

Hi @_gile. The two examples you posted are not exactly equivalent.

The difference between them. is what happens in the event that an exception causes control to prematurely exit the using() block that disposes the OpenCloseTransaction (in the first example) or the using() block that disposes the DBObject (in the second example).

DBObject.Dispose() always calls AcDbObject::close(), which commits any changes made to the DBObject.

OpenCloseTransaction.Dispose() without a prior call to Commit(), calls AcDbObject::cancel() on each DBObject opened with the Transaction, which discards any changes made to the objects (that example is missing the call to Transaction.Commit()  BTW, but I'm going on the assumption that it should).

So, in your first example (using OpenCloseTransaction), if an exception causes execution to exit the using() block before the call  to Commit() is reached, changes made to any DBObjects are rolled-back, whereas in your second example, if an exception causes execution to exit the using() block, changes made to any DBObjects are not rolled-back,  and instead are committed.

In order to make the two examples precisely-equivalent, you would need to refactor the second example, by placing all code that modifies the DBObject inside a try block that is followed by a catch() block that calls DBObject.Cancel(), and then rethrows the exception.

The general pattern would be:

static void ModifyWithObjectIdOpen(ObjectId id)
{
   using(DBObject obj = id.Open(OpenMode.ForWrite, false, false))
   {
      try
      {
         /// all changes to the opened object must occur here
      }
      catch
      {
         obj.Cancel();
         throw;
      }
   }
}

Which is precisely-equivalent to:

static void ModifyWithOpenCloseTransaction(ObjectId id)
{
   using(var tr = new OpenCloseTransaction())
   {
      DBObject obj = tr.GetObject(id, OpenMode.ForWrite, false, false));

      /// all changes to the opened object must occur here

      tr.Commit();
   }
}

So in fact, using ObjectId.Open() to modify DBObjects is not as simple as it may first appear,  and is so much-more complicated that I strongly advise anyone to avoid using it it for anything but read-only purposes.

[daniel_cadext]

it’s actually not rocket science. That’s how it’s done in ARX. I would argue that you should know how DBObjects behave if you want to be more than just a casual CAD programmer, and especially, if you are writing .NET modules professionally.

For those of us that started with .NET in back in 2005, this was the only way. It wasn’t until later that Autodesk realized the garbage collector was non deterministic, hence the introduction of OpenCloseTransaction

Transactions are great %95 of the time, but there's no reason to be afraid of manually opening an closing objects yourself.

[_gile]

@ActivistInvestor Many thanks for these precisions.

[ActivistInvestor]

---

@daniel_cadext wrote:

it’s actually not rocket science. That’s how it’s done in ARX. I would argue that you should know how DBObjects behave if you want to be more than just a casual CAD programmer, and especially, if you are writing .NET modules professionally.

For those of us that started with .NET in back in 2005, this was the only way. It wasn’t until later that Autodesk realized the garbage collector was non deterministic, hence the introduction of OpenCloseTransaction

Transactions are great %95 of the time, but there's no reason to be afraid of manually opening an closing objects yourself.

Autodesk always realized that the GC was non-deterministic, and that code running on the GC's thread had to be thread-safe. The issue was always the complexity of the code needed to deal with direct use of ObjectId.Open(), in cases involving multiple/many DBObjects, and that's the scenario which OpenCloseTransaction was intended to address.

In fact, early-on I had argued that DBObject.Dispose() should not call AcDbObject::close(), but rather, should call cancel() instead (if close() was not previously-called), to make its behavior align with that of Transaction.Dispose(). 

But as this thread attests to, knowing how to write code that properly deals with DBObjects accessed using ObjectId.Open() is not something that is all that well-understood.