awl@extro.ucc.su.oz (Tony Locke) (07/18/89)
I'm interested in messing around with index stacks in hypercard. Using the "link to" feature you can do a reasonable job of linking related records together (in true "goto" fashion) but any adding or deleting cards screws any indexing around. Anyone know I can do this ? An example might be: Stack1 (1 card only) Stack2 (Sorted addresses) (Like an address book index) A --> Tony Able Berry Anvil C --> Jeff Collins If 'A' points to the first 'A' address, how do I write a button which allows a user to add a card (e.g. "Steve Aaron") and resets the A pointer to look at this card, after the stack is sorted. It seems as though Hypercard's linking feature is great when the inexperienced used is browsing (such as the excellent hypercard help stack), but keeping any links updated seems to be a bit more of a challenge. Thanks in advance Tony Locke Standard discalimers ....
steve@arc.UUCP (Steve Savitzky) (07/19/89)
In article <514@extro.ucc.su.oz> awl@extro.ucc.su.oz (Tony Locke) writes: >Using the "link to" feature you can do a reasonable job >of linking related records together (in true "goto" fashion) but any >adding or deleting cards screws any indexing around. Anyone know >I can do this ? The cleanest thing I can think of is to add 26 dummy cards with one-letter entries A, B, ... in all of the fields you're likely to sort on. Link the index buttons to those. Put "index tab" graphics on the card layer to hide the kludgery. (Hmm... think I'll put this in MY address stack!) Better than linking: give the cards 1-letter NAMES, and give the index buttons the same names. Then you can use the trivial script: on mouseUp go card the short name of the target end mouseUp in each button. Disclaimer: my macintoy's at home, so all code in this post is untested. (I *never* assume HyperCard is going to behave the way I think it ought to.) -- Steve Savitzky | steve@arc.uucp | apple.com!arc!steve ADVANsoft Research Corp. | (408) 727-3357(w) / 294-6492(h) 4301 Great America Parkway | #include<disclaimer.h> Santa Clara, CA 95054 | May the Source be with you!
dlugose@ecsvax.UUCP (Dan Dlugose) (07/20/89)
In article <514@extro.ucc.su.oz> awl@extro.ucc.su.oz (Tony Locke) writes: >Using the "link to" feature you can do a reasonable job >of linking related records together (in true "goto" fashion) but any >adding or deleting cards screws any indexing around. Anyone know >I can do this ? > >An example might be: > A --> Tony Able >If 'A' points to the first 'A' address, how do I write a button which allows >a user to add a card (e.g. "Steve Aaron") and resets the A pointer to look >this card, after the stack is sorted. I can think of 2 approaches: Create the index stack with 26 cards which can't be deleted, which will always be the first card for that letter. E.g. if there is a field "NameField" put "AAA" or "NNN" or whatever into that card. Therefore your pointers will never have to be updated. I also would hide these cards from sight with an opencard handler in them that set lockscreen to true go next set lockscreen to false Or maybe the set lockscreen to true should be done in the button? 2nd approach: Have the button go to the stack and search for the first "N" card. If this is a sequential search of cards, it's slow. 3rd approach: Set the first card of each letter's name to that letter, e.g. card "X" of stack Index. Also write a stack handler for: On domenu "delete card" If the short name of this card is not empty then -- update correct card go next if char 1 of field "personName" is "X" then set the name of this card to "X" else --if no other X cards decide whether link should go --to prev card or this card --etc Hope this is helpful Dan Dlugose UNC Educational Computing Service dlugose@uncecs.edu
bayes@hpislx.HP.COM (Scott Bayes) (07/22/89)
If you create your standard background first, then make 26 new backgrounds, copying the picture and buttons, etc. from the standard background to each, one for each letter, then finally name each of the 26 different backgrounds so created with its letter name, you should be able to get there with: go first card of background firstletter -- where firstletter contains a letter Make the 26 backgrounds undeletable. Go to the first card of the background when creating the card, and copy the background while creating the new card. Scott Bayes
steve@arc.UUCP (Steve Savitzky) (07/24/89)
In article <10510002@hpislx.HP.COM> bayes@hpislx.HP.COM (Scott Bayes) writes: >If you create your standard background first, then make 26 new >backgrounds, [...] This works but it has a problem that I noticed the last time I did something of the sort: my card and background layouts tend to be pretty dynamic. I'm always tweaking -- adding a button, moving a field, changing a graphic... Propagating a change to each of 26 otherwise identical backgrounds gets to be a pain. (Of course, you can write scripts for propagating most kinds of change, but that requires planning ahead :-) -- Steve Savitzky | steve@arc.uucp | apple.com!arc!steve ADVANsoft Research Corp. | (408) 727-3357(w) / 294-6492(h) 4301 Great America Parkway | #include<disclaimer.h> Santa Clara, CA 95054 | May the Source be with you!
bayes@hpislx.HP.COM (Scott Bayes) (07/26/89)
> / hpislx:comp.sys.mac.hypercard / steve@arc.UUCP (Steve Savitzky) / 10:46 am Jul 24, 1989 / > In article <10510002@hpislx.HP.COM> bayes@hpislx.HP.COM (Scott Bayes) writes: > >If you create your standard background first, then make 26 new > >backgrounds, [...] > > This works but it has a problem that I noticed the last time I did > something of the sort: my card and background layouts tend to be pretty > dynamic. I'm always tweaking -- adding a button, moving a field, > changing a graphic... Propagating a change to each of 26 otherwise > identical backgrounds gets to be a pain. (Of course, you can write > scripts for propagating most kinds of change, but that requires > planning ahead :-) That's the nice thing about prototyping in HC, no need to do much planning ahead. The nasty is the tendency to want to ship the prototype. :-) > > -- > Steve Savitzky | steve@arc.uucp | apple.com!arc!steve > ADVANsoft Research Corp. | (408) 727-3357(w) / 294-6492(h) > 4301 Great America Parkway | #include<disclaimer.h> > Santa Clara, CA 95054 | May the Source be with you! Scott Bayes