Sean: I think that fn GETCURRENTPROCESS gives you the currently active process, even if the process is in the background. Here's some lazy pseudo-code (I've just bought a new computer and haven't installed any programming stuff yet because I plan to GAL for a while, except for this list, so I can't provide you with specifics): LOCAL FN CheckWindow(wndPtr&) - Check the currently running process - If the process is Claris e-mailer: - Check for the window name or other identifying information - If it's the correct window: - FN DoWindowStuff (Hopefully the window stuff can be done here because otherwise you would need more than one patch and this is tricky to have in FBII). END FN "NewWindow Patch" ENTERPROC(...parameter list...) FN CheckWindow(wndPtr&) EXITPROC HTH Mark Sean -G3- wrote: > >Sean: > > > >I wasn't following your original thread so I wasn't sure what you are doing > >with your program. I'll take one last stab at it and then leave you alone. > > > >If all you need to do is catch the opening of a certain window then you can > >write an INIT with a patch for newwindow or newcwindow. Check the name of > >the window and the currently running app from your INIT. When the window of > >interest is opened, you can either set a flag and store the window pointer > >for > >later processing, or do all your work immediately. HTH. > > > >Mark > > That sounds good, but can a window be created by an application which is > not the "currently running app"? Say Claris Emailer was in the > background, and the finder was currently active. Claris Emailer might > display an error message. However, would my INIT think that the error > message was generated by the finder?