Xref: utzoo comp.sys.mac.comm:3939 comp.sys.mac.system:6576
Newsgroups: comp.sys.mac.comm,comp.sys.mac.system
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!ephraim
From: ephraim@think.com (Ephraim Vishniac)
Subject: Re: MacX cursor bug?
Message-ID: <1991May30.131922.22751@Think.COM>
Sender: news@Think.COM
Reply-To: ephraim@think.com
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <1991May29.211302.13170@neon.Stanford.EDU>
Date: Thu, 30 May 91 13:19:22 GMT

In article <1991May29.211302.13170@neon.Stanford.EDU> philip@pescadero.stanford.edu writes:
>If MacX is in the background, and the foreground program closes
>a window, MacX changes the cursor if it happens to be over
>a MacX window at the time. It took me a while to work this out,
>because it only happens with applications that don't themselves
>change the cursor when the window disappears, and when the cursor
>is over the frontmost MacX window, which must also be an xterm
>window.

As long as we're reporting MacX bugs, here's another one. ResEdit
complains that settings files stored by MacX 1.1 are damaged. The
reason seems to be that MacX repeatedly adds STR -16396 ("MacX") to
the file. ResEdit, like the rest of the world, figures that duplicate
resource IDs are a sign of brain damage, so it complains. 

-- 
Ephraim Vishniac    ephraim@think.com   ThinkingCorp@applelink.apple.com
 Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142
        One of the flaws in the anarchic bopper society was
        the ease with which such crazed rumors could spread.