cross-stack globals, also, file inclusion

Joel Rees joel at alpsgiken.gr.jp
Tue Oct 21 00:57:10 EDT 2003


Hi, Rob, and thanks for the comments ...

> >Is there an easy way to set up something similar to file inclusion?
> 
> Not that I've found or read of so far...and it would be nice if one existed.
> 
> Example:  Serendipity Library defines about 265 constants; but much 
> of the code independence is lost because a constant must be defined 
> in each script that uses it rather than in a master list that can be 
> included in each script but maintained in a single copy.

Maybe I should be submit a feature request?

(I wonder how much overhead there would be in passing 265 constants
around via handlers. The "send ... put the result" interface is less
than optimal. I can stand it for a few file paths, but I'm betting it'd
get in the way with a lot of the constants you've set up. I'll have to
take a look at your libraries some time.)

> >What I've settled on to deal with this [finding a full path name to 
> >a subStack] is a handler in the primary stack
> >which sets several global variables, including the path of the primary
> >stack directory and the sub-directory where the independent sub-stacks
> >are stored. [snip]
> >
> >But I have not been able to come up with a way to get the primary
> >stack's path unless the primary stack is already running, because the
> >global "stacks" property/function will execute in the environment of the
> >independent sub-stack.
> 
> "get the effective fileName of this stack" returns the complete path 
> name of the stack, or its mainStack if its a subStack.

Okay, it gives the name of the stack that the handler resides in, rather
than the calling stack. That's good.

Looks like there's going to be a lot of Hypercard stuff that will need
to be swapped out for Metacard stuff. That's going to raise the project
cost a little bit.

> >But I want to generalize a bit. I don't want to have to know the name of
> >the enclosing directory in advance, and I want to be able to bury
> >sub-stacks several directories deep.
> >
> 
> My approach to generalization is a file search handler that looks for 
> a stack or file in several different places, depending in part on the 
> current platform. All file searching is relative to the main 
> standalone; so the level of nested directories can be as deep or 
> shallow as the placement of the standalone.

Heh. Didn't want to go quite that far. I'll keep your example handy,
however.

> ...
> 
> >Hopefully, I can get the paths problem fixed enough before I convert the
> >stacks to RunRev that the converted stacks will run under Mac OS X, to
> >make the further cross-platform conversions easier.)
> 
> Unfortunately, starting with Mac OS X will make cross-platform 
> conversions more difficult because of the application bundle issue. 
> There are, for example, restrictions on Windows XP installations that 
> can require that modifiable files to be placed in the 
> specialFolderPath, "Documents" (or somewhere other than the folder 
> containing the standalone).

MS is finally trying to get their systems to respect file permissions.
LOL.

Thanks for the warning. We intend to have the user choose where to save
the modifiable data, so I'll have to pass this on to the boss.

And thanks for the pointers.

-- 
Joel Rees, programmer, Systems Group
Altech Corporation (Alpsgiken), Osaka, Japan
http://www.alpsgiken.co.jp
----------------------

"When software is patentable, anything is patentable." 
(http://swpat.ffii.org)



More information about the use-livecode mailing list