Bruce,

The problem I had with AddListItem was as follows:

I had a multi-column list box from which the user could add or remove items. Any items removed mid-list caused "squishing" of the list so that all remaining entries were contiguous. Any adding was always done to the end of the list.
Now with AddListItem you have to supply a nItemID. Unfortunately, RemoveItem does *NOT* clear the array of nItemIDs (this turns out to be "by design"). The consequence is that whaen I try to add an item to the END of the list it would not go there. Rather, it always went into the spot previously occupied by the now deleted item with the same nItemID!! This was a frustrating "bug" (by design"!!!) to the max! Days of pulling my hair out, for nothing!

Needless to say, I developed a strong negative relationship with AddItem and AddListItem. List was so nice and simple by comparison, with absolutely no surprises (so far!). The only problem with List was that it was in no way remotely obvious that it could even be used for the purpose.

Hope that explains things,
regards,
Jim N

>>Elyse,
>>
>>You really CANNOT do this with AddItem - it is my "pet peeve" with VFP and its documentation!
>>
>>I strongly suggest that you use the List property to do what you need . List doesn't seem to be an "action" type function, but it actually is!
>>The undocumented "problem" with AddItem is that each invokation results in a new row being added *BY DESIGN*.
>>You could achieve success with AddListItem, but if you ever plan on deleting any of the rows, then STAY AWAY FROM THIS ONE TOO! List does anything most people need except to "maintain" an ItemID list.
>>
>
>Thanks for noting that you must use AddListItem, not AddItem. Then it works fine...But I'm not sure what trouble deleting you're referring to, RemoveListItem works fine AFAIK if used properly...that is, it's no worse then a single column list with RemoveItem...