Apple II
Technical Notes
_____________________________________________________________________________
                                                  Developer Technical Support
Apple IIgs
#98: Aren't Windows A Pane?

Revised by: Dave Lyons                                              May 1992
Written by: Dave Lyons                                          January 1991

This Technical Note describes interesting Window Manager things.

CHANGES SINCE JANUARY 1991:  Noted that in System 6.0 it's safe to use Window
color table resources.  Added a section on changing the desktop pattern or
picture.
_____________________________________________________________________________


CHANGING THE DESKTOP PATTERN OR PICTURE

The best way to set a new desktop pattern or picture is as follows.  This
works with the Finder and other desktop applications.

   1. Use MessageCenter to delete message 2, the desktop message.  (If there
      wasn't one, that's fine--there still isn't.)
   2. Use MessageCenter to create a new message 2, containing the pattern or
      picture you want (see the Window Manager chapter of Apple IIgs Toolbox
      Reference, Volume 3).
   3. Call Desktop (in the Window Manager) with a deskTopOp of 8 and a
      dtParam of $00000000.  This notifies any part of the system that cares
      (such as the Finder) that there is a new desktop pattern.
   4. Call Desktop with a deskTopOp of 4 and a dtParam of $00000000 and keep
      the result.
   5. Call Desktop with a deskTopOp of 5 and use the result from step 4 as
      dtParam.  This sets the desktop pattern to what it already is, forcing
      the desktop to redraw (this works whether a pattern, picture, or
      pointer to desktop-drawing routine is involved).


A WARNING ABOUT WINDOW COLOR TABLE HANDLES AND RESOURCES

The System 6.0 Window Manager fixes the problem described below.  If your
application requires System 6, you can safely ignore this section.

All versions of the Window Manager that support window color tables specified
as handles or resources, up to and including System Software 5.0.4, work
unreliably when a standard window's color table is supplied by handle or
resource ID.

The problem is not immediately obvious; only one bit of memory is accidentally
cleared, but the address is unpredictable in advance.  (When unlocking the
color table handle, the standard window definition procedure attempts to
unlock the handle manually by turning off bit 15 of word offset +4 in the
master pointer record.  But it gets the high and low words of the handle
reversed and usually turns off bit 15 of the word at offset $80E4 or $80E5 in
some bank of RAM determined by the low byte of the handle.)

The solution is to avoid supplying color table handles or resource IDs to the
Window Manager.  Supply color table pointers instead. You can get a color
table pointer from a color table resource ID by calling LoadResource on the
color table resource, locking the handle and dereferencing it.  Memory is less
fragmented if color table resources used in this way are marked as attrFixed.

One method is to put the window color table pointer into the window template
before calling NewWindow2.  If you are creating the window from an rWindParam1
resource, you need to use LoadResource to get the template into RAM so that
you can stuff the color table pointer into the template.  (Be sure to change
the moreFlags field to indicate that the color table is a pointer, if the
template indicates it's a resource.)  After you create the window with
NewWindow2 (by handle), use ReleaseResource to release the rWindParam1
resource.

Another method is to create the window as invisible and pass the window color
table pointer to SetFrameColor before calling ShowWindow.


Further Reference
_____________________________________________________________________________

   o   Apple IIgs Toolbox Reference, Volumes 2-3