How to filter a big list

[Jérôme Rosat]

Alex,

Thank you for your message. I'm not very at ease with messages and the  
command "send" but I will test your code. I think it is the good way  
to not slow down the typing of the user.

Jerome Rosat

Le 23 oct. 2009 à 00:33, Alex Tweedly a écrit :

>>
>> Would it be practical to break your list into 26 sublists by first  
>> letter?
> That's a pragmatic approach - but I think it's the wrong one.
>
> The fundamental problem is that the idea of scanning an entire list  
> at keystroke speed is not robust. Even if splitting into multiple  
> lists works for now, there's no guarantee that it will work tomorrow  
> - when the database doubles in size, or the data becomes skewed  
> because it contains too many people with the same first letter,  
> or .... or the users demand a similar feature for address as well as  
> surname, or they want to match string anywhere within the name,  
> or ....
>
> What you ought to do (imnsho) is to change the algorithm to one  
> which is inherently responsive, using either 'send' or 'wait-with- 
> messages' to ensure that this matching process does not interfere  
> with responsiveness. In this case, I think it's easier to use wait- 
> with-messages.
>
> So in outline
>
> each time the match data changes, you restart the matching process
>
> the matching process checks a fixed, and relatively small, number of  
> possible matches
>     updates the field showing the user what matches have been found
>     and then allows other things to happen before continuing with  
> the matching.
>
> I'd have a single handler that is always called when any changes  
> happens to the user input, which can kick off a new matching process  
> (by sending to the match handler). Then within the handler, I'd  
> periodically check whether there is a pending message to restart a  
> new handler.
>
> So a brief version of the whole script would be
>
>> local sShow, sStart, sData, sFound,sMatch
>> global gData
>>
>> on keyUp
>>   matchStringHasChanged
>>   pass keyUp
>> end keyUp
>>
>> on matchStringHasChanged
>>   send "processamatch" to me in 0 millisecs
>> end matchStringHasChanged
>>
>> on processamatch
>>   local tCount
>>      put gData into sData
>>   put the text of field "Field" into sMatch
>>      put empty into field "Show"
>>   put empty into sShow
>>      repeat for each line L in sData
>>      add 1 to tCount
>>      if L begins with sMatch then
>>         put L &CR after sShow
>>      end if
>>      if tCount mod 100 = 0 then
>>         put sShow & "....." & CR into field "Show"
>>         wait 0 millisecs with messages
>>         if the pendingmessages contains ",processamatch," then
>>            put "exiting" & CR after field "StatusLog"
>>            exit processamatch
>>         end if
>>      end if
>>   end repeat
>>   put sShow into field "Show"
>>   put "Completed" && the number of lines in sShow &CR after field  
>> "StatusLog"
>> end processamatch
>>
>
>
> Note the use of "......" to give an indication that work is still in  
> progress and there may be more matches to come.
>
> You could easily add refinements to this
>
> 1a.  if a matching process has completed (rather than exited), and  
> if previous match string was a substring of the new matchstring,  
> then instead of starting with
>         put gData into sData
> you could instead do
>         put sShow into sData
> (i.e. re-use the filtered list - but be sure to remember that if you  
> exit before completing, or if the matchstring changes in any other  
> way you need to restart with the whole of gData)
>
> 1b. If you do 1a, then if you are *nearly* complete with a match  
> when the matchstring changes, then just go ahead and complete it, so  
> you get to work on the subset.
> (good luck deciding what *nearly* means :-)
>
> btw - I don't think there is any magic 'split'-based method possible  
> here.
>
>
> -- Alex.
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution