home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / programm / 20624 < prev    next >
Encoding:
Text File  |  1993-01-04  |  1.5 KB  |  37 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!stanford.edu!rpal.rockwell.com!planets!sho
  3. From: sho@planets.risc.rockwell.com (Sho Kuwamoto)
  4. Subject: Re: Window Zooming
  5. Message-ID: <1993Jan4.180924.211@planets.risc.rockwell.com>
  6. Reply-To: sho@risc.rockwell.com (Sho Kuwamoto)
  7. Organization: Rockwell International Science Center, Thousand Oaks, Ca.
  8. References: <1993Jan1.122830.1@vaxc>
  9. Date: Mon, 4 Jan 93 18:09:24 GMT
  10. Lines: 25
  11.  
  12. In article <1993Jan1.122830.1@vaxc> matsrc@vaxa.hofstra.edu writes:
  13. >A window is put in its standard state, which is smaller than
  14. >the screen  (like a Finder window). It is then moved elsewhere on the
  15. >screen, but to another valid position for its standard state. When the
  16. >user clicks on the zoom box, you would like FindWindow to return
  17. >inZoomIn because the window is in its standard state, but how will
  18. >FindWindow know that?
  19.  
  20. I ignore the difference between inZoomIn and inZoomOut, and
  21. use my own code to figure out whether the window needs to be
  22. zoomed in or out.  Window zooming works differently now than
  23. it did when first implemented, and it's too hard to force
  24. the new behavior to fit into the old mechanism.
  25.  
  26. >(2) Which takes precedence when switching to the standard state:  The
  27. >desire to leave the top left corner fixed, or the desire to leave space
  28. >on the right of the main screen for Finder icons? 
  29.  
  30. I don't bother leaving space for the Finder icons.  I can
  31. see going either way on this one, I suppose.
  32.  
  33. -Sho
  34. --
  35. sho@physics.purdue.edu
  36.  
  37.