home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / oop / macapp3 / 325 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  3.2 KB
  1. Path: sparky!uunet!olivea!apple!applelink.apple.com
  2. From: SIGMUND@NORA.HD.UIB.NO
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: TWindow, a problem and a bug
  5. Message-ID: <199301011930.AA00471@nora.hd.uib.no>
  6. Date: 1 Jan 93 20:30:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 84
  10.  
  11. From: sigmund@nora.hd.uib.no
  12. To: MACAPP3TECH$@applelink.apple.com
  13. Cc: achiqui@roman.uib.no
  14.  
  15. Dear MacAppers,
  16.  
  17. Working with multiple monitors connected has revealed a problem with MacApp
  18. 3.0.1 and also what I believe are a couple of bugs.
  19.  
  20. The problem:
  21.  
  22. Members of TWindow: Center and Zoom, are two large functions that call
  23. this->GetMaxIntersectedDevice.  That means they are hardcoded to be
  24. directed to the device that has the largest area in common with the window.
  25.  One of my windows needs to be directed towards the device with a video
  26. board connected, and we can imagine occasions where a window should be
  27. directed to the deepest device, or the main device.
  28.  
  29. It would be better if there was a "GetPreferredDevice" function that Center
  30. and Zoom would call instead.  TWindow::GetPreferredDevice could simply call
  31. GetMaxIntersectedDevice, and subclasses could call something else.
  32.  
  33. The first bug:
  34.  
  35. TWindow::Center doesn't work if GetMaxIntersectedDevice returns any other
  36. device than the main screen.  As theFrame is calculated, Center only pays
  37. attention to the device's size, not its position.  As a result the window
  38. is placed on the main device, in a position where it would have been
  39. centered on the correct device.
  40.  
  41. The second bug:
  42.  
  43. TWindow::Center doesn't really trust GetMaxIntersectedDevice to account for
  44. menubar and adds GetMBarHeight to theFrame.top.  This compensates for bug
  45. #1 when dealing with the main device, but when bug #1 is corrected, the
  46. window will be placed 20 pixels (at least here in Norway) too low on any
  47. device.
  48.  
  49. I would suggest the following fix to both bugs in TWindow::Center, where
  50. theFrame.top and theFrame.left are calculated.
  51.  
  52. Take this:
  53.  
  54. if (horizontally)
  55.     theFrame.left = (screenSize.h - contentSize.h + fContentRegionInset.h)
  56. / 2;
  57. if (forDialog)
  58.     // Put it in the top third of the screen
  59.     theFrame.top = ((screenSize.v - contentSize.v + fContentRegionInset.v)
  60. / 3)
  61.                                                           +
  62. GetMBarHeight();
  63. else if (vertically)
  64.     theFrame.top = ((screenSize.v - contentSize.v + fContentRegionInset.v)
  65. / 2)
  66.                                                           +
  67. GetMBarHeight();
  68.  
  69. And change to this:
  70.  
  71. if (horizontally)
  72.     theFrame.left = (screenSize.h - contentSize.h + fContentRegionInset.h)
  73. / 2
  74.                                                           +
  75. screenRect.left;
  76. if (forDialog)
  77.     // Put it in the top third of the screen
  78.     theFrame.top = (screenSize.v - contentSize.v + fContentRegionInset.v) /
  79. 3
  80.                                                           + screenRect.top;
  81. else if (vertically)
  82.     theFrame.top = (screenSize.v - contentSize.v + fContentRegionInset.v) /
  83. 2
  84.                                                           + screenRect.top;
  85.  
  86.  
  87. This works for me, but please correct me if I am wrong or if anybody has a
  88. better solution.
  89.  
  90.         Regards,
  91.         Sigmund Tveit
  92.         Humanistisk Datasenter
  93.         Norway
  94.  
  95.