Hello Geoff:
I asked:
> >This sound interesting. Would you care to expand? I note <filter
>'container' with 'wildcard'> *replaces* the contents of the
>container with the result. That's rather puzzling.
> >
> >(I tried the command and found the entire contents of the
>container was removed leaving it blank)
And you responded with:
>The way I used the filter command was to store the data in chunks of
>1000 lines. For each 1000-line chunk, I make a copy and then filter
>the copy, because of the fact you describe above, that filter works
>directly on the text you hand it.
I note your iDirectory application. However, as I've not looked at
your code so I'm none the wiser.
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?
I asked:
>>What if I had, say, 50 preferences and wished to load those at
>>startup from a text file. I could keep them in a field and look up
>>the variable name as required. In a FaceSpan table the row title
>>can be set to the variable name and the first column contains the
>>data. So...
You suggested this as a way of storing preferences:
>So the way to handle the thing you're talking about is to break your
>application into two stacks. One will be built into a standalone.
>The other will go along with it, as a "preferences" file. Generally,
>the application stack ends up being the splash screen, and the
>"preferences" stack ends up being the bulk of your application,
>although there are a number of ways to do it. Then you can just
>store the 50 preferences as properties of your stack. Then you could
>refer to them and set them without doing anything special:
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?
And there is one further advantage. Mac users may not agree, but you
can read the text file with a word processor and modify the prefs
directly, (provided they are saved in plain text format of course).
DW
