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)
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
