I am very much interested in search and it is always interesting to see other people’s approaches.
I have done a lot of work on optimizing the searching in StringTheory and tend to use that but Clarion also has a built in “instring” function that you can use.
For example your Fast.Find method can be greatly simplified and sped up by avoiding taking any copies of the strings. You are doing a case insensitive search, so something like:
Fast.Find PROCEDURE(STRING SearchSTR,STRING OnThisSTR,BYTE DebugMSG)
if ~searchSTR or ~onThisSTR then return false.
if searchSTR and onThisSTR and instring(upper(clip(left(searchSTR))),upper(onThisSTR),1,1)
another thing would be to do the upper(clip(left())) on the search string just ONCE before you start searching rather than on each record in the database. And so on… there are always lots of ways to speed things up.
I have only had a brief look as I am heading out soon but hope that helps - and once again thanks for sharing. The interface looks much better than many “boring” standard Clarion apps.
just following on from what I mentioned earlier, a couple more suggestions for your consideration.
where you are doing a search on all the fields (eg. LOC:SearchMode = ‘Everywhere’)
srch &String ! trimmed and uppered search string
on take accepted on
srch &= new string(len(clip(left(LOC:SearchString))))
srch = upper(clip(left(LOC:SearchString)))
ReturnValue = PARENT.ValidateRecord()
if not srch &= null and srch
ReturnValue=Record:Filtered ! default to no match
if instring(srch,SV_:RecordNumber,1,1) then ReturnValue=Record:Ok
elsif instring(srch,upper(SV_:ZipCode),1,1) then ReturnValue=Record:Ok
elsif instring(.... and so on ....
note you only need the upper() where a field can have alpha characters so not needed for numeric fields like recordNumber which is a LONG but is needed for ZipCode which is string(20).
where instead you are searching on specific fields, it would be better to exit as soon as you find one column that doesn’t have a match, rather than doing the check on all the columns then checking if they all matched.
finally I should probably mention that you might want to look at setting up a filter string instead if this was to be used in a client server situation. In that case you want to do as much of the processing on the server (back end) rather than passing all the records over the network to the client for filtering in ValidateRecord.
Hum… I just signed up. First thread I see on the list is this. “Me comes here, me reads” your suggestion to this fella about INSTRING. “Me thinks”: WTH… would it really be possible that the guy who produced such code wouldn’t be aware of INSTRING?
Me; nah. I must take it easy on coffee… starting to see things.