Kay C Lan wrote:
On Tue, Feb 17, 2009 at 6:11 AM, Richard Gaskin
<ambassador at fourthworld.com>wrote:
At the risk of pulpifying this long-dead horse, for clarity's sake I don't
believe it's the *executable• within an AppleScript applet bundle that is
being modified. AFAIK that isn't possible in any UNIX-based system.
I figured the same, and I really have no idea what's going on 'under the
hood', but I did a simple experiment. I opened ScriptEditor and put in the
following:
property theCount : 0
set theCount to theCount + 1
display dialog "The value of theCount is: " & theCount as string
If you 'Run' this over and over the dialog displays an ever increasing
number. If you recompile it goes back to 1.
I then saved it, but there are a couple of options including 'Application'
or 'Application Bundle', I used 'Application'. This produced a single file,
I tried to 'cntrl-click' to 'Show Package Contents', but this did not come
up, so this wasn't a case of an Application Bundle (a folder appearing to be
a file).
I then quit ScriptEditor and double clicked on my newly created App. It came
up with a dialog with the number 1 and then self quit. I double clicked on
it again and it said 2, etc etc. The Modification Time of the file changed
with each running of the App.
Maybe that horse isn't quite dead yet ;-)
Or maybe just a ghostly apparition from the past: it seems that when
you make an application with AppleScript (as opposed to a bundle) the
resulting file uses CODE resources (ID 0 and 1). Even knowing what a
CODE resource is makes me feel old. :)
In ancient times (read "Mac OS 9 and earlier" <g>) apps used CODE
resource for executable code. This is how HC made standalones, and even
older versions of SC and Rev, just binding the CODE and other resouces
of the engine to the stack in the data fork.
Resources are kinda like separate files, much like the files in a
bundle, in terms of being discrete elements. The CODE resources aren't
changing between runs, but the scpt resource is (poking around with
Rev's getResource function, apparently byte 651 there stores the value
of theCount).
So while these various different parts are technically in the same file,
this is merely a clever trick of the legacy file system which still
supports resource forks. As such, it's just one level of misdirection
away from being more or less the same as a bundle in terms of code and
data being separate.
In OS X apps don't commonly use resource forks, and it's only a matter
of time before the OS finally ditches them altogether. But in the
meantime, if you want to use the dual-fork trick in Rev you can store
your data in the resource fork using the setResource function.
My main point is simply that there's no special restriction unique to
Rev with regard to data storage. If another app has a way to store data
in the application, Rev can probably use the same mechanism; where Rev
can't store data, neither can any other.
--
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
