Creating a Search Field

[Josh Mellicker]

On Apr 29, 2008, at 7:29 AM, william humphrey wrote:

> The fld "bigList" could be a dump of data from a SQL database or the  
> search
> code could be re-written to directly search the database?
> At what point is it better to put the database in a search field and  
> search
> that or use SQL directly and search the database?  With the goal  
> being a
> list of results that shows up instantly as you type in the search  
> field.


I would say there's no particular "point", it's just that the initial  
download gets progressively slower the larger the dataset becomes. You  
have to deicde how long a wait is acceptable, then see if you can get  
all the records you need in that interval.

A search field that had to hit the database every time would be slow  
and not so fun as one that works on a data set in memory :-)

We have an app that downloads about 1200 records, this happens in  
around 5 seconds, then a search field like the one you speak of  
provides instantly filtered results.

Here is our script:

First, the search field script:

ON keyUp tKey
     FilterWSearch me
END keyUp

ON backspaceKey
     delete char -1 of me
     FilterWSearch me
END backspaceKey

(Obviously we're not accounting for arrows, selected text, but it  
works fine, no one misses those things, for a simple search people  
just type a few characters...)


Then, the table field ("theData") contains the records, and also, a  
custom property ("uData") with the data.


Then, somewhere in the message path:

ON FilterWSearch pSearch
     lock screen
     put the uData of fld "theData" into tList

     IF pSearch is not empty THEN
         filter tList WITH "*" & pSearch & "*"
     END IF

     put tList into fld "theData"
END FilterWSearch

This way, if there is nothing in the search box, the table field shows  
all records, otherwise, it shows only records with a string matching  
the string typed into the search box.