These are the methods that fire the events.  The general purpose and structure of an On method is to fire the respective event.  So the MyBase call will be where the events are actually raised and then your code below the MyBase call will be executed after all handlers have responded to the raised event.

Hi Greg,

For what it's worth - have you considered firing your audit procs from normal database triggers rather than from with the app.

Cheers, Peter

Maybe this is what I want...I'm kinda tired, so not all the neurons are firing...



So, if I override these methods, and the BaseForm is casting its BOs to BusinesLayer and calling save/delete, these methods are fired?

Since you are subclassing the BusinessLayer, just override the OnBeforeSave method and OnBeforeDelete method rather than handling the event so you can test on the cancellation of the event args.  For example:

This way you are not relying on event execution order depending on when the handler was added and you can reliably test on the cancel arguments.  Let me know if this is not what you were looking for.

It occurred to me that I could probably just handle the BeforeSave/AfterSave and BeforeDelete/AfterDelete events in my subclassed business layer (obvious now).



However, I'm not sure how to handle the issue that the BeforeDelete event can be canceled. I.e. if I use the MaintenanceFormToolstrip, it calls the form's delete, which asks for a confirmation of the delete (handled by BaseForm reacting to the BeforeDelete event). Now I could turn off AutoDeleteConfirmation for the form, but a month from now, after I've forgotten what I've done , I could end up handling the BeforeDelete and mess up my auditing.



Is there a sure fire way of executing some code right before the delete is sent to the server?

I'm attempting to implement auditing. I've got a bunch of sprocs that do a nice job of handling the database side of things, now I need to be able to instigate it from the app.



To that end I've subclassed the BusinessLayer object and overridden the Save and Delete methods. It now handles saving away an audit history item related to change, with user name and an audit comment and saves a record of the fields that were changed changed and what the old and new values were (using the sprocs mentioned above).



However, when I went to test this with a form that was using a MaintenanceFormToolstrip, it didn't work. After some looking I realized that is because the MFT is calling the BaseForm's Save/Delete methods, which call a the BO's Save/Delete, but it is called through a cast to BusinessLayer....so my code never gets called.



So, my question is, what would be the best way to optimize the use of the framework without having to reimplement everything? I could just do a custom toolstrip that calls the methods of the bo directly and handles editing status changes, but would loose all the other cool MTS goodness. On the other hand, messing with the BaseForm seems even worse...my brain is a bit fried, so I'm not seeing clearly.



Any suggestions?



Thanks!