Topic: how to stop object events to react to our own modifying?

[nekitip]

If we change some values in entity programmaticaly, it will fire "modified" event.
If we are hooked to that event, then it will get processed an read again. That is not efficient (we know what is new there - since we are the one who change it)! There is a way to stop this by having boolean operator in modify object handler, that switches to "if we write something, then ignore first modify event".

But is there a better way?

[MexicanCustard]

As i replied to your other post on the same question.  You need to look at using an Overrule instead of trying to monitor each entities modified event.

[nekitip]

...You need to look at using an Overrule instead of trying to monitor each entities modified event.

Unfortunately, I think overrule is introduced with autocad 2010, not before.
I was hoping that there was an existing solution to this before overrule was introduced.
Never mind. Thank you MexicanCustard! I will look into overrule direction.

[TheMaster]

If we change some values in entity programmaticaly, it will fire "modified" event.
If we are hooked to that event, then it will get processed an read again. That is not efficient (we know what is new there - since we are the one who change it)! There is a way to stop this by having boolean operator in modify object handler, that switches to "if we write something, then ignore first modify event".

But is there a better way?

You can do one of two things.

Remove the event handler temporarily while you update the object and add it back once the changes have been made.

Use a boolean variable that's visible from both the code that modifies the object and the event handler, and before making changes that will trigger the modified event, set the flag to true. In the event handler, check the flag, and if its true, do nothing. After the changes have been made set the flag to false.

[nekitip]

Fast connecting and deconecting of event handlers to dbobjects I tend to avoid.
Boolean switch variable at event handler is indeed the way its implemented, but I've always been seeing it as a duck-tape solution.

[owenwengerd]

Can you modify your design so that it's appropriate for your event handler to handle all modifications the same way regardless of their source? That's another way to eliminate the flag.

[nekitip]

I was looking into that direction, but I think you can hardly avoid that boolean operator.

For other readers who stumble into this problem. With that operator, problem is that you must always pay attention to see if routine is really going to change entity. There is no general write routine "this is my write routine for my block and at the begining, i will put marker operator"
For instance, look at this, where should that boolean be?

Code - vb.net: [Select]

1. 'entity that is about to be opened for write only needs data in xrecord change. where should operator be?
2.  Protected Sub createXrec(ByVal name As String, ByVal ent As Entity, ByRef trans As Transaction)
3.         If ent.ExtensionDictionary.IsNull Then
4.             HERE_IS_WHERE_IT_MUST_BE = True
5.             ent.UpgradeOpen()
6.             ent.CreateExtensionDictionary()
7.         End If
8.         'although it seems it is part of same entity, and opened for write, extensionDict is already different ObjectID!!
9.         Dim extensionDict As DBDictionary = trans.GetObject(ent.ExtensionDictionary(), OpenMode.ForWrite)
10.         Dim newxrec As New Xrecord
11.         extensionDict.SetAt(name, newxrec)
12.         trans.AddNewlyCreatedDBObject(newxrec, True)
13.     End Sub

[TheMaster]

I was looking into that direction, but I think you can hardly avoid that boolean operator.

For other readers who stumble into this problem. With that operator, problem is that you must always pay attention to see if routine is really going to change entity. There is no general write routine "this is my write routine for my block and at the begining, i will put marker operator"
For instance, look at this, where should that boolean be?

Code - vb.net: [Select]

1. 'entity that is about to be opened for write only needs data in xrecord change. where should operator be?
2.  Protected Sub createXrec(ByVal name As String, ByVal ent As Entity, ByRef trans As Transaction)
3.         If ent.ExtensionDictionary.IsNull Then
4.             HERE_IS_WHERE_IT_MUST_BE = True
5.             ent.UpgradeOpen()
6.             ent.CreateExtensionDictionary()
7.         End If
8.         'although it seems it is part of same entity, and opened for write, extensionDict is already different ObjectID!!
9.         Dim extensionDict As DBDictionary = trans.GetObject(ent.ExtensionDictionary(), OpenMode.ForWrite)
10.         Dim newxrec As New Xrecord
11.         extensionDict.SetAt(name, newxrec)
12.         trans.AddNewlyCreatedDBObject(newxrec, True)
13.     End Sub

The modified event does not fire until the transaction you modified the object in is committed, so the flag would have to be set when the transaction is committed.

[TheMaster]

Fast connecting and deconecting of event handlers to dbobjects I tend to avoid.
Boolean switch variable at event handler is indeed the way its implemented, but I've always been seeing it as a duck-tape solution.

Removing and adding event handlers is not a problem because it only needs to be done once (when an object is added to the entity's XDictionary).