At 5:56 PM -0500 3/8/07, Peter K. Stys wrote: >I think firing events in response to control changes in done in code >is a dumb idea. Action is a user action, not a program's execution. >If I'm explicitly doing self.CheckBox1(j).value = true I don't need to >be told that I've just done this by having a new event fired! > >Ditto for TextChanged events in editfields, etc... > >There should be an easy way to tell whether an "event" was triggered >by the user vs. code. > >Don't others agree?
Yes, I agree completely. This is a large and unnecessary irritant, especially since some controls do it and others don't. It is much harder and uglier to add flags to decouple the action event from programatically setting the control's value than the reverse. If setting the control's value didn't trigger the action event normally, it would be a simple matter of calling that code in the cases where you DID want it triggered. But trying to remove the coupling requires hacking around with flags and trying to anticipate the order of various events. In other words it would be easier to couple "setting" to "action" when we wanted it, rather than the current situation of kludging flags together to try to decouple them. And I agree with Peter that in most cases I DON'T want them coupled at all. But this question came up at last year's Realworld and Aaron described how the current system is preferable, but frankly I couldn't follow his logic. Regards, Joe Huber _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
