clones and scripts

Jeanne A. E. DeVoto revolution at jaedworks.com
Thu Mar 31 14:24:17 EST 2005


At 12:01 PM -0500 3/31/05, Thomas McGrath III wrote:
>I have a standalone that will offer a window based upon a project. 
>In other words if the user wants to have two projects open then the 
>standalone will offer a second window for the second project.
>
>What I want to decide is the best way to share the scripts. I am 
>thinking that a splash screen stores the code and substacks can be 
>used as the project windows. But I was thinking it might be better 
>to have a separate stack for each project so they can be deleted 
>from the users desktop. If I do this what is the best way to share 
>the scripts then.
>
>I am aware of the start using and was thinking that might be the way 
>to go. But then I would need a library stack, and then each project 
>would have a splash screen and a project screen. But it seems this 
>could be over kill. Any help/advice is appreciated.

I'd do it this way:

1. All substantive code routines are stored in the standalone's main 
stack script (which might as well be the splash screen). Because the 
splash screen is the main stack of the standalone, it is always in 
the message path whenever the standalone is running.

(Depending on the complexity of your code, you might want to put some 
of the code into other objects and use the insert command to make 
those objects into backscripts or frontscripts. But for a relatively 
simple project, putting it all in the main stack script will work 
without the need for backscripts, frontscripts, or start using.)

2. The standalone includes this main stack, plus one substack. The 
substack is a project window blank template. This template is never 
actually seen by the user; instead, it is cloned every time you need 
a project window.

3. When the user creates a new project, you clone the template 
substack. This clone can be saved as a separate file on disk.
-- 
jeanne a. e. devoto ~ revolution at jaedworks.com
http://www.jaedworks.com


More information about the use-livecode mailing list