🚀 go-pugleaf

 
Dear MACAPP2TECH$ and MACAPP3TECH$ folks,
 
Macromedia has several applications written with MacApp 2 which exhibit a
common bug under KanjiTalk 7.1: they crash when the Kotoeri palette is opened.
These apps all use the UFloatWindow extension to MacApp to handle their
floating windows.
 
I believe that the problem is in MABringToFront in UFloatWindow.inc1.p. This
routine is MacApp 2's patch for BringToFront that preserves window layering.
The code uses the conditional
 
                    windPeek^.windowKind < 0
 
to determine if the window is a system window. Since the Kotoeri palette has a
windowKind of 7, it is not recognized as a system window. Instead the code for
handling document windows gets executed, and when the SendBehind trap gets
called a bus error occurs.
 
When I change this conditional to
 
    (windPeek^.windowKind < userKind) & (windPeek^.windowKind <> dialogKind)
 
so that windows with windowKinds of 0, 1, 3, 4, 5, 6, and 7 - in addition to
those with negative values - are recognized as system windows, the problem
seems to go away. I decided to recognize all these values, rather than just 7,
because Inside Macintosh I-276 says that "WindowKind values 0, 1, and 3 through
7 are reserved for future use by the system."
 
Has anyone else encountered this problem? How did you fix it? Do you know if
this is the proper way to handle not only the Kotoeri palette but other future
system windows?
 
- Gordon Smith, Macromedia
  AppleLink D3431