> lets say i have a custom method on my texbox class to activate popup dialog box if certain key is pressed. in my base textbox class, I have a code in textbox's keypress event to call this custom method.
>
>now after adding mytextbox class to my windows form, i want to be able to change something in that custom method. i.e. call base class's method first and then add few lines of my code. how can i do that?

> i have a custom method on my texbox class to activate popup dialog box if certain key is pressed. in my base textbox class, I have a code in textbox's keypress event to call this custom method. now after adding mytextbox class to my windows form, i want to be able to change something in that custom method. i.e. call base class's method first and then add few lines of my code. how can i do that?


That's multiple questions in one… *g*

Let's look at what you are doing in Visual FoxPro. You have a form (let's say a class) and add an instance of a textbox class to the form. You now end up with an object on a form class. In VFP objects and classes are interchangeable. This is similar to prototype based languages such as JavaScript.

Only because a class and an object are the same you are able to change the method code of the textboxes now. Let's see how this compound class is instantiated. VFP first creates an empty form object. It then adds a textbox object. We're talking about an object here, after all the command is called ADD OBJECT, or Thisform.AddObject(), nor ADD CLASS or Thisform.AddClass(). Because you changed the method code in this object, VFP now changes the method code of the object instance. You have introduced new behavior without creating a class.

If you try to express this in OOP terms, what happens is that VFP creates a temporary subclass of the textbox and adds it to the form instead. However, this expression quickly fails when you think of multiple levels of inheritance. Internally, VFP most likely maintains a list of pointers to method code for the object and a separate list for the class. My guess is that the object list mostly has NULL pointers which are resolved to class pointers. Otherwise the code in the object instance would overwrite the code in the class. But that's getting too technical.

.NET isn't prototype based or object based as VFP is. It's like object oriented much like Java, SmallTalk or C++. In OOP you have classes that contain the definition and object instances that behave according to the definition. You cannot alter the behavior of an object, only the behavior of a class.

This is the reason you cannot change any override any of the methods of the textboxes. In fact, you can't change anything of the textbox object. When you change a property, what VS.NET generates is code that changes the properties of the already instantiated object. Changing properties and fields and calling methods is the only thing you can do with an object in .NET. This is similar to Visual FoxPro, actually. You can't assign code blocks to a method like you could do in some other XBase dialects:

Thisform.Click = { Messagebox("Hello") }

So what do you do?

There are several aspects to this. The first one is "overriding events". This is what you did in VFP, but it's not what you do in .NET. A class in .NET (usually) has two related members. One is the event, such as the KeyPress event. The other is a virtual method called OnSomething. For the KeyPress event this is the OnKeyPress method.

The control always calls the On method which raises the event (executes all registered delegates). The On methods are virtual protected and meant to be changed in subclasses. Events, on the other hand, belong to the public interface of a class and are meant for the consumers of the object (not the class).

Hence, if you're thinking related to words such as "class", "override", etc. the place you want to go to is the On method. If you think of "object" like in "I need a textbox object on this form", then you are talking about events.

In On methods you can override the code exactly the same as in the events in Visual FoxPro. Call the base.OnSomething method if you want to execute the default behavior. If you want to change the default behavior of the Textbox class in your own Textbox class, On methods are the way to go (at least for now).

What you are attempting to do is something different, though. You want to change the behavior of the textbox object on the form. Skipping back a few paragraphs, this means what you need is an event.

In your sub class you define an event and provide an On method that calls it. When you add the textbox to the form, the event becomes available to the form, as in .NET an event is basically a special property (sort of, at least).

In your form you can define a new method. Then create a delegate for the method and assign it to the event. Interactively, you enter the name of the method in the Properties Window. This isn't any different from creating code for the Click event, except that in this case it's your own event, not one of the provided ones.

Sometimes, you want to raise an event, but also provide the possibility to cancel the execution of the event. The corresponding key word in VFP would be NODEFAULT. In the .NET framework you find some samples of similar events. Usually they receive special event arguments (CancelEventArgs instead of EventArgs, if you want to look up the class). This class has a logical Cancel property that the event handler can set to true. The On method would need to deal with it and stop further processing accordingly. In .NET this does not happen automatically.

To summarize: When you define the class you need to think about what behaviour might need to change. Create events for those and call them from the class. When you instantiate the class, assign event handlers to these events.

While this would work, the actual questions, though, is: Why do you create a subclass of the textbox at all? In VFP this is quite clear. Overriding event method was the only possibility to change the behavior until very recently. Every other approach required that you implemented some sort of hook system or extension provider.

Not so in .NET. Events are available to all objects, not just the sub class. In fact, they are available only to other objects.

If you want to extend the behavior of a class and can do so by only utilizing events and properties, a subclass isn't the right approach. Instead you want to create a class that is completely separate.

This class would provide the event implementation for objects. For instance, it would provide a KeyPress event handler that checks for a specific key and displays a popup when the hot key is pressed.

If you now need this popup feature on a form, you can add any textbox (not just your sub class), add the Provider class that implements the feature and link the two. Linking could be done manually by assigning the KeyPress event of the textbox a delegate of the handler in your provider class.

A better approach, though, would be to have a method in the provider class that receives a reference to the object and wires the two together. I call these methods usually BindTo, but you can use any name. The parameter for this method should be as high up as possible. For WinForm controls, for instance, you should use Control instead of TextBox whenever possible. Then you can make the provider work with a larger variety of controls, for instance, RTF Textboxes, DateTime pickers, etc.