Updating Data Substacks

Dan Shafer dan at danshafer.com
Fri Jul 12 01:15:01 EDT 2002

>If nobody minds me putting in my 2 eurocents..
>--- Scott Rossi <scott at tactilemedia.com> wrote:
>>  Recently, Dan Shafer wrote:
>>  > It just occurred to me that the RR model which
>>  requires me to create
>>  > a separate stack to hold the data for my app might
>>  be an obstacle to
>>  > product upgrades.
>>  >
>>  > My mainstack is a splasher. My substacks are a
>>  palette (which can
>>  > change) and the primary data stack (which will
>>  change). If in my next
>>  > rev of the product, I wish to add features (e.g.,
>>  a menu or even a
>>  > button on that stack with some new functions), I
>>  would expect to ask
>>  > my users to replace their current stack with the
>>  new one. But that
>>  > will, obviously, result in the loss of all their
>>  data.
>>  >
>>  > How should this work? What am I missing?
>>  Two options I can think of:
>>  Good) Keep your data separate from the UI.  This way
>>  you can update the UI
>>  independently of the data.
>I'd have to second this approach. Have the data in a
>substack that you can easily edit all the data
>(including more low-level content that you don't
>usually display on-screen) in case something has gone
>wrong ; have the UI in another stack, and 'on
>openCard' fetch the necessary data from the
>This approach also means you don't have to go about
>devising your own file format.

Ah, I see your plan. Intriguing. So rather than a splasher and a 
"traditional" HyperCard-style stack containing UI and data, have the 
mainstack be the UI stack which has no data in it (and can't be 
updated by default) and then have an invisible stack that just stores 
the data card by card. Hmmm. I'll have to ponder this. It may be a 
great solution, though.

Thanks for the thought.

>  > Not So Good) If you really want to keep the UI and
>>  data in the same stack,
>>  include an "export data" option or similar in the
>>  stack.  When a user wants
>>  to upgrade they hit "export" and then import the
>>  exported data into the
>>  upgrade stack.
>As at times you'll have to provide some sort of data
>"update" procedure, you could do this either via an
>export/import, or -- pretty interesting imho-- with
>the use of 'create field' for what is new in your data
>I recall having made an update script in HC for this
>sort of thing. It looked something like:
>   put "Updating data file... (This may take a while)"
>   lock screen
>   doMenu "Background"
>   select field tool
>   doMenu "New field"
>   put the number of bg fields into theLastOne
>   set the name of fld theLastOne to "Something"
>   set the topLeft of fld theLastOne to theTopLeft
>   ... etc ...
>Especially the whole workaround of having to select
>the field tool to get to the "New field" menu makes me
>ever so grateful for the create command in RR :-)
>Hope this helped a bit,
>Jan Schenkel.
>"As we grow older, we grow both wiser and more foolish
>at the same time."  (De Rochefoucald)
>Do You Yahoo!?
>Sign up for SBC Yahoo! Dial - First Month Free
>use-revolution mailing list
>use-revolution at lists.runrev.com

Dan Shafer
Technology Visionary - Technology Assessment - Documentation
"Looking at technology from every angle"
831-392-1127 Voice - 831-401-2531 Fax

More information about the Use-livecode mailing list