Problem with Set Script in Compiled App
dburgun at dsl.pipex.com
Wed Aug 24 10:50:25 CDT 2005
The real problem is that you can't attach a script with more than 10
lines while running a standalone app, so RunRev would have to be
installed on the QA machine, which is far from ideal.
All the Best
>David Burgun wrote:
>>There are a number of reasons to extract the Scripts of RunRev
>>Objects into seperate text files:
>>1. We have to check files into a Source Database (Source Control
>>System) and Binary Files are not handlied that well.
>>6 We want to write an "include" file pre-processor that grabs
>>functions from a Common Include file.
>>There are more reasons that this, but these are the main ones off
>>the top of my head!
>Those sound to me like good reasons. But the question is whether the
>associating of scripts to objects *needs* to be done within a
>standalone executable ?
>At first glance, it seems feasible to achieve all (or very nearly
>all) of those objectives with a system like :
>- scripts are kept in the database
>- when it is time to release, a "build" script collects the scripts
>from the database and sets them into the script of the various
>- the standalone builder is then run to create the standalone.
>That would seem to get 5 out of the 6 issues covered cleanly, and
>could still be usable (with slight inconvenience) by QA to rebuild
>with earlier script versions. If that was a critical issue, you
>could (easily?) provide a mechanism to allow multiple versions of
>the scripts to be attached, with a run-time selection between them,
>for QA investigative usage.
>Alex Tweedly http://www.tweedly.net
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.338 / Virus Database: 267.10.15/80 - Release Date: 23/08/2005
>use-revolution mailing list
>use-revolution at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
More information about the use-livecode