Using a Splas screen

Joe Lewis Wilkins pepetoo at cox.net
Sun Sep 21 13:21:04 EDT 2008


Hi Tom,

Thanks for your fine, detailed explanation. I always understood the  
problem, but the splash screen solution seemed so convoluted that I  
have, stubbornly, refused to go in that direction. It would seem this  
old dog needs to learn a new trick - or two. (smile) I still like the  
idea of developing a program in the IDE as a single stack and then  
adding the splash stack at the end, probably as the "About  
Application" feature most of us use anyway.

Joe Wilkins

On Sep 21, 2008, at 9:33 AM, Thomas McGrath III wrote:

> Hey Joe,
>
> I got confused by this at first in building standalones. You're not  
> alone. ;-)
>
> You may already know some of this but for anyone following this  
> thread it might help.
>
> OK, So you want to build an application that can save 'apparent'  
> document files. Why, because on most Operating systems the actual  
> application itself can not be modified while running, so it can't  
> save itself. OK, so the answer is to build an app that can store  
> things in another document(stack) instead, thereby not changing  
> itself but rather it is changing the 'other' document(stack) which  
> is not self running.
>
> OK, so in Revolution we use stacks for most everything so our  
> 'document' is actually a stack and our 'application' is actually a  
> stack too. The problem you ran into is that the standalone/ 
> application has the cards that you want to save in it and it is  
> actually the 'document' stack that should have the cards that you  
> want to save. (You have your 50 cards in the wrong stack if you want  
> to save them easily)
>
> For the most part most people will build either a splash screen  
> stack as the non-editable application stack or a minimal application  
> stack that has most of the 'engine' of your application and then use  
> another stack as the savable stack or document stack. If you do it  
> this way then all of the 50 cards should NOT be in the application  
> stack but rather in the document stack. Then when you open your  
> standalone/application stack as a running application it should then  
> open the separate documentation stack after loading and then right  
> away from your standalone application you should save that just  
> opened stack under a new name. This ensures that the original is not  
> written over by your stack or the user.
>
> Now that the document stack is saved (from the application stack)  
> any and all changes made to that stack will be saved when you issue  
> the save command.
>
> So, incase your stack crashes etc. you should have a save command on  
> quit and on close etc. to ensure the best chance the stack is saved.
>
> I hope this helps and explains the issue.
>
>
> Tom McGrath
>
> On Sep 21, 2008, at 11:30 AM, Joe Lewis Wilkins wrote:
>
>> I guess this is my day for confusion. (smile) I'm not using a  
>> player for any of this.
>>
>> I have a fairly simple stack consisting of some 50 cards, each of  
>> which has one or more images and some fields and/or buttons. Using  
>> the bucket tool, a user may color inside the lines of the images as  
>> they see fit - often pretty complex. Once colored, they may print  
>> portions of the cards that I designate in the print routine; but,  
>> once the stack is closed, all of these colorations disappear. I  
>> would like for them to be able to Save a copy of the colorized  
>> stack under a new name, as a document?, from the standalone. Then,  
>> as you have indicated it can, have that copy open as a document  
>> "of" the standalone when double clicked upon. So far, I've used:
>>
>> 	case "Save..."
>>        answer "Save Coloring Book?" with "Cancel" or "OK"
>>        if it is "Cancel" then exit menuPick
>>        save this stack
>>     break
>>     case "Save A Copy As..."
>>        answer "Save a Copy of this Coloring Book?" with "Cancel" or  
>> "OK"
>>        if it is "Cancel" then exit menuPick
>>        clone this stack
>>        save stack ("Copy of "&(the effective name of this stack))
>>     break
>>
>> This kind of works, but doesn't result in a separate stack that  
>> contains the colored images; just the same as the original, "plain"  
>> images stack.
>>
>> Thanks for all your comments.
>>
>> Joe Wilkins
>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

--
Please avoid sending me Word or PowerPoint attachments.
See   <http://www.gnu.org/philosophy/no-word-attachments.html>
----------------------------------------
Joe Lewis Wilkins
pepetoo at cox.net








More information about the use-livecode mailing list