>> As an example, consider trying to create a report generator that can target
>> any open FileMaker file. The report generator would store criteria, run
>> finds, extract and summarize data, etc. Ideally, this report generator is
>> universal; it does not require modifications to data files it is querying.
>
> The most generalised situations are covered by the two scripts above.

No they are not. They REQUIRE modifications to the query target.

> Put a database into Find Mode, create a find request by whatever
> means, Perform Find. You can specify the find request using
> AppleScript from another application or you can do it from within
> FMP. There is no need to hardwire the find.

Why are you repeating back to me exactly what I said as if it is something
new? I have already stated that the only ways to avoid the applescript Find
problem are to create a single step script perform find [no restore] script;
or else issue a commmand to an external application, which will then reflect
it back to FileMaker.

However, the need to modify every database by inserting a new script - even
this simple script - is something I would like to avoid. The purpose of
creating a generic report tool is to have it call on ANY other database
without requiring modfications to the other database. That cannot be done
with standard FileMaker techniques. That's the whole point.

> I'm only making suggestions that may provide you with other ways to
> get the job done. In my experience it is much better to get FMP to do
> as much as possible internally. Using FMPs built in scripting
> language is much faster than using Applescript, it doesn't get lost
> like helper files do and it doesn't generate
> dependencies/compatibility problems.

You are completely misunderstanding what I'm trying to accomomplish, any you
are incorrect technically.

The purpose is to build a generic report tools, in FileMaker, that can
report on any other database, without requiring any modifications whatsoever
to the other file.

The speed issue is more complex than you describe. First of all, universal
finds can be scripted with applescirpt in two ways: by creating standard
FileMaker requests; or by running "whose" queriies. The standard Filemaker
requests will operate with standard FileMaker speed; except that they
REQUIRE modifications to the target files (creation of the 1 step Find); or
use of the external helper. You are correct that applescript "whose"
statements are often slower. That's exactly why I have recommened standard
scripted requests.

In applescript, there are many things that can be done that do not require
you to view the database or "go to" any set of records, or see layouts; or
even have the file window visible (though of course it must be open). Set
thisList to field "SalesTotal" of every record whose cell "City" =
"Seattle". I can sum thisList quickly, or average it, or do whatever I want,
without creating scripts or summary fields in the target database.

I am tired, tired, tired, of hearing that I should throttle back to 10%
power becuause my neighbor with the Windows box can't keep up. I'm not
interested. I'm fully aware of how to do standard FileMaker scripting.

I will re-use an analogy that I have used often in this kind of discussion.
Just because all my neigbors own drill presses doesn't mean that the right
thing for me to do is shut down all the features of my 5 axis CNC mill and
punch simple holes all day.