Of standalones, bundles and files
joel.guillod at net2000.ch
Fri Jan 28 05:11:10 EST 2005
> Date: Thu, 27 Jan 2005 23:27:32 -0700
> From: David Squance <dsquance at elkvalley.net>
> Subject: Of standalones, bundles and files
> I'm using RR2.1.2 on OSX, and would like to avoid using the standalone
> builder, as it takes 30 to 40 minutes doing something with a particular
> substack. Is there a reason why I shouldn't just build the
> splashscreen stack and put the 'real' rev file in the same folder and
> avoid having it in the build? And if I do this, is there a way to get
> the file inside the OS X bundle?
Recently Trevor DeVore <lists at mangomultimedia.com> gave me the answer
("the" at least for me!):
My preferred way to fastly swap from developing to testing the
implementation is to build the standalone as one stack with just the
startup screen and the script below. That way I dont need to wait the
long process of building a dozens stacks applications. My application
folder looks like this:
path/StandaloneApplication -- this is the standalone
path/StandaloneStack -- Optional but practical for swaping between Dev
and Standalone: This is the one stack used to build the standalone. Its
card contains the script below and a splah screen.
path/plugins/Startup -- this is my initialization stack: I put in its
"preOpenstack" all the scripts to executed to initialize my
path/plugins/ExternalLoader -- during initialization I do a: <go
invisible to stack "ExternalLoader"> to load the externals (see the
above link from Trevor).
path/plugins/many_other_stacks_used_by_your_application -- These are
the stacks of my application.
path/plugins/externals/ -- this is the folder in which I put the
path/plugins/externals/revdb.bundle -- this is the externals for
path/plugins/externals/revdb.dll -- this is the externals for database
path/plugins/externals/revxml.bundle -- this is the externals for xml
path/plugins/externals/revxml.dll -- this is the externals for xml
Script inside the unique card of the StandaloneApplication stack looks
like this (I use a variant because I have a rolling script for a field
displayed on the startup screen, I can share the whole stack if you'd
send startApplication to me in 3 secs -- dont do "startApplication"
directly because some libraries will not be loaded, see documentation
under the note under subject "revGoURL".
constant kStarterStack = "plugins/Startup"
@purpose To start the application according to the convention.
@convention Just next to the application file there should be a
"plugins" folder with a "Startup" stack (depends on constant
@convention This "startup" stack is just responsable to start the
application when it receives a preOpenstack message.
put the short name of this stack into kApplicationStack
start using stack kApplicationStack
put startupStackFilepath() into tStartupStack
if there is a stack tStartupStack then
hide stack kApplicationStack
open stack tStartupStack
-- this is the french translation : answer error "Le module de
démarrage de l'application est introuvable! Veuillez vérifier votre
configuration!" &cr&cr& tStartupStack with "Quitter"
answer error "The Startup module has not been found! Please check
your configuration!" &cr&cr& tStartupStack with "Quit"
set the itemdel to "/"
put my_applicationStack() into f
put kStarterStack into last item of f
put the filename of me into f
if the platform is "MacOS" and char 1 of the systemVersion is "1" then
--it's a bundle
if it>0 then delete char it to -1 of f
Note that for MacOSX bundle it should be possible to adapt the
startupStackFilepath() so the plugins folder is placed inside the
This is just a summary. If many are interested, I will take some hours
to polish my own stacks and put them as a complete sample downloadable
from the net. I wrote some usefull utility scripts to manage the
application settings. Let me know!
Joel Guillod - www.imed.ch
More information about the Use-livecode