Some Basic Misunderstandings/Problems with RunRev - aka Help!

David Burgun dburgun at dsl.pipex.com
Wed Apr 14 14:51:29 EDT 2004


>On 4/14/04 1:03 PM, David Burgun wrote:
>
>>Then PLEASE could someone just tell me how I save a Standalone 
>>Stack PLEASE!!! I've been asking questions about this all day and 
>>I'm just going round and round and round in circles.
>
>There is an OS restriction in Windows, in all varieties of Unix, and 
>in OS X that forbids an application from saving itself. This isn't a 
>Rev limitation, it is in the OS. The only operating system that 
>does/did allow an application to be saved is OS 9, which is now 
>going obsolete. To retain consistency, Rev simply doesn't allow even 
>OS 9 standalones to alter themselves and save themselves to disk. 
>So, a built standalone cannot be saved under any circumstances. 
>Since no other operating systems allow it, and since almost all OS 9 
>applications outside of HyperCard do not save to themselves, it is 
>mostly only ex-HyperCard users who find this to be a disadvantage.

Thanks I realized this, but I thought that there was a built-in way 
of getting around this. For instance, the RR kernal/engine or 
whatever it's called, could copy the App to another file and then 
save to this file. There are a number of ways this could work. I'm 
not saying that this is a better way than how it's done now, I just 
assumed (since nothing in the save stack docs said differently) that 
it was taken care of for me.

>That being said, there are ways around it, and these methods are 
>what all other developers use for all other apps. Basically, you 
>keep the standalone separate from its data. You can do this in two 
>ways, but both ways require that you have two files on disk: the 
>standalone, and some kind of data repository.
>
>The first way is to write the data to a text file. When the app 
>closes, it saves the data to the text file, and when it opens it 
>reloads the data. Since you've mentioned that you have a lot of 
>controls and cards, this probably isn't the best way for your 
>situation.

Agreed.

>The second way is to just save the stack itself as the data 
>repository. When you do that, it functions exactly as HyperCard did. 
>Your standalone becomes the equivalent of the HyperCard Player, and 
>your stack runs as an independent stack which can easily be saved. 
>That's how I'd suggest you do it. It will mirror the experience you 
>had in HyperCard.

Actually I've never used HyperCard! I'm a C/C++ programmer usually 
but decided to take a RunRev sabbatical which I am (mostly) enjoying!

I really like RR  the only critisism I have is the lack of 
documentation on how to put all the pieces together. There are 
command things that a lot of RR developers must want to do that just 
don't seem to be covered. Either a document or a  sample Stack setup 
with a separate Standalone and "data" stack as you describe would 
have been of so much help.

It's really, really difficult to piece it together from the 
Dictionary, mainly because they doesn't seem to be any examples of 
how to practically use a command in context with other commands.

>To do that, create a one-card stack with almost nothing in it. Most 
>people use a splash screen image on the first card. That way when 
>the app opens, users will see the splash image for a moment before 
>your actual stack opens. This is the stack you would make into a 
>standalone. It contains no data, just your splash image. The first 
>card should have a handler something like this:
>
>   on openstack
>    wait 3 seconds
>    go stack "myDataStack"
>   end openstack
>
>Users will double-click your standalone, see your splash image for a 
>few seconds, and then your data stack (called "myDataStack" here) 
>will open. After that, the stack functions as you expect and you can 
>save it at will with this command:
>
>   save this stack
>
>Does that help?

Yes! It really does help a lot. I was just about getting there with a 
lot of help from others on the list.

I have posted a couple of additional questions in another message 
sent before I read this one, but as far as I can tell, from what you 
have said, it should all work ok.

Thanks Again
Dave


More information about the use-livecode mailing list