>>>I was thinking of something along that line.
>>>Your solution is more elegant than what I had in mind, though.
>>>I'll try it
>>
>>When I consider Viv's embolded question a few lines above, I'd encapsulate that functionality in a small Dotnet class, which you could then use to embellish all of the textboxes Viv mentioned if the need arises. Put the magic numbers like the 7 into class properties and you are set to branch out into other currency counters ;-))
>>
>>The Custom Control would have the same ease of handling and needs only aggregation of the "counter class" and the wiring into the specific textbox class.
>
>Good ideas, Thomas.
>In this case my dedicated code is running like a charm, so I'll leave it.
>I have a personal rule about generalizing code as you suggest.. unless I have a need to use code at least 3 times, I don't generalize it.
>The efficiency of generalized classes like the one you suggest varies directly with the number of times they are deployed.
>Unless I can see that the extra effort to generalize the code will be amortized, I don't exert it.

Bill, the rule of 3 is not bad (I use the more rigid "break out any code you see repeated 3 or more times") but I use it for deciding if I should refactor code not touched in the last days (perhaps 3 again..). If in the finishing touches of new functionality, at the end I lean back a moment and wonder if there was a better architectural approach - moving the functionality at that stage is done MUCH faster than later, as all the relevant pieces of the effort are still easily recalled. The cost/benefit factor (benefit being less rigid/brittle code even if not generalized already) for me is most of the times positive.

Every seasoned dev has developed some practices best fitting his own strengths and weaknesses: the nagging uncertainty if refactoring late in the game without a rigorous analysis is never evoked, to enter a PURELY personal reason/argument as well ;-)