TALLEY-J@osu-20.ircc.ohio-state.edu (James T. Talley) (02/15/90)
I have noticed that you can set the name of a card to some fairly long strings (>30 characters), but that the "go" command stops functioning for cards with names longer than 29 characters. In other words, put "This is a test of rather long card names" into x go to cd x will _not_ take you to the card named "This is a test of rather long card names". I've verified the name of the card with the "put" command so it's not the case that there is no such card. Is this a known limitation? Should I limit my card names to 29 or fewer characters? Is this also a problem with field, button, and background names? (Obviously a stack name can be no longer than a valid file name.) Should I RTFM? If so, which FM? :-) James
ba0k+@andrew.cmu.edu (Brian Patrick Arnold) (02/15/90)
Mr. Talley writes (abbrev): >you can set the name of a card to some fairly long strs (>30 chars), >but the "go" command fails for cards with names longer than 29 chars. It applies to all HyperCard objects. I first noticed this problem when trying to reference a button with a very long name in a handler. That handler was just trying to name the button by a string and then reference it by name. That was fun to debug. "Never heard of button named" by the name it was freshly given. Sonova...frickin.... INFORMAL POLL ---- E-Mail me your vote "yup" if you like to exploit names of HC objects. Who tends to use the name of an object for reasons such as matching names of buttons to cards etc., or to hold other navigational or otherwise bizarre pieces of information? How successful have you been? E-Mail me your vote "nope" if you avoid names like the plague. Who steers clear of dependance on the name as a place to store things and especially as a way to reference HC objects and in navigation? ---- If more than 10 people respond, I will summarize the results. It seems to me that it's really easy to try to "store" non-trivial information in name fields that comes back to haunt developers of reasonably large stacks. I blame this on the fact that developers can't assign attributes of their own to HC objects without smoke and mirrors. For example, I tried to use the button name to hold the name of a "model" card concatenated with the name of a "variable" card which were cards in different bkgnds. I feared that with 100's of btns and cards, indirection through storage of names in bkgnd field lists would be "slow" (relative term). It works as long as the net string length is under 29 chars. I just want to confirm whether I've been a dorky programmer or whether a lot of people do funny things with names of HC objects. How many people have tried to store numbers in or as parts of names (I've tried this, don't be shy). I'm especially interested to hear from people developing stacks where users dynamically create cards and multiple-card links as a result of a user's simpler actions. Peeve #504873: When HyperCard fails from too much recursion, it doesn't lead you into the script of the responsible recursor - it leads you into the script that had the handler guilty of overflowing its HyperTalk handler/function stack, somehow imagining that that handler had to be the recursive handler. It is very painful to be told that a handler that never recurs on itself even indirectly is guilty of too much recursion. This problem is not affiliated with the one where you accidentally use "go" in an openCard handler. - Brian
jk3t+@andrew.cmu.edu (Jonathan King) (02/15/90)
TALLEY-J@osu-20.ircc.ohio-state.edu (James T. Talley) writes: > I have noticed that you can set the name of a card to some fairly long > strings (>30 characters), but that the "go" command stops functioning > for cards with names longer than 29 characters. In other words, > > put "This is a test of rather long card names" into x > go to cd x > > will _not_ take you to the card named "This is a test of rather long > card names". [...] > Is this a known limitation? Should I limit my card names to 29 or fewer > characters? Is this also a problem with field, button, and background > names? (Obviously a stack name can be no longer than a valid file name.) > Should I RTFM? If so, which FM? :-) The FM to read is, as usual, the Apple (r) HyperCard (r) Script Language Guide: The HyperTalk (r) Language. Published in 1988 by Addison-Wesley as one of The Official Pulbications from Apple Computer, Inc., the book lists for $23.00 and is worth every cent. (The ISBN is 0-201-17632-7). Without this book, you continually run into bizarre features of HyperCard and bang your head against the wall. With this book you will still run into bizarre features of HyperCard, but at least you can look them up in the FM. The fact that most names are limited to *31* characters is listed with the other HyperCard limits on pages 267-8 of the HCSLG. "But", you say, "names fail at 29 characters!" Yes, but this is HyperCard: twenty-nine characters and two double quotes make thirty-one, you see...but I've ranted before about strings and quotes and names. I have to add, however, that this problem would be just a curiosity if HyperCard had real data structures, since people wouldn't be tempted to use long names as containers. Maybe HyperCard 2.0 will have better data structures to go along with the promised Mr. Coffee drivers. jking
tim@hoptoad.uucp (Tim Maroney) (02/16/90)
In article <12566361650019@osu-20.ircc.ohio-state.edu> TALLEY-J@osu-20.ircc.ohio-state.edu (James T. Talley) writes: >I have noticed that you can set the name of a card to some fairly long >strings (>30 characters), but that the "go" command stops functioning >for cards with names longer than 29 characters. In other words, > > put "This is a test of rather long card names" into x > go to cd x > >will _not_ take you to the card named "This is a test of rather long >card names". I've verified the name of the card with the "put" command >so it's not the case that there is no such card. Yes, this is a major pain, and I sure hope HyperCard 2.0 fixes it. I constantly run into cases where I need to have card names like Button "Wanna Buy a Duck?" of Card "Honk" of Stack "Duck Soup" (from a script editor stack) and The Goetia of the Lemegeton of Solomon the King (from an occult dictionary stack). The card names are stripped to 29 characters, but the "go" command does not do a similar stripping, so that even if the first 29 characters are unique, you can't use the "scrolling text field as index of cards" approach without some extra hacks. And if they aren't unique in the first 29 characters (as could easily happen in a script editor stack), may "Bob" have mercy on your soul. We really need to have either unlimited card names, or card names which can be longer than almost anyone would need (say, 255 characters). 29 is nowhere near long enough. By the way, since HC2.0 is almost in beta, would it hurt Apple to finally give us a canonical features list? The reasons they hesitate to do so during development and alpha are sufficiently obvious that even Chuck what's-his-name can figure them out, but presumably the features are pretty well frozen at this point. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Please help support the moratorium on meaningless quotes in .signatures." -- Doug Asherman on rec.music.cd