home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / mac / programm / 18247 < prev    next >
Encoding:
Text File  |  1992-11-10  |  3.0 KB  |  58 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!mdisea!jackb
  3. From: jackb@mdd.comm.mot.com (Jack Brindle)
  4. Subject: Re: The Forgetful Finder
  5. Message-ID: <1992Nov11.000631.7251@mdd.comm.mot.com>
  6. Sender: news@mdd.comm.mot.com
  7. Organization: Motorola, Mobile Data Division - Seattle, WA
  8. References: <Nov.9.12.14.27.1992.24843@math.rutgers.edu> <keith-091192124523@kip-16.taligent.com> <BxIM0r.IHC@unx.sas.com>
  9. Date: Wed, 11 Nov 1992 00:06:31 GMT
  10. Lines: 46
  11.  
  12. In article <BxIM0r.IHC@unx.sas.com> Michael Hecht <Michael_Hecht@mac.sas.com> writes:
  13. >This sounds very similar to one of my pet peeves. It seems that there's a
  14. >bug in the Mac OS in that if an application creates a new window when
  15. >it's not the foreground app, the window appears enabled. Its title bar
  16. >has the vertical lines in it, etc. Nuntius is a prime example. This
  17. >becomes a problem when I use the title bar as a visual cue to tell me
  18. >what the front-most application is. I may end up typing text or command
  19. >keys only to discover that the text isn't going where I intended, or the
  20. >command keys are doing things I don't want! Is this the behavior you're
  21. >describing?
  22. >
  23. >I thought of a very kludgy way to get around the bug. It involves making
  24. >an invisible "spare" window, which is normally last in the window list.
  25. >When an application is suspended, it brings this inviso window to the
  26. >front. Notice that this also generates a deactivate event for the
  27. >frontmost window, so the app won't have to simulate that as well. When
  28. >the app opens any new windows, it now opens them *behind* the inviso
  29. >window, causing them to appear deactivated. When the app is resumed, it
  30. >moves the inviso window to the rear, causing the frontmost window to
  31. >receive an activate event.
  32. >
  33. >You could maintain a static WindowPtr variable named "behindWindow" that
  34. >points to the inviso window when you're in the background, and contains (
  35. >WindowPtr )-1 when you're in the foreground. Then you just need to pass
  36. >this variable as the "behind" value to the NewWindow calls.
  37. >
  38. >Of course, fixing it in the Window Manager is the better solution, Apple!
  39.  
  40. Come now. The Window manager has no concept of foreground or background.
  41. That is more the domain of the process manager. The Window manager does
  42. not unhilite a window when the application is moved to the background,
  43. the app itself takes care of this in response to various events. I would
  44. suggest a different approach to creating a window. Something of the sort:
  45. Create the window as invisible. Check the foreground/background status (you
  46. _were_ catching these events, right?). If the state indicates background,
  47. (or non frontmost app) then unhilite the window. Finally, make the window
  48. visible. The proper update events will be generated, causing the window
  49. to be drawn the way you want it. I haven't tried this (yet), so feel free
  50. to try to show why it won't work. The real point is, don't blame the OS
  51. for a deficiency in some developer's code.
  52.  
  53. -- 
  54. ==========================================================
  55. Jack Brindle
  56. ham radio: wa4fib
  57. internet: jackb@mdd.comm.mot.com
  58.