B
Brandon Potter
I'm frustrated with the way I've been handling events previously inside
WinForms apps. It always seems that I end up with the effect I call
"AddHandler Hell".
I would like to do things a little differently and try to apply a little
more object-orientation to events; for a low-level example, I would like to
have my main MDI form and some child forms enable and disable some buttons
and controls based on the user's login status (logged in or logged out).
What's the most efficient way to almost define an event globally, so that
when my "UserAuthentication" class raises an event, say,
"LoginStateChanged", that the main form and child forms can respond to it
without having to individually wire up and keep track of each window?
It almost seems like I should be able to define a central shared/static
class that holds most application-wide events (i.e. an AppEvents class), and
allow my UserAuthentication class to raise AppEvents's "LoginStateChanged"
event.
Can someone shed some light on this for me?
Brandon
WinForms apps. It always seems that I end up with the effect I call
"AddHandler Hell".
I would like to do things a little differently and try to apply a little
more object-orientation to events; for a low-level example, I would like to
have my main MDI form and some child forms enable and disable some buttons
and controls based on the user's login status (logged in or logged out).
What's the most efficient way to almost define an event globally, so that
when my "UserAuthentication" class raises an event, say,
"LoginStateChanged", that the main form and child forms can respond to it
without having to individually wire up and keep track of each window?
It almost seems like I should be able to define a central shared/static
class that holds most application-wide events (i.e. an AppEvents class), and
allow my UserAuthentication class to raise AppEvents's "LoginStateChanged"
event.
Can someone shed some light on this for me?
Brandon