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 <[email protected]> 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" <[email protected]>
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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
