home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!spool.mu.edu!agate!ames!data.nas.nasa.gov!taligent!apple!applelink.apple.com
- From: D3431@AppleLink.Apple.COM (MacroMedia Programmers,PRT)
- Newsgroups: comp.sys.mac.oop.macapp3
- Subject: UFloatWindow & Kotoeri palette
- Message-ID: <722171257.8164257@AppleLink.Apple.COM>
- Date: 19 Nov 92 01:10:00 GMT
- Sender: daemon@Apple.COM
- Organization: AppleLink Gateway
- Lines: 37
-
-
-
- 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
-
-