First let me say that the 8.1.2 compile time is orders of magnitude improved! WOW what a difference. It was taking me 20 minutes to save as standalone, now it's under a minute. AWESOME! Now on to my tests.
Okay I see what is happening. In the IDE the mainstack of a substack is the actual stack file. But when a splash stack is used to create a standalone, THAT becomes the mainstack of the standalone! This sucks of course, because now I have to go back to every instance where I reference the mainstack of this stack and hard code the name of the "actual" mainstack where all the properties are stored. And while I am relieved that I have finally tracked down a stubborn problem I didn't even know I had, this is going to cost me alot of time to rectify. I wish this had been clearer before I attempted to start building standalones. It's been my whole understanding of the use of splash stacks that the stack used to create a standalone is read only, and therefore cannot be a stack you set properties of, or make any changes to. I had no idea it became the mainstack in a standalone. This fairly torpedoes my whole portability concept where I go to a substack of a mainstack and perform some actions, finally setting some properties of the mainstack. In retrospect now, I can see why seasoned livecoders don't go in much for the concept of substacks. However convenient it is to have a single stack file with all the substacks included, it appears I can no longer do this. I have made extensive use of the mainstack properties as a kind of "application global" storage to avoid conflicts between applications open simultaneously, with the same "setup stacks" embedded. I can see I am going to have to come up with an entirely new way to do this. Bob S _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
