Search For Improved Splash Standalone

[TerryL]

Thanks to Dunbarx and Bogs for examples of an uncompiled Splash stack and Working stack on another thread. I've been experimenting with improvements.

I was hoping to use an on startup handler but I couldn't get it to work. I was surprised that the Splash.exe is not in the message pathway of the Working stack, so I tried to add it to the stacksInUse with start using, but that failed. The Working stack still has to be modified with save routines, or maybe a library stack with the saves could be added to the stacksInUse, but I didn't try that. I was unaware that a closed Splash.exe remains in memory even if its destroyStack prop is true, as long as it has at least one other stack (Working stack) added to the build. Testing for environment() allows easier editing in the IDE. If user renames Splash it still works, if user renames Working or moves it from Splash folder it quits.

Does anyone have an alternate route for a Splash strategy standalone?

This is what I came up with. Terry

Code: Select all

--For Splash Standalone Stack Script:
--1) include working stack in the build: file > standalone app settings > stacks, add stack file. Choose platform(s).
--2) compile splash stack: file > save as standalone app.
on preOpenStack
   if environment() contains "standalone" then
      close this stack  --splash's LC engine remains in memory even if destroyStack prop is true, if other stacks are in the build
      if there is a stack "Working" then  --<-ENTER YOUR WORKING STACK NAME
         open stack "Working"  --<-ENTER YOUR WORKING STACK NAME
         set the loc of this stack to screenLoc()  --center
      else quit  --remove splash from memory
   end if
   pass preOpenStack
end preOpenStack

--For Working Stack Stack Script:
on closeStack
   if environment() contains "standalone" then save this stack  --auto save
   pass closeStack
end closeStack

on commandKeyDown pKey
   if environment() contains "standalone" and pKey = "s" then save this stack  --save
   else pass commandKeyDown
end commandKeyDown

[jacque]

The splash stack is the executable and it has to remain in RAM because it is running everything else. Removing it from RAM would quit the app. When LC builds a standalone, it attaches the LC engine to your splash stack, creating a single file. Since no OS allows altering an executable, you need an independent stack file if you want to save data to it.

The independent ("working") stack will not see the executable's handlers unless you put the standalone stack in use. You were on the right path there. Typically you do that in the splash stack script:

Code: Select all

start using this stack

Do that before you open the working stack, it's a permanent part of the splash script. The startup message will be sent to the splash stack as the first message it receives after launch (you won't see it in the IDE, only in a standalone.) You can put the "start using" command in the startup handler if you want, though it can go anywhere as long as it occurs before you open the working stack. Frequently the startup handler is placed in the first card of the splash stack where it will always execute but won't get in the way of the working stack.

The working stack can have the "save" handlers, no need for a separate library for that. In fact, the working stack should contain all the working scripts, and the splash stack should have only the bare minimum to get the working stack opened. Basically, a splash stack is a smaller copy of LC with the IDE parts removed.

[dunbarx]

Jacque.

That little exposition ought to be chapter one of the much needed comprehensive tutorial on this subject.

Craig

[bogs]

I second that thought Craig, but I just KNOW you weren't thinking of heaping more work on that poor gal, were you?

[jacque]

Nah, no problem. I'm only working on three projects right now.

[bogs]

Oh is that all? Pffft, your practically lazing around then. You know, I've been thinking the entire dictionary needs a good re-write...

[TerryL]

Thanks Jacque. I tried start using with a launcher splash that stays open. That was the trick. Closing a splash and then adding it to the stacksInUse re-opens the thing. Here's my take on a launcher splash that stays open, contains the save routines, and is in the msg pathway of the working stack. Terry

Edit: Switched from preOpenStack to startup to prevent working stack access. Tested and works in Win7. Sorry Jacque, what a goof. Updated in attachment too. Terry

Code: Select all

--launcher splash stack script
on startup  --standalone only
      set the itemDel to "/"
      set the defaultFolder to item 1 to -2 of (the effective fileName of this stack)
      get files()  --files in default folder
      filter it with "*.livecode"  --keep only stacks
      sort lines of it
      set the menuLines of btn "Open Stack" to number(lines in it)
      set the text of btn "Open Stack" to it  --stack names
      hide btn "?"
      hide fld "Info"
      set the loc of this stack to screenLoc()  --center
      start using this stack  --place splash in msg pathway
   pass startup
end startup

on closeStack
   if environment() contains "standalone" then save this stack  --auto save
   pass closeStack
end closeStack

on commandKeyDown pKey
   if environment() contains "standalone" and pKey = "s" then save this stack  --save
   else pass commandKeyDown
end commandKeyDown

[jacque]

@TerryL, If the script you posted is in the stack script of the splash stack, the preOpenStack handler could potentially fire every time you open a working stack, and would put the script of every working stack in use.

If you move the preOpenStack handler to the first card of the splash stack it will fire once after startup and apply only to the splash stack. Keep the closeStack and commandKeyDown handlers in the stack script so they can respond to the working stacks.

[TerryL]

Thanks again Jacque. Yes, working stack was firing the preOpenStack handler. Edited and updated code and attachment. Terry