A standalone HyperCard application includes what is essentially an embedded copy of the HyperCard Player. However, a standalone application, unlike HyperCard or the Player, does not have a Home stack. Rather, the stack embedded within the standalone application is its own Home stack. Therefore, the standalone's stack script must perform all the tasks the Home stack normally takes care of.
In regard to search paths, the Home stack stores a set of locations where HyperCard looks for stacks, documents, and applications. If your standalone goes to other stacks, or opens other applications or documents, you'll need to store these paths and maintain the globals that go with them. Otherwise, every time your standalone tries to access another file, it will ask the user to locate the file. To see how you need to maintain these globals, look at the getHomeInfo handler in the Home stack script.
In order to support the search paths for stacks, applications, and documents in a stand-alone application, the embedded stack needs to have three cards named "Stacks", "Applications", and "Documents". Each of these three cards needs to have a background field named "paths". This is where the search path information will be stored.
To test this, create a stack with one button which launches TeachText on the first card. Verify that it works. Then select "New Background", which creates a new card and background. Select "New Field" and name the field "paths". Then name the card "Stacks". Do this two more times, naming the next two cards "Applications", and "Documents". When the stack is saved as an application everything should work exactly the same as the original HyperCard stack had.
A good source of additional information on this topic is the book, HyperCard 2.2 by Winkler, Kamins, and DeVoto. See the chapter titled Coding for Special Environments.
Support Information Services