>>I am not a fan of collections and I don't use them. Arrays and custom (and mostly "Empty") object does good for me in most cases.
>
>I use collections a lot, but for small things, order of magnitude of a couple hundred elements max. They do help in cases where the search key is a string, and aScan() would match a shorter search string in a longer one, i.e. if a[4]="abc" and a[92]="ab", ascan(a, "ab") returns 4, not 92. Not so with collections, or at least I don't have to pad the key strings.
>
>I did have a case where I had to abandon collections and use arrays - and that was an XML builder where I used to have a collection of child elements, up to 4 or 5 levels deep. It worked fine for months in several places, until once it just stopped working for one, then another. Replaced with arrays and had no more problems.
>
>>I chimed in to ask about that "text and xml via com parsing". That sounds to be a bigger problem. I would try keeping away from COM unless absolutely needed. Maybe you could parse via XMLAdapter and remove the need to collections completely?
>
>AFAIK, XmlAdapter uses a COM object internally. Looks so in the debugger and intellisense.
I am well aware that VFP string searches are not consistent and you should always be careful (saying not consistent, I mean the behaviours are different depending on where you use it, in one way in xbase and in another way in sql - I have created some documentation on StackOverflow VFP doc if you want to check). With ascan() I simply use its last parameter and always get what I ask for. The correct search would not be ascan(a, "ab") but:
ascan(m.a, "ab", 1, -1, 1, 2+4)
I didn't know XMLAdapter was using COM behind. Even if it does, it is doing that well and in an encapsulated small piece of code I can get my nested xml structures as linked tables (of course I would probably create and use C# based activex control for parsing if I needed it myself).
