>>I can duplicate the behavior by moving the Class Browser window down in my VFP6 window; the list box moves up if there isn't enough space in the window to display all the entries in the list, but it fixes itself when I move the browser winow relative to the bottom of the VFP main window. See if moving the Class browser window up in your VFP screen helps.
>
>Doesn't help. Moving it up high is how you can really see the problem manifest itself.
>
>>
>>If push comes to shove, you have the source for the Class browser on your system in XSOURCE.ZIP - you could modify the control's behavior to show fewer entries; ytou can also use the Class Browser to change some properties of the class browser itself - the VFP Help is rather detailed.
>
>I discovered the class browser props just after firing off this thread. At first blush I didn't see one that seemed to apply. Didn't know about the xsource.zip, so I'll investigate there.
>
>Since the class browser is programmable to some extent, I probably have inadvertently screwed up one of these programmable properties. Be damned if I know how.

Hi again David,

Just a clarification on my previous post. The value that causes this behavior changes based on the position (apparently) of the combo in its relationship to the screen. The value for the DisplayCount property that will cause this behavior is dependent on that. In my original test it was 21. Subsequent tests changing the initial position of the combo or form, yielded different results.