home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / mac / hypercar / 4241 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  3.0 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!saimiri.primate.wisc.edu!ames!data.nas.nasa.gov!taligent!apple!jkc
  2. From: jkc@Apple.COM (John Kevin Calhoun)
  3. Newsgroups: comp.sys.mac.hypercard
  4. Subject: Re: HyperCard won't let me do libraries!?
  5. Message-ID: <74485@apple.apple.COM>
  6. Date: 19 Nov 92 17:54:44 GMT
  7. References: <1992Nov17.104028.12220@waikato.ac.nz> <jpugh-171192212941@kip2-56.apple.com>
  8. Organization: Apple Computer Inc., Cupertino, CA
  9. Lines: 66
  10.  
  11.  
  12. In article <jpugh-171192212941@kip2-56.apple.com> jpugh@apple.com
  13. (Jon Pugh) writes:
  14. >In article <1992Nov17.104028.12220@waikato.ac.nz>, ldo@waikato.ac.nz
  15. >(Lawrence D'Oliveiro, Waikato University) wrote:
  16. >> 
  17. >> But I hit a snag--namely, a bug in HyperCard. The library stack correctly
  18. >> appears in the "StacksInUse" list, but when I try invoking an external from
  19. >> that library, HyperCard just beeps at me. I can make it come right if I try
  20. >> again a second time, but it always fails that first time.
  21.  
  22. >I commend you on your persistence.  I tried this quite some time ago and
  23. >just assumed it didn't work because of this problem.  I wasn't as
  24. >persistent as you were.  We'll have to see if Kevin "HyperDeity" Calhoun
  25. >has any wise words on the whys and wherefores of the issue.
  26.  
  27. No deification please; we already have our pantheon of HyperGods, and I
  28. regularly slime them for having abused their privileges.  As for me, I'd
  29. rather just have them give me the project back, thanks.  :-)
  30.  
  31. Thanks, Lawrence, for posting the materials that allowed me to reproduce
  32. this bug.  Here's the nub of it (this information applies to HyperCard 2.0,
  33. 2.0v2, and 2.1):
  34.  
  35. When you send a message to a stack other than the current stack, and the
  36. resource fork of the target stack has not been opened since HC was last
  37. launched, HyperTalk will open the resource fork, cache information about
  38. its externals, and then close the resource fork, thereby invalidating
  39. some of that information without realizing it.  When the resource fork of
  40. the stack is next opened, HyperTalk won't refresh its cache, because it
  41. thinks it already has all of the relevant data.  However, everything gets
  42. back in synch after the resource fork is closed a second time.
  43.  
  44. This problem will also surface if you send a message to another stack, and
  45. the message is intercepted by a handler that invokes an external command.
  46.  
  47. The workaround for versions 2.0, 2.0v2, and 2.1 is to visit the stack once
  48. before trying anything fancy, such as sending it the StartUsing message
  49. described in Lawrence's document.  So, you can do this to make things work:
  50.  
  51.   lock screen
  52.   lock messages
  53.   go stack "Library"
  54.   go back
  55.   unlock screen
  56.   unlock messages
  57.   send StartUsing to stack Library
  58.  
  59. It's actually slightly faster, however, to do it this way:
  60.  
  61.   lock screen
  62.   lock messages
  63.   push card
  64.   go stack "Library"
  65.   StartUsing
  66.   pop card
  67.   unlock screen
  68.   unlock messages
  69.  
  70. This does the trick for the stacks that were posted.
  71.  
  72. BTW, if there's ever another version of HyperCard, this bug will be fixed
  73. therein, thanks to Lawrence, whose bug reports are always invaluable.
  74.  
  75. Kevin Calhoun
  76. jkc@apple.com
  77.