stel@tank.uchicago.edu (stelios valavanis) (06/20/89)
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? stel -- Bitnet: stel%tank.uchicago.edu@uchimvs1.bitnet | i don't know Internet: stel@tank.uchicago.edu | YOU don't know? uucp: ...!uunet!mimsy!oddjob!tank!stel | ok, so i don't know
dan@Apple.COM (Dan Allen) (06/22/89)
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