best approach for limiting length of combo boxes on datasheet forms

[WyvsEyeView]

I have a datasheet form in which one field is a combo box that will potentially contain hundreds of records. I've read about several methods of speeding up such combo boxes or limiting their initial contents and I have used those methods on "form view" forms, but they don't lend themselves to datasheet forms. One thing, of course, is to set the Row Source programmatically using the OnEnter event and to limit the Row Source based on a query with a limiting parameter of initial letters entered in a separate field. This works well for a "form view" form but on a datasheet form, I'm thinking that the list would have to be re-created for each instance of the field on the datasheet (for example, if you were entering a lot of records on the datasheet form) which could take longer overall than if the Row Source were set in the combo box's properties. Am I correct in that thinking and are there any other methods for speeding up long combo boxes on datasheet forms? If I'm not correct in that thinking, of course, I can implement the solution above. Thanks!

[FishVal]

... I'm thinking that the list would have to be re-created for each instance of the field on the datasheet (for example, if you were entering a lot of records on the datasheet form) which could take longer overall than if the Row Source were set in the combo box's properties.

There are no multiple instances of control in datasheet view, but only one rendered multiple times and having the same values of properties.
There won't be performance penalty, at least not that you are expecting.

This also means that unless your visible and bound combobox columns are not the same and Combobox.LimitList=False, combobox is expected to blink or not to display value through datasheet when RowSource property is being changed.

Regards,
Fish

[NeoPa]

Why Values in Unbound Form Controls Don't Persist may help to explain why unbound controls are not repeatedly set up.

[WyvsEyeView]

The fields I'm referring to are actually bound :) I understand why unbound field values would not persist--it is, as you said, completely logical. I think I just didn't explain myself very well, but at any rate, I discovered a way to work around the issue. Thanks for the input.

[NeoPa]

Good for you WEV.

It was probably my tired reading of your post that got me confused ;)

Pleased you're sorted anyway :)