On 18/5/00 1:12 am, Scott Raney <[EMAIL PROTECTED]> wrote:
>>> We considered this, but rejected it because I've seen many stacks that
>>> change the current directory to select different sets of images or
>>> movies (e.g., to support multiple languages), something that wouldn't
>>> work if you hard-wired the image/player paths to be relative to the
>>> stack path. This isn't an issue with stackFiles AFAIK, probably
>>> because using separate *stacks* for the different languages isn't a
>>> good design. Any other suggestions?
>>
>> I get it. I do have another suggestion: search the directory first as is
>> done now. If (and only if) that results in file not found, search relative
>> to the current stack?
>
> Sounds kind of unreliable to me. Sure it may be unlikely, but what if
> the current directory happens to have a file of the same name as some
> media file you're trying to access in the folder where your stack is?
> You might get the wrong image displayed, or worse, it would display
> the right image in your development environment and then fail later on
> in the distributed version because that image really *isn't* in the
> folder with the stack like you thought it was...
An alternative might be an object property useDirectory or similar that
defaulted to the current behaviour but could be turned off? Or perhaps this
should be a global property? (I'm sure someone could think of a better name
for it anyway.)
Regards,
Kevin
> Regards,
> Scott
>
> ********************************************************
> Scott Raney [EMAIL PROTECTED] http://www.metacard.com
> MetaCard: You know, there's an easier way to do that...
Kevin Miller <[EMAIL PROTECTED]> <http://www.xworlds.com/>
Cross Worlds Computing, MetaCard Distributors, Custom Development.
Tel: +44 (0)131 672 2909. Fax: +44 (0)1639 830 707.
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
