>>>>>ALternatively, you can create a textbox class that will become your grid textbox class, and swap out the base textbox for yours at runtime. The disadvantage to this is that it prevents you from putting instance code in your textboxes if you need to.
>>>>
>>>>You could use a textbox class that delegates events to the gridclass. Something like: grid.ColumnClick(this, columnNumber) You could go a step further and create an array property in the grid that contains references to objects that handle the delegated events. The nice thing about delegation to an object is that you can change what event handle object is referenced at will. This is a nice way of handling different behavior for different operating modes, it removes any need for case structures in the event handlers for multiple states.
>>>
>>>This is what I do most of the time, but you still have to have a textbox class that calls the grid's method, or you'll be writing that call in every box. And this still only lets you write common code for all textboxes in the grid, so if each one needs different behavior, you're writing a CASE statement to look at the calling object... this is not a nice way of handling it, but maybe the best design compromise.
>>
>>If you reread my statement above, you will note that I addressed the case structure issue and provided a way to avoid it. A refinement of the above technique would be to add the event handler object to the column instead of to the grid array property.
>>
>
>
>Ok, I did misread your post. But if you are going to all the trouble of removing a textbox and replacing it with another, and adding an object derived from a class that has to be programmed at the class level, how is this simpler than just creating a textbox class that has the code that you need? Or creating a grid class with columns already prebuilt with the textbox?
>
>Unless I am misunderstanding the implied benefits, delegation seems like a lot of complexity for the given task.

If you delegate to added methods of you column, as in the last example, there is no great complexity. The more complex examples are useful in that you can have a toolkit of interchangable handlers that you can hook on dynamically at runtime for any desired behavior. This can technique is useful in two ways -- it eliminates the need of a case structure to handle each column, you just hook on the appropriate handler for each column; when the behavior of the controls changes due to a change in operating state, you can hook up a replacement handler for the new behavior. Another place delegation is useful is for status reporting for utility classes. I have some classes that use a presenter class to handle status messages. I can have Presenter classes that output to the status bar, messagebox(), a wait window, a log file, or that do nothing. I can hook up a Presenter that gives the behavior I want for a particular application with no need to subclass my utility classes and no need for case structures in the utility classes.

Additionally you will note that instead of assigning the handlers to properties, I used addobject(). This has one advantage over properties with object references, I can use saveasclass() to implement persistent objects. Instead of storing information of the current state of the interface to an .ini file, the registry, a table, ..., I can save or restore the current state of a complete object heirarchy to or from a class library with a single call to the top level object.

There is added complexity, but the payoff can justify it if there will be code reuse. It is also justified in cases where you are not distributing the source of your classes to to developers who need to extend the behavior of your classes.