Professional Web Applications Themes

Cocoa, changing window close behavior? - Mac Programming

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 doent window has finder-like icons that represent individual data doents. Double clicking an icon opens one (or more) views of the doent data. I'd like to set it so that closing the data view windows does not send a closedoent message to the data doents, but just hides the data window. Instead, either closing the main icon window would send individually closedoent messages to all of the data doents, or else highlighting a single icon ...

  1. #1

    Default Cocoa, changing window close behavior?

    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
    doent window has finder-like icons that represent individual data
    doents. Double clicking an icon opens one (or more) views of the
    doent data. I'd like to set it so that closing the data view windows
    does not send a closedoent message to the data doents, but just
    hides the data window. Instead, either closing the main icon window
    would send individually closedoent messages to all of the data
    doents, or else highlighting a single icon and deleting it (for
    example) would send the same message to just that one data doent.

    Is there an override to do this?

    thanks,

    Rick
    None Guest

  2. #2

    Default Re: Cocoa, changing window close behavior?

    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
    > doent window has finder-like icons that represent individual data
    > doents. Double clicking an icon opens one (or more) views of the
    > doent data. I'd like to set it so that closing the data view windows
    > does not send a closedoent message to the data doents, but just
    > hides the data window. Instead, either closing the main icon window
    > would send individually closedoent messages to all of the data
    > doents, or else highlighting a single icon and deleting it (for
    > example) would send the same message to just that one data doent.
    >
    > 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
    John C. Randolph Guest

  3. #3

    Default Re: Cocoa, changing window close behavior?

    In article <3F3F5DD4.99C027D8nospam.idiom.com>, John C. Randolph
    <jcrnospam.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 doent 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
    None Guest

  4. #4

    Default Re: Cocoa, changing window close behavior?

    In article <170820030829201894%nonenone.com>, None <nonenone.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.
    Michael Ash Guest

  5. #5

    Default Re: Cocoa, changing window close behavior?

    None <nonenone.com> wrote:
    > I'd like to have a slightly unorthodox behavior, in which the main
    > doent window has finder-like icons that represent individual data
    > doents. Double clicking an icon opens one (or more) views of the
    > doent 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 doent 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
    doent, you have to override
    shouldCloseWindowController:delegate:shouldCloseSe lector:contextInfo
    and/or it's matching canCloseDoentWithDelegate:etc:etc method, both
    in NSDoent. They're pretty confusing, compared to the rest of the
    doent system. Helpful sample code here:
    <http://makeashorterlink.com/?H19D23D95>

    If your doent 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 doent 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 doent object for each subview, then you get to
    do the same thing with canCloseDoentWithDelegate:etc:etc:.

    HTH.
    Paul Mitchum Guest

  6. #6

    Default Re: Cocoa, changing window close behavior?

    In article <mail-5F7E48.10062817082003localhost>,
    Michael Ash <mailmikeash.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.
    Doc O'Leary Guest

  7. #7

    Default Re: Cocoa, changing window close behavior?

    In article <1fzu61p.9hnpn5ospglvN%usenetmile23.com>, Paul Mitchum
    <usenetmile23.com> wrote:
    > To change the behavior of the 'do you want to save?' process for your
    > doent, you have to override
    > shouldCloseWindowController:delegate:shouldCloseSe lector:contextInfo
    > and/or it's matching canCloseDoentWithDelegate:etc:etc method, both
    > in NSDoent. They're pretty confusing, compared to the rest of the
    > doent system. Helpful sample code here:
    > <http://makeashorterlink.com/?H19D23D95>
    >
    > If your doent 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 doent 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 doent object for each subview, then you get to
    > do the same thing with canCloseDoentWithDelegate: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, NSDoent *, BOOL, void *) =
    (void (*)(id, SEL, NSDoent *, BOOL, void *))objc_msgSend;

    part, project builder complains that "objc_msgSend is undeclared"
    The doentation 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
    None Guest

  8. #8

    Default Re: Cocoa, changing window close behavior?

    In article <200820032221511238%nonenone.com>, None <nonenone.com>
    wrote:
    > part, project builder complains that "objc_msgSend is undeclared"
    > The doentation 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]
    Michael Ash Guest

Similar Threads

  1. Modeless dialog parent window in Cocoa
    By ZZmiy@adobeforums.com in forum Adobe Acrobat SDK
    Replies: 4
    Last Post: September 16th, 08:30 AM
  2. Close Window Behavior
    By antartida in forum Macromedia Exchange Dreamweaver Extensions
    Replies: 1
    Last Post: July 13th, 07:03 PM
  3. close my project that is in a browser window (close this window)
    By Carlos Gonçalves in forum Macromedia Director Lingo
    Replies: 2
    Last Post: November 14th, 02:24 PM
  4. Fixing Tab Order in Cocoa Window
    By ifiaz in forum Mac Programming
    Replies: 2
    Last Post: September 29th, 03:55 PM
  5. multiple doent and window types in cocoa
    By matt neuburg in forum Mac Programming
    Replies: 0
    Last Post: July 21st, 02:35 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139