Hi Marcia:

Hope all is well with you.

The file I am using is an invoice file with a row for each item of a transaction. In case no one knows the Invoice Number that it is being paid, I put up a screen that allows you to see a list of things like 1) Full Name (Name + Invoice No) 2) Full Address (Address + Invoice Number) 3) Full Phone (Phone + Invoice No) 4) .... you get the idea. The file is filtered to show the first row of any invoice. The above fields are all manufactured at the time of invoice production to load the list box. The operator gets a list box with an option group that allows selection of a different order. On Click, the operator is rounted to a different list box that opens at the same record he/she was on before.

If I didn't need incremental search, this thing could have been done really easily with a Grid. Your idea of creating a cursor or view as the row source would solve the list index problem I guess, but I found the whole process with the List Box very awkward.

But just so we have not lost the definition of the problem. Somewhere in this thread I was suggesting that I put something into the UT Wishlist saying that it would be nice if we could use locate for recno() = m.r1 to simplify the location of the initial record. All of the replies are offering work arounds, so I guess this is not seen as a useful improvement for VFP 10 or whatever.

I see in one of Sergey's replies, there are some threads about getting a Grid to do an incremental search. Marcia, do you know if a Grid will do this as fast as a List Box? I am really pleased with how my list boxes are working now that I have the bugs out.

Mike Smith