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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
