>>>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?
>It is interesting that there are so many people in VFP filling up the arrays with hardcoded constants. With hardcoded constants I wouldn't go after cursors either.

Yep... Had to change a few programs in VFP6 from using arrays to cursors after running into the array size limitation. With two-dimensional arrays this limit becomes more acute, since the number of rows is reduced significantly (i.e. maximum row count is 65000 divided by number of columns). As a side benefit, some of the code ended up being simplified in several areas - especially when transitioning from DBFs to a SQL backend.