David,

>
>It's sorta silly to give the user a 22,702 item long cbo in the first place.
>

I agree. As I stated earlier, a "larger-than-preferred" dropdown was how I found out about the bug... The class was designed and has performed excellent in applications with much smaller recordsets for 4 years - 50 to 6500 records. The bug is regarding the element limit of the array. So lets see... 6550 records x 5 columns is 32,750 elements. Going from a 13,000 record limit to a 6550 record limit is a big concern.

>Why would the user want to interact with your system like that anyway? Your cbo is populated with employee numbers which makes that the incremental seek value. Why not develop a much faster UI that uses two textboxes, one to enter an employee number and another to allow them to enter a last name. Get the "key" data from them and then present them a candidate list to select from if there is more than one match? ie they type "smith" in and you let them pick the one smith they really want. If they type in a employee number you go directly to that employee's record.

Ok... Finally some constructive input. I've spent many long nights perfecting this combobox class. It's a "Quick-Books" classic and works great. I do agree, with VFP controls anything can be built. My Outlook bar is all VFP controls. For building data-intense interfaces you couldn't ask for better than VFP controls. That's why I am bummed about this bug in VFP 8.0. Probably I wouldn't hit the limit with anything in production right now... but how long? And how long before a fix?

>
>Your network admins will be happier with your app because you'll stop slogging so much data down the wire, your server admins will be happy about the reduced load on your file server and your users will be happy because they don't need to wait for huge cbos to be constructed chewing up megabytes of memory.

If you must know David... :)

My framework has application-level "lookup objects" - session objects. These lookup objects have methods with names like:

Location_LocationNo
Location_Name
LocationVendor_LocationName
LocationVendor_VendorName
LocationAnalyst_LocationName
LocationAnalyst_AnalystName
Vendor_VendorNo
Vendor_Name
Analyst_Name
Analyst_AnalystNo
Action_Name
ActionTask_Name
CostCenter_Name
CostCenter_CostCenterNo

The methods share the same cursors to populate the array property (aRowSource) on the ComboBox class. The ComboBox class name by default is the method name in the Lookup Class. Comboxes can be manually requeried at Interface-Level or Individually. The Lookup class can either load all required DataObjects (cursors) at startup or on an "As Needed" basis. Before lookup method calls the required DataObject (cursor) "requery time" property is checked. If the time has lapsed the cursor is automaticly requeried before the SQL Select INTO ARRAY .aRowSource. All comboboxes in the application use lookup objects to load data. Lookup cusors are shared throughout the application, across all data sessions - comboboxes, interface objects, business objects and process objects. You get the idea. This solution works excellent in FoxPro, SQL Server and Oracle applications and greatly reduces network traffic and support questions.

>
>Besides what happens to your app in VFP7 when the 32,501st employee is hired?
>

Again, with the record count... It's the Max. element count of the array that is my problem not the record count. With this bug my record limit went from 13,000 records (around the max of the combobox control) to 6550 records. The class performs fine to around 10,000 records and I used the control in applications with that limit in mind. Moving to VFP 8.0 with this bug potentially breaks current applications and leaves me at a disadvantage in new development because now I can't use the class as it is designed to be used. So forgive me if I am a bit disappointed about this bug.

>>Wow, that's a pretty BIG BUG and certainly enough to stop me from working in VFP 8.0 since my framework uses the same approach for all comboboxes. The code ran fine when testing with 8.0 Beta. What's worst functionality that worked in Beta in now doesn't or advertised functionality that never worked?
>
>>>>My problem is a "larger-than-preferred" dropdown consisting 2 fields from a 22,702 record table. This calculates to 45,404 elements which is under the 65,000 Maximum # of elements.