Arrays and Custom Props

Richard Gaskin ambassador at
Tue Feb 17 00:43:43 EST 2009

Kay C Lan wrote:

> On Tue, Feb 17, 2009 at 6:11 AM, Richard Gaskin
> <ambassador at>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:
  Webzine for Rev developers:

More information about the Use-livecode mailing list