Making a stack a custom property of a stack

[Richard Gaskin]

David Glasgow wrote:
> A while back Klaus was kind enough to spend some time describing how  
> to do this and then use any stack stored in this way.  I was  
> impressed at the time, and still am.
> 
> In fact this is such a Very Good Thing, I want to suggest that it  
> should be an explicit part of the IDE.  I know that would only make  
> it marginally easier to do, but it would make it a darn sight more  
> obvious to new users.  I do enjoy the ongoing discovery of Revs  
> flexibility and power, but can't help thinking that in this case the  
> gem would have been useful to me way back at the beginning of  
> learning Rev.  I had settled on a world picture that allowed  stacks  
> which are modifiable and standalones which are not, and to use the  
> former they have to be installed as  stacks when the end user  
> installs the whole package. The stack as stack custom property  
> changes the game completely, without breaking any rules.  Great.  But  
> not obvious.
> 
> I have in mind a variant of the custom property tab which would  
> display and manages stacks 'banked' within the current stack,  
> avoiding the scripting Klaus described.  I don't want to go mouthing  
> off to the nice folks in Edinburgh if this isn't such a good idea, so  
> I would be interested in the thoughts of the wise...

It's handy when you need it, but outside of making installers it's not 
very commonly used.  Since stack files can contain any number of 
substacks, most operations just use the clone command on a substack to 
create instances; setting the clone's fileName property and then issuing 
a save command on it will create a new stackfile from the clone.

In the old SuperCard days we used to call this SuckUp and SpitOut, 
unsavory but memorable handler names. ;)  Since SC's read/write mode was 
always binary, we never had to worry about the mode of the open file so 
it was pretty straightforward to do.

While we ponder whether to include these in the IDE libs, perhaps these 
may be candidates for inclusion in stdLib.rev, a collaboration of the 
Rev Interoperability Project (with better names, of course):
<http://tech.groups.yahoo.com/group/revInterop/>

Feel free to run it up the flagpole there if you like.  I'd vote for it, 
and it would take only a little time to write the handlers for it to 
include optional compression and even encryption if desired.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  Developer of WebMerge: Publish any database on any Web site
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com