a new problem with standalone

[Christoph Wollek]

I had indeed set the directory:

  put the effective filename of this stack into fn
  set the itemdel to "/"
  delete item -1 of fn
  put "/" after fn
  set the directory to fn
  get the files

after replacing the "effectiv filename" with "long id" the standalone 
now works fine.
Thanks to all helping folks!

But there is another problem to be aware of (MC 2.5 / Mac OS X).

I have MChome and the other needed stacks in folder x
a copy of mchome an the others in folder y

starting MC in folder y and asking for the long id of the home stack I 
got the address of the home stack in the folder x
trying to open a stack in folder y - the stack from folder x was opened.

Is there a known problem with the domestification of home stacks in folders?

Christoph


RCS wrote:

> (defaultfolder)
> 
> I had to give up using this method (because of Linux actually). Your best
> bet is to get the long id of your startup stack, and parse the location from
> there...works without fail. 'DefaultFolder' in Linux reports the default
> 'user' folder, which has nothing to do with the engine folder.
> 
> JR
> 
>>> Please, couldn´t You give me a hint, how to get the files?
>> 
>> The files returns a file list for the current defaultfolder. When a
>> standalone starts up, the defaultfolder is the same as the one
>> containing the standalone. I just made a test application and it seems
>> to work fine. Does your script change the defaultfolder (also called
>> "the directory") before getting the files?
>> 
>> -- 
>> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
>> HyperActive Software           |     http://www.hyperactivesw.com
>> 
>> 
>> 
>> --__--__--
>> 
>> _______________________________________________
>> metacard mailing list
>> metacard at lists.runrev.com
>> http://lists.runrev.com/mailman/listinfo/metacard
>> 
>> 
>> End of metacard Digest
>> 
>> 
> 
> _______________________________________________
> metacard mailing list
> metacard at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/metacard
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.runrev.com/pipermail/metacard/attachments/20030701/79973f32/attachment.htm