home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / mac / programm / 15453 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  1.5 KB
  1. Path: sparky!uunet!stanford.edu!unix!mxmora
  2. From: mxmora@unix.SRI.COM (Matt Mora)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Set/Get Cursor
  5. Message-ID: <38564@unix.SRI.COM>
  6. Date: 14 Sep 92 16:38:44 GMT
  7. References: <1992Sep1.202106.2865@informix.com> <1992Sep10.184138.3458@amgen.com>
  8. Followup-To: comp.sys.mac.programmer
  9. Organization: SRI International, Menlo Park, California
  10. Lines: 39
  11.  
  12.  
  13. In article <1992Sep10.184138.3458@amgen.com> mikeb@sam.amgen.com (Michael Brennan) writes:
  14. >In article <1992Sep1.202106.2865@informix.com> Bill Stackhouse, sbill@informix.com writes:
  15. >>Why does the following cause EvenBetterBusError detect a NIL pointer
  16. >>problem?
  17.  
  18. >>   SetCursor(*GetCursor(iBeamCursor));
  19.  
  20. >Here's the code I use.  It works for me:
  21.  
  22. >    Cursor        myCursor;
  23. >    CursHandle    hCurs = 0L;
  24. >
  25. >    hCurs = GetCursor( iBeamCursor );
  26. >    myCursor = **hCurs;
  27.  
  28. >    SetCursor( &myCursor );
  29. >    DisposeHandle( hCurs );
  30. >    ShowCursor();
  31.  
  32. What is different about your code than the line above? Neither has any
  33. error detection. Both will bomb with a nil handle. And is it really a good
  34. idea to dispose of a system handle or it that your own IbeamCursor resource?
  35.  
  36. If your going to be changing the cursor all the time, you should just
  37. load and lock the cursors when your program starts up. Then you won't
  38. have to worry about a nil handle.
  39.  
  40. Matt
  41.  
  42.  
  43.  
  44.  
  45.  
  46. -- 
  47. ___________________________________________________________
  48. Matthew Mora                |   my Mac  Matt_Mora@sri.com
  49. SRI International           |  my unix  mxmora@unix.sri.com
  50. ___________________________________________________________
  51.