A Foole's Thoughts on the windowBoundingRect

[Rob Cozens]

Moi:

> I believe using the working screenRect rather than the 
> windowBoundingRect is preferable in these cases.
>

I spent some more time playing with stack resizing & max/mining 
yesterday.

It's difficult to keep straight IDE issues vs standalone issues; but 
here's what I conclude:

1. The Run Rev IDE apparently sets the windowBoundingRect ["wBR"] once 
on startup and never changes it.  So some TPC compliance issues IN THE 
IDE could be solved as follows:

	on deskTopChanged
		set the windowBoundingRect to (the working screenRect)-[adjustment 
for rev.Menubar.rev]
	end deskTopChanged

2. Unless you script it, your standalone will also be unresponsive to 
deskTopChanged ["dTC"].

3. A dTC handler similar to #1 above will work for a standalone that 
opens a single window.  If your app maintains multiple open windows, 
you may need to adjust the wBRs for some or all of them on dTC.

4. FWIW, WinXP apps in general respond to dTC and MacOSX apps don't:

	A. Change screen orientation or hide/show the TPC Input Panel, and 
windows fully or partially outside the wBR (the "true" wBR, not what 
Rev sets on startup) adjust size or position.

	B. Reposition the Dock so it covers part of an open window, and the 
window remains partially covered.

I'm adding this info to the comments re:Bugzilla #3252, TPC Compliance. 
  You can vote for this at

  <http://support.runrev.com/bugdatabase/show_bug.cgi?id=3252>

Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)