>It completely depends on scope of usability. Surely enough, any VCX can be either more specific or more common. My understanding is that robust OO approach is that class is self-contained, i.e. developer can write code using internal PEMs only, all external factors will go through parameters: Class.Init event, and/or other event/methods.

OK... Then when you instance the TextBox Class, you could send a parameter that references the lookup class. Or, using the approach I suggested, the Textbox would have a property that refernces a class that is instanced when the TextBox is instanced. Regardless of the approach, you are still using methods of the TextBox to do everything. Yes, there are methods of the lookup class getting called, but all of that is happening behind the scenes.

I am not sure that robust OOP design calls for lumping functionality into one class. I think it is more about providing a concise, straightforward interface for the client to use. Behind the scenes of course, many objects are collaborating with one other. A good design obviates the need for the user to know exactly how that collaboration occurs.

>In particular, if some developer wants to use MS Popup instead of native >listbox, then he/she can proceed with new class. It's impossible, though >endeavour, task to write library which will cover all once and forever.

Even with my example, a new class would be needed. Except that in my case, the new class deals only with the lookup. What you are implementing, on a form, remains unchanged? The only change is the lookup class getting instanced. All of the implementation code at the form/textbox class level remains unchanged. When creating a new class, you only want to change what needs changing, nothing more.