This is Dissasociating-a-Window-from-an-Application in view mode; [Up]
Date: Sun 05-Dec-1989 00:31:33 From: Unknown Subject: Dissasociating a Window from an Application Is there a way to dissasociate a Window from the application that created it? I don't want this window to hide when the application hides, or the application to unhide when the window is clicked on. Jacob
Date: Sun 06-Dec-1989 02:15:42 From: Unknown Subject: Re: Dissasociating a Window from an Application In article <130039@gore.com> jacob@gore.com (Jacob Gore) writes: >Is there a way to dissasociate a Window from the application that created >it? I don't want this window to hide when the application hides, or the >application to unhide when the window is clicked on. I hope you have a good reason to want to do this, Jacob... That behaviour isn't consistent with the UI guidelines --- "When an application is hidden, only its freestanding or docked icon remains on-screen." Anyway, as you can gather, there's no official way. However, anything's possible... What seems to work in this case is to have the Application's want to remain unhidden. One line of code! The window remains behind (actually goes away and comes back), along with the app icon. 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. Ali > >Jacob >-- >Jacob Gore Jacob@Gore.Com boulder!gore!jacob >From: jacob@gore.com (Jacob Gore)
Date: Sun 06-Dec-1989 05:46:12 From: Unknown Subject: Re: Dissasociating a Window from an Application / comp.sys.next / ali@polya.Stanford.EDU (Ali T. Ozer) / Dec 5, 1989 / > I hope you have a good reason to want to do this, Jacob... That behaviour > isn't consistent with the UI guidelines --- "When an application is hidden, > only its freestanding or docked icon remains on-screen." That's certainly a fair question. My application is Announcer, sort of a panel-oriented biff. It listens to a Listener port for announcement requests, and when it gets one, it plays a sound, or pops up an announcement panel, or both. The announcement panels are not modal, since I don't want to force the user to change the active application in order to get rid of an announcement panel (this, in my view, is the most annoying thing about getting a "printer out of paper" panel). Instead, they are dismissed by clicking on their close button. If Announcer is auto-launched from the dock, it starts up quickly. It has a very minimal nib file that gets loaded at this time. But another thing Announcer does is maintain a list of registered clients. By registering a client one can specify things like what icon to display, what sound to play, whether to use video notification or audio or both, etc. There are panels for editing the client list, a client, and preferences. The client list panel shows up when Announcer's miniworld icon is double-clicked (probably in the dock). (This is also when a larger nib section, containing all the interactive panels, is loaded.) This interactive mode starts up on an unhide: message. > 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. One line of code! This is close to what I tried -- I overrode AnnouncementPanel's and [NXApp isHidden]. 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. But when the application is unhidden, the client list panel and whatever other interactive panels were on the screen before the application was hidden come back. And the active application changes to Announcer, which is something I wanted to avoid from the outset! I guess I would have achieved my goal if there was some way to make clicking on an AnnouncementPanel behave as if it was Alternate-clicked -- just drag the panel around, but not make Announcer the active application. Any ideas along that line? Any other suggestions? Jacob
Date: Sun 08-Dec-1989 01:58:26 From: Unknown Subject: Re: Dissasociating a Window from an Application 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 >From: dennisg@kgw2.UUCP (Dennis Glatting)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.