Saving stuff in a standalone

Ken Ray kray at
Sat Oct 12 23:22:01 EDT 2002


You have a lot of questions, and I'll try to answer them as best as I can.
I've used xTalk languages since HyperCard 1.0 so I know where you are coming
from... the idea of a "standalone" really didn't hit the scene until almost
the end of HyperCard's existence; so many people were just using the Home
Stack as a launching ground for getting to their own stacks, that it didn't
seem to be very important at the time, since HC was distributed for free
with new macs, you could be assured that everyone had it, so why make a
standalone? Why not just give 'em your stack and let them double-click it?

However times have changed since then, and we're using a tool that allows us
not only to distribute applications that look and act like "real" apps
(something HC had a lot of trouble with), but also across platforms as well.

So here goes my comments:

> Topic 1:
> Postponing the question of implementation for a moment, I'm am sure that
> I do not understand the metaphor of how the external files (stacks or
> text) are actually utilized.  In a simple database arrangement with a
> standalone as a front end, is all the data from the external file loaded
> at once , in effect creating a new card for each record when the file is
> loaded with say a thousand or so cards now held in memory?  Or is the
> standalone only comprised of one (or more) "template" cards which load
> the data stored in the external file one at a time as needed and stores
> newly created or revised data one record at a time in a similar manner?
> If the latter is the case, how would one go about searching and indexing
> such data; reasonably straightforward tasks IF the data is stored in the
> stack as in a traditional Hypercard arrangement?

OK. Think about a simple address book stack (like the one that came with
HC). All the data was stored on cards, and if you made a new card, filled in
the fields and quit, your data was saved. Simple. However now, if you make a
standalone, you can't modify the contents of the standalone, so how can you
save your data? There are a number of methods, but the simplest one is as
follows: Using the Address Book stack as an example for a moment, imaging
that your "standalone" is nothing more than an application (like the
HyperCard application was) to launch your stack. So if you create *two*
stacks, one small one that you will turn into a standalone application, and
a second one that will be "opened" from the standalone and contains your
Address Book cards, you are set... the application can't modify itself
(which is good since there's no need to in this example anyway), and the
plain "stack" which is opened by the standalone, can modify itself as much
as it likes. So your "stub" stack simply says:

  on openStack
    open stack "Address"
  end openStack

In your Address Book stack, the only thing you'll need to do a bit
differently than in the HC days is that you need to explicitly save changes
to your stack before quitting, with "save this stack", otherwise changes
won't be saved. However the construction of the Address Book stack is nearly
identical to the original HC one (background fields that are shared across
cards, etc.).

The concept of saving data in external files would be the same as in HC..
that is, you can open/close and read/write to text files to save data,
however this is usually used just for simple text storage (initialization
settings, configuration data, export data, etc.). It's more complicated to
map an external text file to the field structure of a multi-card
database-like stack (although you can do it with delimited data). The nice
thing about Rev in this case is that you can shortcut the reading and
writing of text files with the "put url into" and "put into url" commands.
So instead of this:

  open file "Mydata.txt"
  read from file "Mydata.txt" until eof
  put it into tData
  close file "Mydata.txt"

You have this:

  put url ("file:Mydata.txt") into tData

And the opposite is true:

  put tData into url ("file:MyData.txt")

... to write.

The nice thing about Rev is that you also have access to saving data in an
actual database (mySQL, ODBC, etc.) using the revDB external... if your data
management needs are high, you might look into this.

> I would also like to see a similar tutorial stack illustrating how
> RunRev can be used as a front end for a FileMaker database which I
> surmise could be used to store, search and print/report the data as
> needed.  When I previously asked for this on the list I was told this
> was easy and referred to 1 or 2 websites, but I was not able to locate
> the promised Rev to FileMaker sample stack.
> Significantly ore detailed help on both of these topics would be greatly
> appreciated.

First of all, I don't know if Rev can "front" for a FileMaker database
(unless it is done through AppleScript or if it is ODBC compliant... I
haven't used FileMaker since FileMaker Pro, so you can tell how dated I am).
I *do* know, however, that it can front for an ODBC database... I wrote a
'head-to-head' between Rev and Visual Basic that communciated with an ODBC
database. I is completely open so you can examine the source code. It is
normally at:

although I just went there, and for some reason it's not there...
(Kevin/Heather? Can you tell me why it's not there?)

Anyway, there are people such as Tuviah Snyder who are more eloquent at
explaining the ins and outs of using the revDB external, so I'll leave this
in the hands of others more qualified. I agree with you that there should be
tutorial stack on this, and it may very well be in the next version of Rev,
which should be out this year (I believe).

> Topic 3:
> So here's the question: can dynamically changing custom properties be
> saved within a standalone application?  If not (as I suspect), and
> saving changes to custom properties are subject to the same prohibition
> as ordinary data within a standalone, what is an efficient way to store
> these external to the standalone and easily access them when they are
> needed?  My guess is that, like many things in RunRev there is a
> relatively simple answer to this question, but, at least to me, it is
> neither obvious nor intuitive.  Once again detailed help would be
> appreciated.

The answer is similar to Topic 1... you either (a) save custom properties in
a stack that is accessed by a standalone, or (b) you can store your
"components" as separate stacks which are called by either a standalone or
other stack, or (c) you can store your components" as a substack of a stack
that is accessed by a standalone. Something like an "ask list" utility would
be better served as a separate stack that one did a "start using" on, so
that in a script that said "askList <stuff>", it would be sent to the "ask
list" stack so it could field it. If this is not clear, let me know and I'll
expand on what I mean.

> Topic 4:
> This is not the behavior I would normally expect from a Mac
> application - i.e. when double-clicked, a Hypercard stack would normally
> open the Hypercard application with all available features consistent
> with the User Level set in the Home stack or modified by a set userLevel
> script within the stack being opened.

True, although if you think about it from the perspective that a Rev stack
is a "document" of the Rev "application", it makes more sense.
Double-clicking a Word document launches Word and opens the document for
editing... it doesn't go into Preview mode. Similarly, double-clicking a Rev
document launches Rev and opens the stack for editing with the pointer tool.
> I have also noted that whenever I first start Revolution the application
> opens with the Pointer tool as the default setting.  What's going on
> here?  Is there a simple way to make double-clicking on a stack open the
> Revolution application with the browse tool selected as the default
> setting?  What I'm trying to achieve is to have Revolution open in a
> mode roughly equivalent to the "Typing" or "Painting" user level setting
> in Hypercard.  The idea here is to perhaps be able to use a Starter Kit
> version of RunRev as runtime engine for stacks that have not been built
> as standalone applications - but not to give unauthorized users the
> capability of mucking around with the inner workings.

I agree with Troy that you don't want to think in the HC mindset right
now... i.e. that you give people a kind of Player and then distribute your
stacks with it. A Player idea has been bounced around on the boards, but
until a "real" Player is created, you should probably think about
distributing standalones only, or creating your own kind of standalone
"player"(see Topic 1).

Hope this helps,

Ken Ray
Sons of Thunder Software
Email: kray at
Web Site:

More information about the use-livecode mailing list