events and me

[kpgraci]

This is mostly a philosophical argument than a question, maybe it’s just me, or maybe others have had the same thought. I’ve been programming PC’s since prior to the advent of windows and event driven programming, and I’m sure someone will tell me I’m doing it (or thinking about it) wrong but I’ve always had this nagging problem with the lack of differentiation between user generated events and program generated events.

For example, if I have a handler on a combo box selection changed event, and the user changes the combo box, I want the event code to execute. But often I find that if I set the combo box in code I don’t want the handler to execute. I’m in the habit now of setting a global ignore_event flag that I set whenever I programmatically perform initialization that will trigger control events, then in the event handler I check this flag and exit immediately if true.

So while I’ve always thought that any user interface control events should be triggered only by user actions, I have written a lot of code that relies on the program triggered events as well, so in my perfect world there would b a compiler option like Option ProgramEvents On.

My latest run in with this behavior is a report selection screen I’m working on, where I have a combo box that allows the user to select a report type or a user-defined option. Below the combo box it is a block of controls, checkboxes and radio buttons that are set based upon the report the user has chosen. Now if the user manually changes any of the ‘advanced report parameters’ I want to reset the report selector to ‘user defined’. The problem occurs when the advanced settings are changed in code as a result of the user changing the report combo box; they dutifully reset the report to user defined. So I need to add my ignore_events flag all over the place and the result is really quite unattractive.

I’ve never heard or seen any indication that others have thought that the triggering of events by code to be a problem, perhaps only a gotcha for new programmers, and I believe most think it is not only desirable but essential. I would rather have the burden of selecting which event block to execute in exchange for code that has the potential for entering an infinite loop of event chasing – one of the few times I see that once common error message ‘out of stack space’.

To me it’s simple – user controls should trigger events when the user interacts with them, when code interacts with them the code (aka, the programmer) is responsible for what gets called. I think this would eliminate a lot of potential bugs and redundant code execution. Or I could be wrong.

 

[JohnH]

This is often the discussion about whether to set the property or the backing field in code. Usually the property setter, if related to a 'change' event calls the internal 'OnPropChange' which in turn raises the event, while the internal code may choose to bypass that mechanism and instead set the backing field directly. Such layer of indirection may also be used in other cases where sometimes an update does this and other times does that.

 

[kpgraci]

Yes, setting the backing property vs the property to bypass the change event, that's exactly what I'm talking aobut. I could well be ignorant on this matter, but is it possilbe to access the backing properties of common user controls (I doubt it).

I've desired this in vb6 and vb.net, I'm currently programming in silverlight 4. While I'm still on the SL4 learning curve from what I've seen if it were possilbe anywhere it would be here.

 

[JohnH]

That is something you can do when you define a class with a property (and an event).
I know nothing about Silverlight.