Page 1 of 1
Search For Improved Splash Standalone
Posted: Thu Jul 20, 2017 8:13 pm
by 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
Re: Search For Improved Splash Standalone
Posted: Fri Jul 21, 2017 8:21 pm
by 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:
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.
Re: Search For Improved Splash Standalone
Posted: Sat Jul 22, 2017 1:46 am
by dunbarx
Jacque.
That little exposition ought to be chapter one of the much needed comprehensive tutorial on this subject.
Craig
Re: Search For Improved Splash Standalone
Posted: Sat Jul 22, 2017 3:48 am
by bogs
I second that thought Craig, but I just
KNOW you weren't thinking of heaping more work on that poor gal, were you?
Re: Search For Improved Splash Standalone
Posted: Sat Jul 22, 2017 4:14 am
by jacque
Nah, no problem. I'm only working on three projects right now.
Re: Search For Improved Splash Standalone
Posted: Sat Jul 22, 2017 11:35 am
by 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...
Re: Search For Improved Splash Standalone
Posted: Sat Jul 22, 2017 7:42 pm
by 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
Re: Search For Improved Splash Standalone
Posted: Sat Jul 22, 2017 8:41 pm
by 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.
Re: Search For Improved Splash Standalone
Posted: Sat Jul 22, 2017 11:04 pm
by TerryL
Thanks again Jacque. Yes, working stack was firing the preOpenStack handler. Edited and updated code and attachment. Terry