home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / programm / 12888 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.8 KB
  1. Path: sparky!uunet!olivea!sgigate!psinntp!psinntp!newstand.syr.edu!greeny
  2. From: greeny@top.cis.syr.edu (J. S. Greenfield)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Moving to the foreground after receiving an 'odoc' from the Finder
  5. Message-ID: <1992Jul22.003451.6460@newstand.syr.edu>
  6. Date: 22 Jul 92 04:34:51 GMT
  7. References: <mxmora-200792113832@css-mac1.sri.com> <1992Jul20.195334.19197@newstand.syr.edu> <1992Jul21.161251.7693@midway.uchicago.edu>
  8. Organization: Syracuse University, CIS Dept.
  9. Lines: 48
  10.  
  11. In article <1992Jul21.161251.7693@midway.uchicago.edu> jcav@midway.uchicago.edu writes:
  12. >>
  13. >>What is the standard technique to insure that your application is in the
  14. >>foreground after receiving an 'odoc' event from the finder?
  15. >>
  16. >>I have an application (which does not recieve suspend/resume events) which
  17. >                        ^^^^^ ^^^^ ^^^ ^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^
  18. >This is the root of your problem.  If you accept high-level events, you also
  19. >_must_ accept OS events (suspend/resume, etc).
  20.  
  21. But this is not correct.  The SIZE resource has a bit to indicate whether
  22. the application receives suspend/resume events.  Since this application
  23. does not manipulate any scrap or manipulate any windows (other than modal
  24. dialogs), it has no need for suspend/resume events.
  25.  
  26. Anyway, even if they were sent, I don't mask them out.  They just would not
  27. produce any response from my application.
  28.  
  29.  
  30. >>brings up a custom get file after receiving an 'odoc' event.  If there are
  31. >>some finder windows open, the get file dialog will occasionally appear
  32. >>*behind* the finder windows, initially.  It then moves to the front, but
  33. >>the dialog window is left empty.
  34. >
  35. >If you want to be absolutely sure you're in front, you can call
  36. >_SetFrontProcess (I think that's the name) with your own process serial #.
  37. >However, I suspect that if you handle your suspend/resume events by the
  38. >book, the other problems should "factor out".
  39.  
  40. Actually, several individuals pointed me to the proper technique when handling
  41. apple events, which is to call AEInteractWithUser.  This routine checks both
  42. the server's and client's specification for allowed interaction in processing
  43. the event, and will call the notification manager, if necessary, in order to
  44. request that the user move the server application to the foreground.
  45.  
  46. (See IM VI, 6-51 through 6-54.)
  47.  
  48. In my case, this is not necessary--the call simply holds up my application
  49. until it moves to the foreground, as it will normally do since 'odoc' events
  50. from the Finder allow the server to interact (and the Finder seems to
  51. undertake to move the server to the foreground, itself).
  52.  
  53.  
  54. -- 
  55. J. S. Greenfield                                         greeny@top.cis.syr.edu
  56. (I like to put 'greeny' here, 
  57. but my d*mn system wants a 
  58. *real* name!)                        "What's the difference between an orange?"
  59.