Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!timbuk!cs.umn.edu!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!scott From: scott@mcs-server.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: window focus revisited Message-ID: Date: 3 Dec 90 13:12:01 GMT References: <339@heaven.woodside.ca.us> Organization: Gustavus Adolphus College Lines: 64 Nntp-Posting-Host: mcs-server.gac.edu In-reply-to: glenn@heaven.woodside.ca.us's message of 3 Dec 90 05:12:35 GMTLines: 64 In article <339@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: The "Steal Keys" option in Terminal makes it possible to focus the Terminal application simply by moving the mouse into its window (no click is required). It is purportedly for debugging, as in this passage from the documentation, but it is interesting in light of our discussion about this topic. I'm not sure how it's done, but it appears that Terminal simply does not become the key window, but does "steal" keydown events from the event queue somehow. The previously-active application is still highlighted and looks active. Ah. Like Old Shell's debug mode. Well, I don't support that in Stuart, because I think it's _really_ disgusting, and I'm sure I don't want to see the code to do it. What I do when window activation and the like will cause problems while debugging is to fill the event queue with appropriate events (since the windowserver handles that, it can be done even while the app has halted). Of course, that won't work in some very _strange_ cases, but it's not been a problem for me. Hey, Scott, have anything to toss in about this feature? Well, I am close to releasing two Window subclasses I've created in the course of Stuart2.0. One is labeled DocWindow, and allows the user to specify an alternate miniwindow icon for use when the docEdited flag is set for the window (like Edit and Stuart2.0 does). The other is called FocusWindow. FocusWindow tracks the mouse, and when it moves into (and stops in) a FocusWindow instance, that window becomes key and makes its app active (if needed). While this is exceptionaly silly to be doing at a user level, it works on a per-app basis. It also works fine under 2.0 . . . Well, I amend the "and I'm sure I don't want to see the code to do it" I have above. I'd love to see the code NeXT uses, because maybe it will help me on the way to global move-to-focus. I've asked NeXT some questions, but they don't support my goal . . . OK. While I'm here, I'll ask the net. I can handle all the windowpackage code to track the mouse, find the window it's over, and find the app who owns the window. There are two things I've been unable to accomplish. One thing that is needed for something like this is some sort of DPS-level timed entry, because I cannot focus until the mouse has stayed in place for a certain length of time. Alternately, a method of blowing away a certain number of fractional seconds (heck microseconds are good enough), and then I could poll (which I don't really want to do either). The other question relates to window activation. I've tried spoofing the app by sending a mouse click with a position in the middle of the title bar (mouse focusing only occurs in windows with title bars). This almost works. If the window just happens to be the key window for the app, it seems to work. If not, I've managed to get everything all confused . . . running gdb and watching a Window subclasses' sendEvent: (and the App's, also) doesn't help, as it appears that the events coming through for both are the same, yet it still doesn't work. So, could anyone explain how exactly to activate a specified window/ application, where the window may be any title-barred window on the screen, and the app is the owning context of that window? thanks. -- scott hess scott@gac.edu Independent NeXT Developer (Stuart) GAC Undergrad (Horrid. Simply Horrid. I mean the work!)