>I am writing a program to take 47,800 demographic records from a bulk mail list company and comparing it against 8,700 demographic records from a clients system - removing those from the bulk mail file that are clients.
>
>I am comparing the data three ways:
>- exact match (zip, lastname, address)
>- probable match (zip, address)
>- possible match (zip, digits of address)
>
>For the probable and possible matches, I want the user to make the visual distinction if it definately is a match or not. Running this through tests, I may end up with multiple client records that match the bulk mail record.
>
>What I wanted to do was supply two list boxes on a form... the one on the left would be all the records in the bulk mail file that are probable or possible matches. Depending on which record is displayed in the left list box, the right list box would list all the client records that are potential matches.
>
>What I think I wanted to do was have both list boxes look like an address label per record... that is:
>LASTNAME, FIRSTNAME
>ADDRESS ADDRESS2
>CITY, STATE ZIP
>
>I would then have two buttons - ACCEPT HIGHLIGHTED RECORDS and NO MATCH. The user would typically change the right list box to the matching record and hit the ACCEPT button which marks the acception and moves to the next record in the LEFT BOX (updating the right one with new data). A NO MATCH causes it to be skipped.
>
>Through testing, I was going to use a cursor for the left list box and was able to build a field called RECDATA that has that info with what I thought would cause the listbox data to carriage return CHR(13) All that appears to do is add an unprintable character to the listbox.
>
>I guess my questioning to the experts would be:
>
>a) can this be done - multiple lines per record in a list box?
>b) if it can, how can I display record divider lines?
>c) is there a better way to display this data - I prefer to NOT have to have the user scroll left or right to display columner data if at all possible - don't want to slow them down to much.
>
>Just for decision making help - when I ran this data through my comparisons, there were 1,600 records in the bulk mail data that matched to a total of 4,200 possible matches - ALOT to check by hand so the faster the better. This still will be ALOT faster than the old manual system that took days to complete.
>
>And before anyone voices concerns about a user having to do this comparison step each time they want to do a bulk mailing... I am recording the user intervened MATCHES into another database file for the next time the bulk mail comparison is run... that way, if the data was compared visually recently, that will be accepted automatically - which in essence will severly limit the number of records that need to be visually inspected.

Peter,
I wouldn't go with listboxes. 2 simple reasons :
-One line max 255 char limitation
-Thousands of records would mean long coffee breaks for the user.

For latter to see what I mean create a test table with say 5000 records :
create cursor myTest (myDummy c(10))
for ix=1 to 5000
insert into myTest values (sys(2015))
endfor

Now for a moment think in order to prevent requerying you'd let a multiselect on listbox. OK create a test form with a multiselect=.t. listbox, rowsource myTest. Select only a few and list them to screen. Were you able to get a coffee break ? (I guess yes) If no then go with listboxes.

My alternative preference would be a grid. I would use editboxes in it and that would accomodate multilines problem. An accompanying checkbox would make the selections.
Cetin