>>>>Yes it works for me wonderfully well and cursors are the way to go to populate comboboxes in scalable applications. You are just making up unrealistic excuses not to use cursors (sys(1104) for example). You are not filling up the arrays with constants hard coded, do you? If you do then hands down, forget I even said cursor.
>>>
>>>
>>>I don't see embolded part the same way. I have not tested lately, but vfp tended to slow down earliest when lots of forms were kept in memory. IIRC next were DS and cursors, where slowdowns could be measured A LOT sooner than with multiple long arrays. After measuring this slowdown (in vfp6) we decided to base the common UC combo/listbox on arrays with an API for feeding in different data.
>>>
>>>I concur that cursors as language element are probably the best thing vfp offers in comparison to other languages - but arrays are more light weight.
>>>
>>>Some apps need hundred+ combos (in insurance combo is also often used), so whenever a couple of forms were needed in memory, the # of cbo ballooned.
>>
>>VFP6 ??? Isn't that the last version handling memory variables much more efficiently? Wasn't that a version where an array could hold 65000 elements at most?
>
>Back then I had enough budget to measure scientifically enough to warrant changes for multi-million development often too slow...
>
>As the C interface of memvars and arrays has not changed, I doubt the implementation is much different. AFAIR the only major change was the search algorithm for fields/memvars in vfp7, making time needed to find in NTI more linear - slower when few vars, much faster when many in use.
>Probably only a few C constants changed to allow larger arrays and so on in vfp9 as memory was not as scarce as in vfp3/5 times

https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-tip-field-name-lookup-for-tables/

MartinaJ