Saving stuff in a standalone

[Alan Gayne]

Hi to Ken, David, Jan, Yves and all others who responded to Tim Hart's 
questions regarding the techniques for saving data generated out of 
standalone apps built in RunRev.

As a Hypercard user back to 1987, the idea of a standalone stack is 
pretty much foreign to me, even though I think HC was supposed to have 
had some form of this capability since back in version 2.2.  Most of 
what I used HC for was as a number of business database applications, 
each usually with several thousands of cards but no fancy stuff like 
multimedia content.  In combination with Reports DataPro's printing, 
high speed search and index capabilities I was pretty much able to get 
this combination to do everything that I needed to get done in my 
business.  And since it was for MY business, over the years, I was 
constantly tweaking the interface, performance and output as the need 
would arise.  In any case all of my data was stored in my "application" 
stack - with HC always running in the background which also allowed me 
convenient access to other useful stackware created by others.

In the short time I've been playing with RunRev I've come to believe 
that over time I will be able to generate within the RunRev environment, 
most if not all of the "off-the-shelf" tools and goodies, available as 
"externals" for HC and the absence of which I had lamented on the list a 
few weeks ago.

As a result and in good faith reliance on the RunRev team's  promise of 
a "soon to come" report generator, I'm now just about ready to start 
thinking about recreating the business apps which have become absolutely 
essential to my business.  I said "recreate" rather than duplicate since 
RunRev clearly has far more inherent capabilities than did poor 
HyperCard, so horribly neglected by Apple.

So here's my dilemma, what is the most efficient strategy for storing 
the data of my RunRev  apps; and how do I actually implement such a 
strategy.

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?

Topic 2:
As to implementation, I have checked out the Revolution documentation 
suggested by David Vaughn but I can't seem to find the "considerable 
guidance" on the topic which he promised. What the heck am I missing?  
Is there a small step-by-step tutorial stack that would explain the 
concepts and illustrate the techniques of just how this is 
accomplished?  Such a tutorial stack need only contain a few fields and 
10 or  20 cards  (or records as the case may be) to do this.  It seems 
to me that such a basic issue should have been addressed in clearer and 
more complete manner in the documentation, but I can't seem to find this 
in either the online or printed documentation.

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.

Topic 3:
As I believe I mentioned earlier, I have been working on a variety 
useful user interface tools which are essentially involve a bit of 
"reverse engineering" many of the external goodies provided for 
Hypercard by the Reports DataPro package.  Some of these are used to 
input specific data types into any given field, such as several calender 
dialogs and user editable "askList" functions.  Others provide a number 
of search and sort as well as indexing functions.  Those of you who have 
worked with Reports DataPro will know the kind of stuff I'm talking 
about - a group of very useful tools, implemented as externals, with a 
consistent user interface and scripting approach, and which we did NOT 
have to build ourselves since they were already available in a nice neat 
reasonably priced package.

The good news is that with a little thought I have indeed found that 
most of these goodies can also be implemented as RunRev stacks which can 
be added as substacks to most RunRev projects and called as modal 
dialogs.

Aside from getting the tools I need, creating such items have served as 
a great tutorial in using Revolution to do things simply not possible in 
Hypercard.  Once again, many thanks to those list members who were kind 
enough to answer my newbie technique questions.  And yet this activity 
has led me to another question on the topic of where certain data should 
be saved.

My "askList" function, which I've "reverse engineered" from the NTFList 
function (external) from Reports DataPro provides a good example.  This 
is basically a list function which returns the chosen item or items to 
the field from which the modal dialog is called.  The list itself may be 
user editable and the contents stored as a text resource of the stack.  
In my RunRev version the list function is a substack called as a modal 
dialog, with the list contents, prompt phrase, etc. stored as custom 
properties of the field (in the mainstack)which called the function, 
usually from a mouseUp handler.  This way the list contents, prompt and 
edit permission for the list function change dynamically depending on 
the field from which it is called.

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.

Topic 4:
In the course of developing my first stacks I have noted two phenomena 
on which I would like a little help.  The first of these: when I 
double-click on a RunRev stack when the Revolution environment is not 
already running, the stack which has NOT been built as a standalone, 
opens essentially as a type  "standalone" with none of the resources of 
the Rev development environment.  The only menu available is titled 
"Revolution" and the only applicable menu item is "Quit".

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.

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.

Coda:
So there it is (for now).  I'm sorry to have been so long winded but I 
wanted make my questions sufficiently detailed so that the members of 
the list would know exactly the kind of help I was looking for.

Thanks in advance for your patience and help.

Alan Gayne