When programming, usually you come across a tricky situation where you need to decide if you want to "wrap" a control or "derive" a control. Although this seems to be quite a simple question, the implications are quite different.
CASE 1: When do I "derive" a control?
In my experience, usually you can derive a control when the base control is native to the development environment. For example, assuming you are working in ASP.NET, a custom text box implementation would be "derived" from the System.Web.UI.WebControls.TextBox control.
For me, the major advantage is that since the base control is native to the environment, you can be pretty sure that it would be well supported, documented & (usually) thoroughly tested before being released to the world, not to mention the advantages of deriving (inheritence) in an OOP's world, besides its programming model would be similar to what you would be expecting to code in your application.
CASE 2: When do I "wrap" a control?
Ideally whenever you use controls which don't satisfy case 1 - i.e. for all 3rd party controls!
Although I agree this defeats the purpose of using a 3rd party control in the first place, my take is that a 3rd party control introduces its own "style" of coding into your application code & then replacing a 3rd party control in your application at a later stage is far more difficult.
In our example, if I plan to use a 3rd party text box implementation - say Acme.TextBox control, I would wrap the control completely such that it is referenced & used only within the class which wraps it. The advantage of this is that, even though I am using the control in my code, I am not forced to use the 3rd party implementations for the properties/methods/fields anywhere else in my application. So, even if I need to replace the control at a later stage, the impact would be internal to the wrapper itself.
VERDICT:
In today's world our clients expect us to provide the most "cutting-edge" applications. Usually the native controls fail to meet these expectations & we, as developers, reluctantly use 3rd party implementations to satisfy our paymasters.
But keeping in mind the above two options, I think we would be in a position where the vagaries of implementations don't impact our application to a great extent.
Let me know what you people think.