.NET

[#1]

I'm a beginer in programming Autocad and my english may not be so good.

I'm trying to modify a table after user modifies a cell of that table. So i'm using CommandEnded event to do so.

The program works fine until user change table cell content via Proprieties Window. That because CommandEnded doesnt fire in that case.

I cannot use Table object's events because i have to modify the Table object itself during that notification (eWasNotifying error).

There is a trick to manage this problem?

[#2 · Accepted solution]

How to know if an entity's properties are modified by the OPM?

But that possible with ObjectARX and not with AutoCAD .NET API:

Can't find ModelessOperationWill Start Event in .NET

 

[#3]

You may want to see this post for more

http://www.theswamp.org/index.php?topic=43757.msg491198#msg491198

[#4]

---

Hallex wrote:

You may want to see this post for more

http://www.theswamp.org/index.php?topic=43757.msg491198#msg491198

---

Sorry, but the link above does not help the author to solve his problem. The reason is that the event CommanEnded does not occur when editing primitives through the Properties panel.

[#5]

Thanks Alexander.

At the first look the solution looks a little complicated for me. At least I know that is about reacting to OPM events. For now i want to keep my code simple, so i will not complicate responding to OPM events. After i will finish the project, i will consider to upgrade my code with OPM events. Until then i will instruct users of my plugin to not use Proprieties Window to change the table.

I was hoping to be more simple (like an allready exposed .NET event) because i'm learning best practices to handle .NET events. Do you know a resource to learn more about .NET events or best practices?

Sory for my bad english, and thanks!

[#6 · Accepted solution]

Alex - The controls on the Ribbon do not filre the ModelessOperationWillStart/Ended() notifications either, so that entire approach is flawed to begin with.

The ModelessOperationWillStart/Ended() notifications are effectively-obsolete, and the fact that they're not exposed to managed code isn't a major issue, because you can just as easily use the DocumentLockModeWillChange event of the DocumentCollection to do effectively the same thing (when the document is unlocked, that corresponds to the ModelessOperationEnded() notification).

The problem with using the ModelessOperationEnded() notification to make additional changes, is that those additional changes are not encapsulated within the same UNDO groujp/transaction as the changes that triggered the notification, and to the end user, all of the changes are part of a single, logical operation that should be undo-able as a group. Unfortunately, changes made in reaction to changes that trigger a ModelessOperationEnded() notification, will not be undone along with the original changes that triggered the notification. So, if the user issues UNDO/1 after you've made additional changes in response to ModelessOperationEnded(), only those additional changes will be undone, but not the changes that triggered them, and that is a problem.

The best possible way to deal with problems like this, is to use an ObjectOverrule, provided it is constrained using some kind of Filter (ObjectId filter, XData filter or XDictionary filter). Unlike the ObjectModified event of the Database, within the Close() override of the ObjectOverrule, the notifying object that is about to be closed can be modified, and more-importantly, any additional changes made at that point will be undone along with all other changes made prior to that, by whatever operation made them.  

[#7]

See my reply to Alex regarding this issue. The entire approach you want to take has some problems.

Secondly, you really don't want to find yourself in the position where you find it necessary to tell users they can't use certain tools, like the Properties palette or the ribbon.

[#8]

Tony! Thank you for the excellent explanation. What a pity that you so long was not on the Autodesk forum ...