At 12:36 AM +0300 8/14/01, Douglas Wagner wrote:
[Question about the filter command and my suggestion and mention of how I use filter
in iDirectory omitted]
>When you say you copy each 1000 line chunk of data and then filter the copy. What is
>the object of this? I don't believe you mean you have to filter 1000 lines for each
>and every search you do? What you describe seems to be a form of processing of raw
>data. The "filter" command surely isn't intended for large scale or routine searching?
That's exactly what I do. It depends on what you consider "large scale." iDirectory
stores everything in RAM. On a Mac, give it 10 MB and it will handle 10,000 records.
Give it more and it will handle more. On a system with modern memory management, it
should be able to handle anything the system has memory for. Here's the code:
on findABit
global theList, theListCount,theFilter,theBit,theHitList, theSearchMessage
put theList[theBit] into tl
filter tl with theFilter
if theBit is 1 then
put tl into fld "list"
put tl into theHitList
else
if tl is not empty then
if theHitList is not empty then
put return & tl after theHitList
else
put tl after theHitList
end if
end if
end if
if theBit < theListCount then
add 1 to theBit
send "findABit" to me in .001 seconds
put the result into theSearchMessage
else
put theHitList into fld "list"
put the number of lines of theHitList into fld "linecount"
end if
end findABit
I store the data in an the array theList, 1000 lines (records) of data per entry in
the array. Filter is destructive (results are in the target of the command) so for
each 1000-line entry from the array, I copy it into the temporary variable tl, use the
filter command, and append tl to theHitsList, which is the results. The first time
through, it's also placed into the field "list" to give the user something to look at
while the thing processes the rest of the array entries. The last time through, all
the results are dumped into the field.
The data is processed in chunks to limit memory usage and to get some results up in
front of the user as quickly as possible. Mind you, in my tests filter could handle
10,000 lines in less than a second on a fast mac, but I display results as the user
types, so it's best to give them as quick a response as possible.
Finally, you'd have to ask Kevin or Scott what the filter command is "intended" for,
but it works great for this purpose for me. :-)
----------------------------------------------------
[my suggestion to store preferences in a substack omitted]
>This approach seems to defeat the object of the standalone. In effect the application
>is being modified while it runs. That approach seems a dangerous mode of operation.
>What if a write corrupts part of the application?
>
>Why not keep a set of "default" preferences in the standalone. On the first run,
>test for the presence of an external preferences text file. If it doesn't exist then
>creat one from the default prefs in the standalone. On a later runs, import the prefs
>from the text file and save those in some convenient way, in a table for example. Now
>allow the user to modify the current prefs in a Prefs window, saving those changes to
>the external file for the next run. This approach also avoids the need to have a two
>part application. The application and it's prefs file is a more usual configuration
>isn't it?
You can do exactly this and still use a stack. In fact, iDirectory does this as well
(funny how that worked out, eh?). Here's the code:
on goPrefs
try
put the directory & "/prefs" into theStackFile
if there is a file theStackFile then
go stack theStackFile
send "returnVisit" to stack "prefs"
else
hide stack "prefsTemplate"
clone stack "prefsTemplate"
set the name of it to "prefs"
close stack "prefsTemplate"
save stack "prefs" as theStackFile
go stack theStackFile in window of this stack
show stack "prefs"
send "firstTime" to stack "prefs"
end if
catch errorNum
quit
end try
end goPrefs
Note that the prefs file _is_ iDirectory. The main file is nothing but a splash
screen. You can do it the other way as well, and avoid a few of the steps above.
Regards,
Geoff
