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

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to