Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!dan
From: dan@Apple.COM (Dan Allen)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: field limitations
Message-ID: <32578@apple.Apple.COM>
Date: 21 Jun 89 19:03:53 GMT
References: <3970@tank.uchicago.edu>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 32

In article <3970@tank.uchicago.edu> stel@tank.uchicago.edu (stelios  valavanis) writes:
>i'm in the process of making a stack and realize that one of my cards
>will have to have very many fields (or very big fields).  i though i
>saw something a while back but i can't remember.  Does anybody know if
>there is a limitation to the number of fields you can have in a card
>or to the number of chars in a field?  By the way, what i'm doing is
>making a sort of index card with a field for each day containing the
>ids of cards with info for that day.  Know what i mean?

Fields can only hold 30,000 characters of text.  A card or background
can have up to 32,767 fields, but in practice having several hundred
fields slows the system so much as to be a practical limit.

My recommendation after having done a lot with HyperCard is to have far
less: a dozen fields is my personal limit of choice.  In many
circumstances you can store your information in line 1, line 2, line 3,
etc. of a field.  You can still sort (sort by line 3 of field 1) and do
all sorts of things, although find does not allow restrictions smaller
than a field.

For the suggested task of indexing, card ids can certainly be put in a
scrolling (perhaps hidden) field and retrieved through HyperTalk.  Each
field has a 3 byte overhead per card, as well as a one-time overhead of
about 50 bytes.  (Longer if the field has a script.)

If you need 100 fields, HyperCard should work fine, but all that I am
suggesting is that if you are using that many fields, a look for
different data structuring may help the system be more efficient.

Dan Allen
Apple Computer
HyperCard Team