open stack finds stack in wrong path!?
Devin Asay
devin_asay at byu.edu
Mon Jun 15 13:56:40 EDT 2015
On Jun 15, 2015, at 10:37 AM, Tiemo Hollmann TB <toolbook at kestner.de> wrote:
> Hello,
>
> LC 6.5.2, OS X 10.9. I have a splash stack and a main stack. The mainStack
> is located at the regular place on the same level as the executable within
> the app bundle.
>
> Because this software runs directly from CD and there also is a windows
> version on the CD, there is a copy of the mainStack on the same level, as
> the app bundle in the root of the CD, which is used from the windows exe.
>
> On OS X I open the main stack with: open stack (item 1 to -2 of the
> effective filename of this stack & slash & "mainStack.rev"). The splash
> stack opens correctly the mainStack in its bundle, only as far there is no
> copy of the mainStack on bundle level. But as soon there is a copy of the
> mainStack in the bundle directory (for windows use), the OS X program
> ignores my given path within the bundle and opens the mainStack from the
> bundle level, which I don't want to be used on OS X.
>
> Is there any secret hierarchy for looking for stackfiles and ignoring given
> paths? Or am I overseeing something obviously?
Tiemo,
On OS X looking for a stackfile relative to the location of the .app bundle will look inside the .app bundle, as you have seen. But if you don’t try to find a stackfile relative to the .app, it will look first in the folder that contains the .app bundle. I think you can work around your problem by including this in the preOpenStack or openStack handler of the splash stack/app:
if the environment is “development” then
go stack item 1 to -2 of the effective filename of this stack & slash & “mainStack.rev"
else
go stack “mainStack.rev”
end if
Why? Because once the stack is made into a standalone the defaultFolder becomes the folder containing the .app bundle. It should therefore work in both the Mac and Windows environments.
I hope I understood your problem correctly.
Devin
Devin Asay
Office of Digital Humanities
Brigham Young University
More information about the use-livecode
mailing list