Topic: Events

[Draftek]

I tend to stay away from the event handlers but the users want my BOM program to work automatically when inserting, moving, copying or deleting blocks.

Any suggestions? - I'm really afraid of the ObjectModified event or any database events really.

I'll be updating a table based on some blocks and their associated attributes.

Thanks

[sinc]

Feel the fear, then do it anyway!   

But seriously, event handlers are a major part of object-oriented programming.  If you continue with .NET, you'll be using them a fair bit.

[Draftek]

My bad, I should have been more detailed.

I don't like the idea of manipulating the database while trapping an event of the database which is manipulating the database.

Does anyone have any experience modifying the autocad database as a result of a database event?

[LE3]

I have done little about events in C#, but have followed what I been doing in ARX, to monitor new objects and highlight them I go with ObjectAppended and to change them  I use ObjectOpenedForModify all of course combined with a command event.

[sinc]

I have some things where I watch ObjectModified, then store the ObjectId.  The I also watch Editor.EnteringQuiescentState, and that's where I actually do my changes.

I remember trying to do this using some of the other event handlers, but ran into various problems.  I finally ended up using this approach, and it has seemed to work pretty well so far.  It has some interesting repercussions sometimes, such as when the user modifies an object I'm watching via the Properties Palette (the event handler fires a bit later than I'd like in this case), but all in all it seems to work well.

[Draftek]

I was just playing with ObjectAppended and it works great with a boolean flag set so it doesn't work recursively.
Except - If I run multiple copy.

After the first copy everything looks good - then upon each following copy my last selection set object (the table) gets copied by autocad instead of the selected object....

That would be pretty cool if that is what I wanted to actually happen.
And yes, I'm disposing of everything in my blocks of code.

Somehow the selection set autocad is using is getting replaced by my last one.

[mohnston]

I tend to stay away from the event handlers but the users want my BOM program to work automatically when inserting, moving, copying or deleting blocks.

Any suggestions? - I'm really afraid of the ObjectModified event or any database events really.

I'll be updating a table based on some blocks and their associated attributes.

Thanks

Classic data/sync dilemma. Does your BOM program data go anywhere except the current drawing itself? For example a data file or database?
If it does you have a much more difficult task since users can Save, Undo and Redo with reckless abandon. And what happens when AutoCAD freezes or crashes? (yes it will) Your data can get out of sync SO MANY different ways.

In my opinion, this "LIVE" connection between drawing entities and other systems can be done but it's usually cost prohibitive.

[Draftek]

No, just a table object in the drawing.

But it still sucks...

[mohnston]

Something that might help is creating an interface for working with your objects whatever they are.
Let people do the create, modify in the interface and if they click OK you can update the objects and the tables.
There will be fewer events to deal with. Plus an added advantage is that you can validate input.

[Draftek]

I'm not sure I follow, I'm dealing with a block with attributes, some xdata for filtering and a table.

I have it working. I seem to remember a conversation about not using user interaction when dealing with database events.
I was using selection sets and the editor and apparently that is a no-no.

[Peter Jamtgaard]

I have a program in lisp that does what you are trying to do
without the xdata part, but that would be easy to add.

I do this all the time (with lisp)

I mean objectmodified reactors.

(Of course it is in lisp, but the process is the same.)

I would create a list of modified/appended object handles using the objectmodified or objectappended reactor.

It just makes a list of handles.

Then use a commandended reactor to iterate through the list and
do the cleanup after the command ends with a flag to prevent the
objectmodified/appended callback from running again.

[Draftek]

Thanks, I'm open to all ideas.

ObjectAppended and ObjectErased are working okay but I'm having some issues with ObjectModified running recursively.

[Draftek]

PeterJ, Thanks!

You pointed me in the right direction.
Set a flag in the database events and then take action in the commandEnded event.

Works like a charm.

[sinc]

I ran into issues using CommandEnded for this, but I can't remember exactly what.  That's why I ended up doing my processing in Editor.EnteringQuiescentState instead.

Unfortunately, I can't remember at the moment why I ended up using that event instead...  Maybe it will come to me later.  I think I ended up using Editor.EnteringQuiescentState after seeing it in Kean's blog, but this was a couple of years ago now, and I can't remember the details...

[Draftek]

Thanks, I'll take a look at that too!

I'll be doing some serious testing before unleashing this on my innocent users....