home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / mac / hypercar / 3404 < prev    next >
Encoding:
Text File  |  1992-09-09  |  2.0 KB  |  53 lines
  1. Newsgroups: comp.sys.mac.hypercard
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ucla-cs!lanai.cs.ucla.edu!jason
  3. From: jason@lanai.cs.ucla.edu (Jason Rosenberg)
  4. Subject: difficulty converting from 1.2.5 to 2.1: object names
  5. Message-ID: <1992Sep9.232922.15830@cs.ucla.edu>
  6. Originator: jason@lanai.cs.ucla.edu
  7. Sender: usenet@cs.ucla.edu (Mr Usenet)
  8. Nntp-Posting-Host: lanai.cs.ucla.edu
  9. Organization: UCLA Computer Science Department
  10. Date: Wed, 9 Sep 92 23:29:22 GMT
  11. Lines: 40
  12.  
  13. Hello,
  14.  
  15. I am in the process of converting a rather complex, existing stack from
  16. HC 1.2.5 to HC 2.1.  One of the problems that has come up is the way
  17. in that objects are apparently referred to in HC 2.1.  My stack has
  18. lots of buttons with names like "0.0","0.1", etc....  This has never
  19. been a problem.  I have a script called hiliteBtn which takes one argument,
  20. the name of the button to hilite.  It now complains that button number 0
  21. does not exist, when I pass it "0.0" as its argument.  So, HC 2.1 is 
  22. converting strings to numbers and trying that before trying the string
  23. as a literal.
  24.  
  25. My only way around it has been to change the following line within hiliteBtn:
  26.  
  27. 'set the hilite of bg btn buttonName to true'
  28.  
  29. To:
  30.  
  31. 'do "set the hilite of bg btn" && quote & buttonName & quote && "to true"'
  32.  
  33. This seems to explicitly to treat the buttonName as a literal.  Of course,
  34. it runs about twice as slow....
  35.  
  36. I was upset to discover this anomaly.  It effectively means you can no longer 
  37. have objects with just an integer number as its name.  Which is ok if you are
  38. building an HC stack from scratch in 2.1.  But if you are converting an
  39. existing stack, it can be a major drag to go back and change all the object
  40. names.....
  41.  
  42. Has anyone else encountered this?  Any other work-arounds?
  43.  
  44. Is there an address to contact apple (Claris, I should say) directly about
  45. this?  It seems like it could ostensibly be a bug....
  46.  
  47. Jason
  48.  
  49. -- 
  50. Jason Rosenberg                           Computer Science Department
  51. jason@cs.ucla.edu                         University of California
  52. {uunet,rutgers,ucbvax}!ucla-cs!jason      Los Angeles, CA  90024
  53.