Window cascading

  • Hello,

    I create a window like this:

    id window = [[[NSWindow alloc] initWithContentRect:NSMakeRect(0, 0, 200,
    200) styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered
    defer:NO] autorelease];
    [window cascadeTopLeftFromPoint:NSMakePoint(20,20)];

    but it cascades just vertically - the next window is positioned to the very
    top left of my screen, the next one is just 20px lower (and 0px right), the
    next one is again 20px lower than the previous one but it wont move
    horizontally.

    Why's that? Do I have to remember the returned NSPoint and pass it to
    next cascadeTopLeftFromPoint:?

    Kind regards,

    Ecir Hana
  • On May 8, 2012, at 3:01 AM, ecir hana wrote:

    > I create a window like this:
    >
    > id window = [[[NSWindow alloc] initWithContentRect:NSMakeRect(0, 0, 200,
    > 200) styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered
    > defer:NO] autorelease];
    > [window cascadeTopLeftFromPoint:NSMakePoint(20,20)];
    >
    > but it cascades just vertically - the next window is positioned to the very
    > top left of my screen, the next one is just 20px lower (and 0px right), the
    > next one is again 20px lower than the previous one but it wont move
    > horizontally.
    >
    > Why's that? Do I have to remember the returned NSPoint and pass it to
    > next cascadeTopLeftFromPoint:?

    If I remember correctly you are using the document architecture. The documentation has this to say.

    "If you use the Cocoa document architecture, you can use the setShouldCascadeWindows: method of NSWindowController to set whether the window, when it is displayed, should cascade in relation to other document windows (that is, have a slightly offset location so that the title bars of previously displayed windows are still visible). The default is true, so typically you have no additional work to perform.

    If you are not using the document architecture, you can use the cascadeTopLeftFromPoint: method ofNSWindow to cascade windows yourself. The method returns a point shifted from the top-left corner of the window that can be passed to a subsequent invocation of cascadeTopLeftFromPoint: to position the next window so the title bars of both windows are fully visible."

    http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinP
    anel/Tasks/SizingPlacingWindows.html


    Have you examined the EnhancedDataBurn sample code? It has two examples of where -[NSWindow cascadeTopLeftFromPoint:] is used.

    http://developer.apple.com/library/mac/#samplecode/EnhancedDataBurn/Introdu
    ction/Intro.html


    --Richard
  • Thank you for the reply!

    Yes, document-based.

    However, not sure if it is an issue, but I have my own subclassed window
    controller. The docs also say that the default for "shouldCascadeWindows"
    is YES. I tried to set it to YES in "setShouldCascadeWindows:", without
    luck.

    I look at the EnhancedDataBurn example but it uses the origin of already
    shown window, which is slightly different than my case, I believe.

    On Tue, May 8, 2012 at 4:35 PM, Richard Somers <rsomers123...>wrote:

    > On May 8, 2012, at 3:01 AM, ecir hana wrote:
    >
    >> I create a window like this:
    >>
    >> id window = [[[NSWindow alloc] initWithContentRect:NSMakeRect(0, 0, 200,
    >> 200) styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered
    >> defer:NO] autorelease];
    >> [window cascadeTopLeftFromPoint:NSMakePoint(20,20)];
    >>
    >> but it cascades just vertically - the next window is positioned to the
    > very
    >> top left of my screen, the next one is just 20px lower (and 0px right),
    > the
    >> next one is again 20px lower than the previous one but it wont move
    >> horizontally.
    >>
    >> Why's that? Do I have to remember the returned NSPoint and pass it to
    >> next cascadeTopLeftFromPoint:?
    >
    > If I remember correctly you are using the document architecture. The
    > documentation has this to say.
    >
    > "If you use the Cocoa document architecture, you can use the
    > setShouldCascadeWindows: method of NSWindowController to set whether the
    > window, when it is displayed, should cascade in relation to other document
    > windows (that is, have a slightly offset location so that the title bars of
    > previously displayed windows are still visible). The default is true, so
    > typically you have no additional work to perform.
    >
    > If you are not using the document architecture, you can use the
    > cascadeTopLeftFromPoint: method ofNSWindow to cascade windows yourself. The
    > method returns a point shifted from the top-left corner of the window that
    > can be passed to a subsequent invocation of cascadeTopLeftFromPoint: to
    > position the next window so the title bars of both windows are fully
    > visible."
    >
    >
    > http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinP
    anel/Tasks/SizingPlacingWindows.html

    >
    > Have you examined the EnhancedDataBurn sample code? It has two examples of
    > where -[NSWindow cascadeTopLeftFromPoint:] is used.
    >
    >
    > http://developer.apple.com/library/mac/#samplecode/EnhancedDataBurn/Introdu
    ction/Intro.html

    >
    > --Richard
    >
    >
  • On May 8, 2012, at 8:51 AM, ecir hana wrote:

    > Yes, document-based.
    >
    > However, not sure if it is an issue, but I have my own subclassed window controller. The docs also say that the default for "shouldCascadeWindows" is YES. I tried to set it to YES in "setShouldCascadeWindows:", without luck.
    >
    > I look at the EnhancedDataBurn example but it uses the origin of already shown window, which is slightly different than my case, I believe.

    I would suggest that you download the solutions for Cocoa Programming For Mac OS X (3rd Edition) and look at Chapter 10_Archiving. This chapter contains a modern fully functional document based sample application with window cascading working perfectly. You should be able to quickly get the sample project up and running in a few minutes in Xcode 4.2 by validating the project build settings and setting the default SDK.

    http://www.bignerdranch.com/book/cocoa_programming_for_mac_os_x_rd_edition_

    Subclassing the window controller is a more advanced topic and if I were you I would not focus on that right now.

    --Richard
  • Thanks! Will look at it.

    On Tue, May 8, 2012 at 5:22 PM, Richard Somers <rsomers123...>wrote:

    > On May 8, 2012, at 8:51 AM, ecir hana wrote:
    >
    >> Yes, document-based.
    >>
    >> However, not sure if it is an issue, but I have my own subclassed window
    > controller. The docs also say that the default for "shouldCascadeWindows"
    > is YES. I tried to set it to YES in "setShouldCascadeWindows:", without
    > luck.
    >>
    >> I look at the EnhancedDataBurn example but it uses the origin of already
    > shown window, which is slightly different than my case, I believe.
    >
    > I would suggest that you download the solutions for Cocoa Programming For
    > Mac OS X (3rd Edition) and look at Chapter 10_Archiving. This chapter
    > contains a modern fully functional document based sample application with
    > window cascading working perfectly. You should be able to quickly get the
    > sample project up and running in a few minutes in Xcode 4.2 by validating
    > the project build settings and setting the default SDK.
    >
    > http://www.bignerdranch.com/book/cocoa_programming_for_mac_os_x_rd_edition_
    >
    > Subclassing the window controller is a more advanced topic and if I were
    > you I would not focus on that right now.
    >
    > --Richard
    >
    >
  • On May 8, 2012, at 2:01 AM, ecir hana <ecir.hana...> wrote:

    > Why's that? Do I have to remember the returned NSPoint and pass it to
    > next cascadeTopLeftFromPoint:?

    Yes; the usual pattern is:

    static NSPoint cascadeLoc = {0, 0};
    cascadeLoc = [window cascadeTopLeftFromPoint:cascadeLoc];

    The first time this is called (with 0, 0) the window won't be moved, so the window's initial position in the nib should be something reasonable (or call -center on it before cascade).

    Hope that helps,
    -Peter
  • On Wed, May 9, 2012 at 5:08 AM, Peter Ammon <pammon...> wrote:

    >
    > Hope that helps,
    >

    It did. Thanks!
previous month may 2012 next month
MTWTFSS
  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      
Go to today