jdb@mordor.ARPA (John Bruner) (10/16/86)
I've run across a strange problem in an otherwise stable program. When I use NewWindow to create an invisible window, the current active window is deactivated. (That is, GetNextEvent returns an activate event which specifies that the window is now inactive and the window is no longer highlight.) This occurs regardless of the "behind" value that I specify (i.e. it fails even if I specify (WindowPtr)0 or FrontWindow()). Further, if I subsequently call SelectWindow() on the top visible window (which is inactive), the window manager highlight it but no activate event is generated. Yet if I pop up a dialog or another window, and then remove that window, the previous top window is reactivated correctly. It seems that the window manager does maintain the correct front-to-back ordering of the windows, but something causes the top window to be deactivated. My guess is that the Window Manager doesn't think that it is deactivated; hence, it doesn't generate an activate event when I call SelectWindow(). If a desk accessory is the top window, then it is un-highlighted but it still responds to the mouse and keyboard. This reinforces my suspicion that someone has put out a false deactivate event. I've experienced this problem with System versions 2.0 and 3.1.1 (I haven't yet converted to 3.2) and with both the 64K and 128K ROMs. My program's source is almost 400Kbytes long, so it is quite possible that there is an undesirable interaction with something else. (However, I haven't had any other strange problems with windows.) Does this sound familiar to anyone? -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb