Arrays and Custom Props

[Robert Sneidar]

I suppose where I was getting confused is that Applescript apps  
properties are persistent. I just assumed rev apps pulled the same  
kind of trick.

Bob Sneidar
IT Manager
Calvary Chapel CM
Sent from iPhone

On Feb 14, 2009, at 8:45, Jim Ault <JimAultWins at yahoo.com> wrote:

> I think people get a little confused when they think of Hypercard  
> and how it
> always saved changes to the hard drive as they occurred.  The key is  
> that
> Hypercard stacks are like spreadsheets or word processing documents  
> in that
> you needed the app Hypercard installed on your Mac, and it was  
> free.  Most
> of the time it was already installed on the Mac when purchased.   
> There was
> the issue of multiple versions through the years.
>
> Basically a Rev app could work the same way as the Hypercard app.   
> On launch
> you would give the user a choice of opening an existing 'document'  
> or stack
> or create a new one.  A spreadsheet .xls file is just a bunch of
> gobbledy-gook and data that requires the correct version of an app  
> to use.
>
> Standalones do the same thing... save lots of data to files on a  
> hard drive
> and manage the changes in formatting between versions.  "Are you  
> sure you
> want to update the format of your document to V3.4.5.6?"   "Save as
> Photoshop, Jpeg, Compuserve Gif, Tiff...."
>
> Your choice could be to do like Hypercard and Filemaker... save to  
> disk
> after every change so the user never had to make that step, thus  
> immediate
> persistence.
>
> The app, of course, does not change, just the files in its universe,  
> even if
> they are on the network, somewhere out there.
>
> As far as custom properties, recall that in my first email I  
> mentioned that
> you could store a whole stack in a custom prop.. well, this is one  
> way you
> could store a "New Stack" that opens for the user, just like Excel  
> or Word,
> or a "New card" that was not already in the user stack, or a "New  
> Group",
> etc, etc.  This way, a new stack does not have to have all of the  
> parts that
> the app does, and those are only installed when needed from the  
> mother ship.
>
> I have not looked, but there are probably some videos and help files  
> on
> bundling 'resources' with a standalone since so many Rev apps have  
> been
> created and distributed by pros on this list.  My apps are simple,
> functional, and go to private clients so I am not well-versed in wide
> distribution.
>
> Hope this makes your weekend a bit calmer.  Think about it as  
> traveling the
> oceans as millions of others do.. in a boat on the surface.  Very  
> few people
> ever use a submarine.  Revolution builds boats.
>
> Jim Ault
> Las Vegas
>
> On 2/13/09 4:42 PM, "Richard Gaskin" <ambassador at fourthworld.com>  
> wrote:
>
>> Bob Sneidar wrote:
>>
>>> WHOA THERE TONTO! I thought the whole idea to properties was
>>> persistence?? That means that I cannot save, for instance, the
>>> database settings a user entered? I have to create an external file
>>> for all of that? And so many card and object properties in my app
>>> DEPEND on persistence through runtime. This means that I have to  
>>> put a
>>> kabosh on the whole project!
>>
>> You're no worse off than any other application developer:  Windows  
>> and
>> Linux have never allowed applications to modify themselves at  
>> runtime,
>> and even Mac OS only allowed this back when it still put executable  
>> code
>> in the resource fork (though under OS X any app can store files in  
>> the
>> bundle).
>>
>> This article at revJournal may be helpful:
>>
>> Saving data in Revolution standalones
>> by Sarah Reichelt
>> <http://www.revjournal.com/tutorials/saving_data_in_revolution.html>
>>
>>
>> --
>>  Richard Gaskin
>>  Fourth World
>>  Revolution training and consulting: http://www.fourthworld.com
>>  Webzine for Rev developers: http://www.revjournal.com
>> _______________________________________________
>> 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