home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / apple2 / 19515 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  3.0 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!agate!stanford.edu!eos!data.nas.nasa.gov!taligent!apple!dlyons
  2. From: dlyons@Apple.COM (David A Lyons)
  3. Newsgroups: comp.sys.apple2
  4. Subject: Re: Window Managing Help
  5. Message-ID: <71717@apple.Apple.COM>
  6. Date: 27 Aug 92 12:42:18 GMT
  7. References: <1992Aug21.025859.29356@news.iastate.edu> <mattd-240892162320@city-lights.apple.com>
  8. Organization: Apple Computer Inc., Cupertino, CA
  9. Lines: 61
  10.  
  11. In article <1992Aug21.025859.29356@news.iastate.edu>, irsman@iastate.edu
  12. (Ian Schmidt) wrote:
  13. >[...] if the user clicks in the window (changing
  14. >the position of the selection cursor) while an update event is pending, Bad 
  15. >Things happen (ie, I redraw the cursor, but if its old position isn't part of
  16. >the update region I end up with two cursors [not mouse cursors!] in the window,
  17. >which is obviously messy).
  18.  
  19. Matt D writes:
  20. >Yes -- don't draw in your window outside of your window's update routine.
  21. >
  22. >If you move the cursor from one place to another, you should invalidate the
  23. >place where the cursor used to be, and invalidate the place where it should
  24. >be.  When you get your next update event, your redraw routine should know
  25. >where the cursor's supposed to be now and draw things correctly.
  26.  
  27. That will work, but in my opinion it's excessively complicated, and it will
  28. be sluggish.
  29.  
  30.  
  31. >If you want to draw in your window outside of your update routines, make
  32. >sure you don't wind up drawing something that your update routine will
  33. >draw differently, and make sure you set up the Window Manager environment
  34. >properly.
  35.  
  36. *That* is the key...draw the same thing your update routine would have
  37. drawn, including the insertion point (cursor).
  38.  
  39. My guess:
  40.  
  41.   * You are exclusive-or drawing your insertion point (fine).
  42.  
  43.   * When your update routine draws the window contents it assumes it's
  44.     drawing on a fresh background, which it usually is.
  45.  
  46.   * When the insertion point moves, you xor-draw the insertion point at
  47.     the old location (to remove it).  If all or part of it wasn't actually
  48.     there, you now have all or part of a bogus cursor.
  49.  
  50.   * When the window updates later, the window content gets overlaid on the
  51.     bogus cursor.
  52.  
  53. Solutions (pick one):
  54.  
  55.   * Have the update routine completely overwrite the area to be updated
  56.     (by starting out with a huge EraseRect, or by drawing stuff to the
  57.     entire area). -- Make sure to always draw the insertion point!  If
  58.     all or part of the insertion point is outside the area being updated,
  59.     it will be clipped out automatically, no problem.
  60.  
  61.   * Handle any pending updates before moving the insertion point.  (You
  62.     can use EmptyRgn(GetUpdateRgn(yourWindow)) to see if you need an
  63.     update; then call BeginUpdate, yourContentDraw, EndUpdate.
  64.  
  65. I prefer the first way.
  66. -- 
  67. David A. Lyons, Apple Computer, Inc.      |   DAL Systems
  68. Apple II System Software Engineer         |   P.O. Box 875
  69. Internet:dlyons@apple.com                 |   Cupertino, CA 95015-0875
  70.  
  71. My opinions are my own, not Apple's.
  72.