Cocoa, changing window close behavior?

[None]

Is there an easy way to change the window closing behavior in Cocoa?
I'd like to have a slightly unorthodox behavior, in which the main
document window has finder-like icons that represent individual data
documents. Double clicking an icon opens one (or more) views of the
document data. I'd like to set it so that closing the data view windows
does not send a closedocument message to the data documents, but just
hides the data window. Instead, either closing the main icon window
would send individually closedocument messages to all of the data
documents, or else highlighting a single icon and deleting it (for
example) would send the same message to just that one data document.

Is there an override to do this?

thanks,

Rick

[John C. Randolph]

None wrote:

>
> Is there an easy way to change the window closing behavior in Cocoa?
> I'd like to have a slightly unorthodox behavior, in which the main
> document window has finder-like icons that represent individual data
> documents. Double clicking an icon opens one (or more) views of the
> document data. I'd like to set it so that closing the data view windows
> does not send a closedocument message to the data documents, but just
> hides the data window. Instead, either closing the main icon window
> would send individually closedocument messages to all of the data
> documents, or else highlighting a single icon and deleting it (for
> example) would send the same message to just that one data document.
>
> Is there an override to do this?

Implement -windowWillClose in the window's delegate method. Do whatever
you want in that method, and then return YES if you still want the
window to close, and NO if you don't.

-jcr

[None]

In article <3F3F5DD4.99C027D8@nospam.idiom.com>, John C. Randolph
<jcr@nospam.idiom.com> wrote:

> > Is there an override to do this?

>
> Implement -windowWillClose in the window's delegate method. Do whatever
> you want in that method, and then return YES if you still want the
> window to close, and NO if you don't.
>
> -jcr

Thanks for the suggestion. That almost works perfectly. I actually used
windowShouldClose, since windowWillClose is called later. I overrode it
as:

- (BOOL)windowShouldClose:(id)sender
{
[sender orderOut:self];
return NO;
}

and the window nicely disappears, but still sticks around. The only
remaining problem is if the window contents have changed, before either
windowShouldClose or windowWillClose get called, the "Do you want to
save changes" dialog appears. This really disrupts the work flow (for
the user), and should not be asked until the document really is about
to close. Do you know how I can block that dialog from showing up? I
was thinking about messing with the setWindowIsEdited thing all the
time to make the system think the window contents have not really
changed, but somehow that seems a bit risky in case I forget to set it
back...

Thanks very much

[Michael Ash]

In article <170820030829201894%none@none.com>, None <none@none.com>
wrote:

> Weird, Is this a bug in Cocoa? I tried an alternative strategy, in
> which instead of using the "close" behavior, I just use the minimize
> window function to unclutter the screen. Clicking the window minimize
> button of course works as usual, and the window genies down in about 1
> second (on a 400 MHz Pismo). I made a new menu command (shift-apple-W)
> with the command to firstResponder to performMiniturize. When I run the
> application (either from project builder, or on its own), the menu
> command works, but it take over five seconds for the window to shrink
> down into the dock!! Has anyone else seen this sort of strange
> behavior before?

Hold down the shift key and hit the minimize button in any window of any
app, you'll see the same behavior. It's some kind of demonstration
thing. Use a key combo that doesn't involve shift.

[Paul Mitchum]

None <none@none.com> wrote:

> I'd like to have a slightly unorthodox behavior, in which the main
> document window has finder-like icons that represent individual data
> documents. Double clicking an icon opens one (or more) views of the
> document data. [..]

[..]

> Thanks for the suggestion. That almost works perfectly. I actually used
> windowShouldClose, since windowWillClose is called later. I overrode it
> as:
>
> - (BOOL)windowShouldClose:(id)sender
> {
> [sender orderOut:self];
> return NO;
> }
>
> and the window nicely disappears, but still sticks around. The only
> remaining problem is if the window contents have changed, before either
> windowShouldClose or windowWillClose get called, the "Do you want to save
> changes" dialog appears. This really disrupts the work flow (for the
> user), and should not be asked until the document really is about to
> close. Do you know how I can block that dialog from showing up? I was
> thinking about messing with the setWindowIsEdited thing all the time to
> make the system think the window contents have not really changed, but
> somehow that seems a bit risky in case I forget to set it back...

To change the behavior of the 'do you want to save?' process for your
document, you have to override
shouldCloseWindowController:delegate:shouldCloseSe lector:contextInfo
and/or it's matching canCloseDocumentWithDelegate:etc:etc method, both
in NSDocument. They're pretty confusing, compared to the rest of the
document system. Helpful sample code here:
<http://makeashorterlink.com/?H19D23D95>

If your document class does what it should, and creates a separate
windowcontroller for each sub-view, then you can use the first argument
of shouldCloseWindowController to figure out if the user is closing the
main document window, or one of the sub-view windows. You can allow
sub-views to close regardless, and you can allow the default behavior
for the main window.

If you're making a new document object for each subview, then you get to
do the same thing with canCloseDocumentWithDelegate:etc:etc:.

HTH.

[Doc O'Leary]

In article <mail-5F7E48.10062817082003@localhost>,
Michael Ash <mail@mikeash.com> wrote:

> Hold down the shift key and hit the minimize button in any window of any
> app, you'll see the same behavior. It's some kind of demonstration
> thing. Use a key combo that doesn't involve shift.

The standard one being command+M, which is already in the Window menu of
a Cocoa app.

[None]

In article <1fzu61p.9hnpn5ospglvN%usenet@mile23.com>, Paul Mitchum
<usenet@mile23.com> wrote:

> To change the behavior of the 'do you want to save?' process for your
> document, you have to override
> shouldCloseWindowController:delegate:shouldCloseSe lector:contextInfo
> and/or it's matching canCloseDocumentWithDelegate:etc:etc method, both
> in NSDocument. They're pretty confusing, compared to the rest of the
> document system. Helpful sample code here:
> <http://makeashorterlink.com/?H19D23D95>
>
> If your document class does what it should, and creates a separate
> windowcontroller for each sub-view, then you can use the first argument
> of shouldCloseWindowController to figure out if the user is closing the
> main document window, or one of the sub-view windows. You can allow
> sub-views to close regardless, and you can allow the default behavior
> for the main window.
>
> If you're making a new document object for each subview, then you get to
> do the same thing with canCloseDocumentWithDelegate:etc:etc:.
>
> HTH.

Thanks, that seems to be exactly what I want to override. As you say,
it's a bit more complicated than the "user servicible" functions, and I
can't seem to get it to compile. When I put in the:

void (*callback)(id, SEL, NSDocument *, BOOL, void *) =
(void (*)(id, SEL, NSDocument *, BOOL, void *))objc_msgSend;

part, project builder complains that "objc_msgSend is undeclared"
The documentation on objc_msgSend does not clarify what header file
should be included, and the usage looks different. Do you know what I
should add to be able to use it in this context?

thanks very much for your help

[Michael Ash]

In article <200820032221511238%none@none.com>, None <none@none.com>
wrote:

> part, project builder complains that "objc_msgSend is undeclared"
> The documentation on objc_msgSend does not clarify what header file
> should be included, and the usage looks different. Do you know what I
> should add to be able to use it in this context?

[Foobar:~] mikeash% grep -r objc_msgSend /usr/include
[snip]
/usr/include/objc/objc-runtime.h:OBJC_EXPORT id objc_msgSend(id self,
SEL op, ...);
[snip]