>>I think you can start with container class including textbox and listbox. >Initially, Listbox.Visible=.f. and Textbox.Rightclick event code will take >care about Listbox.Visible=.t., resizing the container etc.
>
>What would you suggest then if the popup class needs to be re-deployed in another scenario. Of, what if you needed to change the overall behavior? For example, instead of a Listbox, you wanted to use the MS Popup Control or a shortcut menu instead? While your suggestion will work, it is rather limiting. I only bring this up because the context of the question was directly targeted toward a "good OOP development"....
>
>I don't really mean to offend here....seriously, I don't. It is interesting however, that many suggested solutions to stuff like this usually peg things in the UI. Granted, you will always implement stuff like this in the UI. However, the classes, when developed, should not depend on a specific UI.
>
>Agree or disagree????

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.
Sorry, if my description is vague, it's because the issue is too generic.

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.