home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.mac.programmer
- Path: sparky!uunet!uchinews!quads!jcav
- From: jcav@quads.uchicago.edu (JohnC)
- Subject: Re: Moving to the foreground after receiving an 'odoc' from the Finder
- Message-ID: <1992Jul21.161251.7693@midway.uchicago.edu>
- Sender: news@uchinews.uchicago.edu (News System)
- Reply-To: jcav@midway.uchicago.edu
- Organization: The Royal Society for Putting Things on Top of Other Things
- References: <D2150035.8p3ep6@outpost.SF-Bay.org> <mxmora-200792113832@css-mac1.sri.com> <1992Jul20.195334.19197@newstand.syr.edu>
- Date: Tue, 21 Jul 1992 16:12:51 GMT
- Lines: 25
-
- In article <1992Jul20.195334.19197@newstand.syr.edu> greeny@top.cis.syr.edu (J. S. Greenfield) writes:
- >
- >What is the standard technique to insure that your application is in the
- >foreground after receiving an 'odoc' event from the finder?
- >
- >I have an application (which does not recieve suspend/resume events) which
- ^^^^^ ^^^^ ^^^ ^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^
- This is the root of your problem. If you accept high-level events, you also
- _must_ accept OS events (suspend/resume, etc).
-
- >brings up a custom get file after receiving an 'odoc' event. If there are
- >some finder windows open, the get file dialog will occasionally appear
- >*behind* the finder windows, initially. It then moves to the front, but
- >the dialog window is left empty.
-
- If you want to be absolutely sure you're in front, you can call
- _SetFrontProcess (I think that's the name) with your own process serial #.
- However, I suspect that if you handle your suspend/resume events by the
- book, the other problems should "factor out".
-
- --
- John Cavallino | EMail: jcav@midway.uchicago.edu
- University of Chicago Hospitals | John_Cavallino@uchfm.bsd.uchicago.edu
- Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
- B0 f++ c+ g++ k s++ e+ h- pv | Chicago, IL 60637
-