I doubt that this is a best practice. I've certainly never heard of this as
any kind of best practice.
an event that fires an event, sounds like the author wanted to play with
events.
Code for the sake of code usually adds unneeded complexity. That increases
the cost of maintenance and increases the liklihood of errors.
There are some elegant ways to seperate business rules from UI. Event
indirection isn't one that comes to mind.
Regardless, if you have to keep this code working, and it is already
working, no point in changing it. Stick with the model in this app.
Just try not to learn from it.
My $0.02
--- Nick
"(Pete Cresswell)" <x@y.z> wrote in message
news:gu******** *************** *********@4ax.c om...
I've been perusing a "real-life" application and notice that for instance,
in a button's Click() event, they don't write the processing code. Instead,
they raise an event like AddNewRecord and then put the coding that would have
been in the click event in the AddNewRecord event handler.
It seems TB throughout the app, so I'm guessing it's some sort of Best
Practice.
Anybody care to explain?
--
PeteCresswell