Ah. Okay, that's more clear.
I can think of a number of ways to approach the problem, but let me say
first that I think that simply initializing it manually is really not that
bad, and in fact is probably the most easily maintained approach.
Especially since the alternative methods don't really put the information
in the Designer per se; they would just make the subscription to the event
more automatic.
Those alternatives include:
-- Using a message filter in your utility class (initialized in a
static constructor) that watches for all WM_KEY events. This has a number
of problems, including the fact that you'll have to filter for the control
because you'll see the message for _all_ recipients, not just the textbox
you care about, and of course the fact that you'll be dealing not with an
actual C# event, but rather a window message.
-- Sub-class the textbox. If you do this, a number of alternatives
open up:
* simply always subscribe the utility method to the event
* use the Tag property as a Designer-controlled way toturn the
subscription on or off
* create a new property for the purpose
There are other approaches along these lines, but the above is reasonably
representative, I think. There are other options that could be used if
your scenario is in fact more restricted than you've explained so far.
But in any case the fact is, I don't really think any of these
alternatives are really better than just writing the code manually. At
some point, someone has to configure the code to subscribe the method.
Whether it's done with the Designer or by actually writing a single line
of code in a specific place, I don't see much difference. I don't really
think you can get the Designer itself to support your goal, so the
work-arounds seem worse than what you're trying to avoid.
Pete
