Embarrassed Newbie

[dunbarx]

Thanks, Richard, et. al.

Funny, I supposed, like usually happens in Rev, that there was a command that did that directly, as I said:

 "place group groupName in all/this/marked cards




On Feb 23, 2009, at 8:46:13 PM, "Richard Gaskin" <ambassador at fourthworld..com> wrote:
From:   "Richard Gaskin" <ambassador at fourthworld.com>
Subject:    Re: Embarrassed Newbie
Date:   February 23, 2009 8:46:13 PM EST
To: "How to use Revolution" <use-revolution at lists.runrev.com>
DunbarX wrote:

> OK. I get groups. And I see the additional flexibility as opposed to the 
> fixed bg object class in HC.
> 
> So how (without a repeat loop that places a group on every card) does one 
> place a newly created background group on every card? That is, if you already 
> have a stack with 5000 cards, how do you put your brand new group (bg) on each 
> one? All doc emphasis is that a bg copies its objects onto newly created cards, 
> not the other way around. I don't see a "place group yourGroup on all cards" 
> variation of the "place" command, though it seems there should be.
> 
> This was easy in HC, one just moved the object(s) to the bg, which already 
> exists, comforted to know you can access it at any time. Or not; groups as a 
> substitute for bgs in some ways almost seem too insubstantial, though they seem 
> powerful as local objects. Rev should have bgs as well as groups. It seems the 
> group concept itself requires more careful initial planning when starting to 
> design a new stack.

Is this stack imported from HC? If so there should already be a bg on 
each card, and you can placed your new controls there.

If not, writing a "place" loop won't take but a minute.

A bigger concern might be the 5000 cards, which is what led me to 
believe this might have been imported from HC. Do you expect it to grow 
much more?

One of the weaknesses of Rev is when the card structure is used as a 
database. Even Bill Atkinson said ,"HyperCard is not a database", but 
then didn't stop people from using cards that way, and since it paged in 
only the cards it could keep in memory it wasn't bad for some of that. 
But with Rev, you'll find having that many cards will have a noticeable 
performance degradation with saves and some other operations.

You can likely reduce overall stack size, simplify your development, 
boost performance, and increase scalability by considering moving your 
data from fields on cards to custom properties in a single-card stack.

It may sound much harder than it is. If it seems daunting, let's 
discuss that and see if we can get some handlers together for you to 
make it a snap.

--
Richard Gaskin
Fourth World
Revolution training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution