Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!snorkelwacker!mit-eddie!uw-beaver!Teknowledge.COM!polya!ali
From: ali@polya.Stanford.EDU (Ali T. Ozer)
Newsgroups: comp.sys.next
Subject: Re: Dissasociating a Window from an Application
Message-ID: <12947@polya.Stanford.EDU>
Date: 8 Dec 89 01:58:26 GMT
References: <130039@gore.com> <130040@gore.com>
Organization: .
Lines: 31

In article <130040@gore.com> jacob@gore.com (Jacob Gore) writes:
>/ comp.sys.next / ali@polya.Stanford.EDU (Ali T. Ozer) / Dec  5, 1989 /
>> What seems to work in this case is to have the Application's 
>> appDidHide: delegate method send an orderFront: message to the window you 
>> want to remain unhidden.  ...
>This is close to what I tried ... But neither this nor your
>suggestion, Ali, goes far enough, because:
>> When you click on the window, the menu for the application also
>> appears. However everything else remains hidden unless you explicitly start
>> making windows come to front through menu commands.

Oh, I see.  If you don't want your hidden app to become active at all,
then the next thing to do is to subclass Application and override sendEvent:,
the method through which all events pass.  Just intercept application
activate events and ignore them if the app is hidden.  Otherwise
invoke the real sendEvent:.  Here's what this might look like:

	// In your subclass of Application:

	- sendEvent:(NXEvent *)event {
	    if (!((event->type == NX_KITDEFINED) &&
		  (event->data.compound.subtype == NX_APPACT) &&
		  ([self isHidden]))) {
		[super sendEvent:event];
	    }
	    return self;
	}

Ali