Yes, I got it once, and since populate ItemID with strictly unique values :-).

>Hi Ed,
>
>I'm replying mainly to fix the crummy italics I did in the original, but I did also want to say that there is a problem in my humble opinion with the RemoveItem / RemoveListItem methods *if* you happen to be using the ItemID. Neither will remove the ItemIDs, so if you happen to add an item with an ItemID that existed before but had been removed, the (new) item will only go to the spot occupied by the ItemID in its FORMER presence.
>This is not documented except in a MS KB article.
>
>Cheers,
>
>Jim N
>
> >>Since I continue to see lots of troubles with AddItem and AddListItem, and it's no wonder considering the need to use a lawyer to read their documentation entries successfully, here's a simple little hint to save lots of trouble:
>>>
>>>Use the List and possibly the ListItem property instead! As long as you don't need to play with the nItemID thingy, it's as simple as that. No surprises (other than the fact that a "property" can do these things in the first place).
>>>
>>>For your information, here is a paste of the preamble from the Hacker's Guide for these properties:
>>>
>>>----- start of excerpt -----------
>>>
>>>These two properties are arrays that give you access to the data in a list or combo box. These are very, very cool properties. They not only let you look up the information, but also let you change it when appropriate.
>>>
>>>----- end of excerpt ----------
>>>
>>>Hope this helps someone,
>>>
>>>Jim N
>>
>>Jim, you know, recently I had to reread Help for IndexToItemID and ItemIDToIndex topics just to figure out what was wrong with AddListItem-ed mover lists. I think next time I will get it, I will have to read again: cool but difficult to remember.