>>>>If user does something, your code reacts to it and assigns the value to this property. You have a choice of bindevent() to the things user may do, or having an _assign method for this property etc. There are ways to avoid having the code in .refresh() doing any checking.
>>>
>>>I think I understand what you are saying (although I have not used bindevent() yet). But I am not convinced that having a code in the Refresh() method (the way I did it so far) is going to be a problem in the long run.
>>
>>In the long run, it would be a problem only if it runs too long, too often :). Test on slow machines.
>
>I used to try to design everything to the lowest common denominator (e.g. slowest computer). And I often ended up having two much code and too much maintenance. And a few customers who still used slow machines didn't really appreciate what I was doing for them.
>No more Mr. Nice Guy.

Someone had the tagline "Premature optimization is the source of all evil (Donald Knuth)".

>Now I design everything for minimum code maintenance and if someone is having a problem I suggest that they spend some money and buy faster machines. Or add memory. Then they appreciate what I am saying :).

Been through that cycle too, and we're actually on the same side: I've found refresh issues hard to track, easy to forget the reasons (why does the code do this? which problem was this solving?) and thus a drag on maintenance. The simpler the refresh, the less work later.