Fullscreen on secondary displays

  • Hello everyone,

    I have an app right now that I've added a fullscreen mode to.  RIght
    now it works for fullscreen when I go to fullscreen on the main
    display.  If I attempt to do this on the secondary display, I get a
    blank screen.

    I think one problem is probably the way I am identifying which screen
    to use -- I use [NSWindow screen] to find where my current window is
    and use that to capture the screen and place a new fullscreen window
    over it.  One potential problem I see is when the window spans across
    two displays -- how do I reasonably choose which screen to display it
    on?  What screen does [NSWindow screen] return?

    So to recap -- this code currently works correctly in the case when
    the _mainWindow is on the primary display.  The code does not work
    correctly when it is on a secondary display.  And I haven't tested the
    case where the code spans displays -- I am assuming that it just flat
    out doesn't work :)

    here is the code from my enterFullscreen method -- mostly pulled from
    sample code off developer.apple.com:

    -(void)enterFullscreen
    {
    NSScreen *windowScreen = [_mainWindow screen];
    NSDictionary *screenInfo = [windowScreen deviceDescription];
    NSNumber *screenID = [screenInfo objectForKey:@"NSScreenNumber"];

    // capture the screen
    CGDirectDisplayID displayID = (CGDirectDisplayID)[screenID longValue];
    CGDisplayErr err = CGDisplayCapture(displayID);
    if(err == CGDisplayNoErr) {
      if(!_fullscreenWindow) {
                // Create the full-screen window.
                NSRect winRect = [windowScreen frame];
                _fullscreenWindow = [[NSWindow alloc]
    initWithContentRect:winRect styleMask:NSBorderlessWindowMask
    backing:NSBackingStoreBuffered defer:NO screen:windowScreen];

                // Establish the window attributes.
                [_fullscreenWindow setReleasedWhenClosed:NO];
                [_fullscreenWindow setDisplaysWhenScreenProfileChanges:YES];
                [_fullscreenWindow setDelegate:self];
            }

      // move our view over to the fullscreen window
      [_mainWindow setContentView:nil];
      [_fullscreenWindow setContentView:_mainView];
      [_mainWindow setNeedsDisplay:YES];

            // The window has to be above the level of the shield window.
            int32_t    shieldLevel = CGShieldingWindowLevel();
            [_fullscreenWindow setLevel:shieldLevel];

            // Show the window.
            [_fullscreenWindow makeKeyAndOrderFront:self];

      _fullscreenFlag = YES;
    }
    }

    Sorry about the formatting -- it got a bit messed up when i pasted it
    into gmail.

    Thanks!
    dennis
  • On May 13, 2008, at 12:11 PM, Dennis Munsie wrote:

    > I have an app right now that I've added a fullscreen mode to.  RIght
    > now it works for fullscreen when I go to fullscreen on the main
    > display.  If I attempt to do this on the secondary display, I get a
    > blank screen.
    >
    > I think one problem is probably the way I am identifying which screen
    > to use -- I use [NSWindow screen] to find where my current window is
    > and use that to capture the screen and place a new fullscreen window
    > over it.  One potential problem I see is when the window spans across
    > two displays -- how do I reasonably choose which screen to display it
    > on?  What screen does [NSWindow screen] return?
    >
    > So to recap -- this code currently works correctly in the case when
    > the _mainWindow is on the primary display.  The code does not work
    > correctly when it is on a secondary display.  And I haven't tested the
    > case where the code spans displays -- I am assuming that it just flat
    > out doesn't work :)
    >
    > here is the code from my enterFullscreen method -- mostly pulled from
    > sample code off developer.apple.com:
    >
    > -(void)enterFullscreen
    > {
    > NSScreen *windowScreen = [_mainWindow screen];
    > NSDictionary *screenInfo = [windowScreen deviceDescription];
    > NSNumber *screenID = [screenInfo objectForKey:@"NSScreenNumber"];
    >
    > // capture the screen
    > CGDirectDisplayID displayID = (CGDirectDisplayID)[screenID
    > longValue];
    > CGDisplayErr err = CGDisplayCapture(displayID);
    > if(err == CGDisplayNoErr) {
    > if(!_fullscreenWindow) {
    > // Create the full-screen window.
    > NSRect winRect = [windowScreen frame];
    > _fullscreenWindow = [[NSWindow alloc]
    > initWithContentRect:winRect styleMask:NSBorderlessWindowMask
    > backing:NSBackingStoreBuffered defer:NO screen:windowScreen];
    >
    > // Establish the window attributes.
    > [_fullscreenWindow setReleasedWhenClosed:NO];
    > [_fullscreenWindow
    > setDisplaysWhenScreenProfileChanges:YES];
    > [_fullscreenWindow setDelegate:self];
    > }
    >
    > // move our view over to the fullscreen window
    > [_mainWindow setContentView:nil];
    > [_fullscreenWindow setContentView:_mainView];
    > [_mainWindow setNeedsDisplay:YES];
    >
    > // The window has to be above the level of the shield window.
    > int32_t    shieldLevel = CGShieldingWindowLevel();
    > [_fullscreenWindow setLevel:shieldLevel];
    >
    > // Show the window.
    > [_fullscreenWindow makeKeyAndOrderFront:self];
    >
    > _fullscreenFlag = YES;
    > }
    > }

    Ack.  Do not expect to use AppKit with a captured display.  I really
    wish all those archived code examples out there would just vanish;
    just leads to more folks doing this.

    Anyhow, if you really must capture the display using the CG APIs,
    please note that there's different mechanisms for getting data onto
    the screen.  Search cocoa-dev and quartz-dev for the details on why
    you cannot use AppKit with captured displays.

    If you must use AppKit, you can always use a call to SetSystemUIMode
    (to hide menu bar and dock).  Then, enumerate all screens and put up
    "blanking" windows on each one.  Then, put up your "content" window
    over a particular blanking one.  See the child window APIs for how you
    can ensure that the content window is never brought forward over the
    blanking one.

    This latter approach is what I've done for the past few years and has
    worked great.

    ___________________________________________________________
    Ricky A. Sharp        mailto:<rsharp...>
    Instant Interactive(tm)  http://www.instantinteractive.com
  • In this case, what I am trying to accomplish is something along the
    lines of how Keynote and Powerpoint behave.  I only want to take over
    one display, most likely connected up to a projector.  But, I also
    occasionally want to have it in a window.  I'm not expecting any
    controls to work -- this is strictly a view-only window.

    Also -- the code currently works just fine for the case of a single
    display machine or when the window is on the main display.  I just
    need to make it work when the window is on another display.

    thanks!
    dennis

    On Tue, May 13, 2008 at 4:23 PM, Ricky Sharp <rsharp...> wrote:
    >
    >
    > Ack.  Do not expect to use AppKit with a captured display.  I really wish
    > all those archived code examples out there would just vanish; just leads to
    > more folks doing this.
    >
    > Anyhow, if you really must capture the display using the CG APIs, please
    > note that there's different mechanisms for getting data onto the screen.
    > Search cocoa-dev and quartz-dev for the details on why you cannot use AppKit
    > with captured displays.
    >
    > If you must use AppKit, you can always use a call to SetSystemUIMode (to
    > hide menu bar and dock).  Then, enumerate all screens and put up "blanking"
    > windows on each one.  Then, put up your "content" window over a particular
    > blanking one.  See the child window APIs for how you can ensure that the
    > content window is never brought forward over the blanking one.
    >
    > This latter approach is what I've done for the past few years and has
    > worked great.
    >
    > ___________________________________________________________
    > Ricky A. Sharp        mailto:<rsharp...>
    > Instant Interactive(tm)  http://www.instantinteractive.com
    >
    >

    --
    dennis
  • None of this really refutes what Ricky posted.
    You are just lucky that it works in the one-display case. It really
    isn't designed to work, and on some configurations, it just won't.
    Is there anything preventing you from following Ricky's advice?

    Dennis Munsie wrote:
    > In this case, what I am trying to accomplish is something along the
    > lines of how Keynote and Powerpoint behave.  I only want to take over
    > one display, most likely connected up to a projector.  But, I also
    > occasionally want to have it in a window.  I'm not expecting any
    > controls to work -- this is strictly a view-only window.
    >
    > Also -- the code currently works just fine for the case of a single
    > display machine or when the window is on the main display.  I just
    > need to make it work when the window is on another display.
    >
    > thanks!
    > dennis
    >
    > On Tue, May 13, 2008 at 4:23 PM, Ricky Sharp <rsharp...> wrote:
    >
    >> Ack.  Do not expect to use AppKit with a captured display.  I really wish
    >> all those archived code examples out there would just vanish; just leads to
    >> more folks doing this.
    >>
    >> Anyhow, if you really must capture the display using the CG APIs, please
    >> note that there's different mechanisms for getting data onto the screen.
    >> Search cocoa-dev and quartz-dev for the details on why you cannot use AppKit
    >> with captured displays.
    >>
    >> If you must use AppKit, you can always use a call to SetSystemUIMode (to
    >> hide menu bar and dock).  Then, enumerate all screens and put up "blanking"
    >> windows on each one.  Then, put up your "content" window over a particular
    >> blanking one.  See the child window APIs for how you can ensure that the
    >> content window is never brought forward over the blanking one.
    >>
    >> This latter approach is what I've done for the past few years and has
    >> worked great.
    >>
    >> ___________________________________________________________
    >> Ricky A. Sharp        mailto:<rsharp...>
    >> Instant Interactive(tm)  http://www.instantinteractive.com
    >>
    >>
    >>
    >
    >
    >
    >
  • I was playing a bit with Cocoa and full screen and I wrote a quick blog
    entry about it: http://everburning.com/news/going-fullscreen-with-medium/

    I'm not sure if it's the correct way, or the best way, but it does seem to
    work for me (although I believe it will limit the OS version you can run
    under).

    dan

    On Tue, May 13, 2008 at 1:40 PM, Dennis Munsie <dmunsie...> wrote:

    > In this case, what I am trying to accomplish is something along the
    > lines of how Keynote and Powerpoint behave.  I only want to take over
    > one display, most likely connected up to a projector.  But, I also
    > occasionally want to have it in a window.  I'm not expecting any
    > controls to work -- this is strictly a view-only window.
    >
    > Also -- the code currently works just fine for the case of a single
    > display machine or when the window is on the main display.  I just
    > need to make it work when the window is on another display.
    >
    > thanks!
    > dennis
    >
    > On Tue, May 13, 2008 at 4:23 PM, Ricky Sharp <rsharp...> wrote:
    >>
    >>
    >> Ack.  Do not expect to use AppKit with a captured display.  I really
    > wish
    >> all those archived code examples out there would just vanish; just leads
    > to
    >> more folks doing this.
    >>
    >> Anyhow, if you really must capture the display using the CG APIs,
    > please
    >> note that there's different mechanisms for getting data onto the screen.
    >> Search cocoa-dev and quartz-dev for the details on why you cannot use
    > AppKit
    >> with captured displays.
    >>
    >> If you must use AppKit, you can always use a call to SetSystemUIMode
    > (to
    >> hide menu bar and dock).  Then, enumerate all screens and put up
    > "blanking"
    >> windows on each one.  Then, put up your "content" window over a
    > particular
    >> blanking one.  See the child window APIs for how you can ensure that the
    >> content window is never brought forward over the blanking one.
    >>
    >> This latter approach is what I've done for the past few years and has
    >> worked great.
    >
  • Other than me wanting to avoid re-writing my view drawing code?  :)

    I will probably look into doing this -- of the unanswered questions
    that I have is will I be able to toggle (relatively) easily between a
    full-screen context and a windowed context?  Do I need to completely
    throw out my NS* drawing code?  Or can I legitimately get away with
    throwing out my NSWindow and NSView usage while in fullscreen mode?

    Part of this stems from the fact that this is only a personal use app
    right now -- so I'm not necessarily tied to the right way of doing
    things at the moment.  If I decide to distribute this in any way, I
    would be all for ripping things out and re-writing as necessary.  But
    right now, I just need to have something working on my laptop only :)

    thanks!
    dennis

    On Tue, May 13, 2008 at 5:00 PM, John Stiles <JStiles...> wrote:
    >
    > None of this really refutes what Ricky posted.
    > You are just lucky that it works in the one-display case. It really isn't
    > designed to work, and on some configurations, it just won't.
    > Is there anything preventing you from following Ricky's advice?
    >
    >
    >
    >
    > Dennis Munsie wrote:
    > In this case, what I am trying to accomplish is something along the
    > lines of how Keynote and Powerpoint behave. I only want to take over
    > one display, most likely connected up to a projector. But, I also
    > occasionally want to have it in a window. I'm not expecting any
    > controls to work -- this is strictly a view-only window.
    >
    > Also -- the code currently works just fine for the case of a single
    > display machine or when the window is on the main display. I just
    > need to make it work when the window is on another display.
    >
    > thanks!
    > dennis
    >
    > On Tue, May 13, 2008 at 4:23 PM, Ricky Sharp <rsharp...> wrote:
    >
    >
    > Ack. Do not expect to use AppKit with a captured display. I really wish
    > all those archived code examples out there would just vanish; just leads to
    > more folks doing this.
    >
    > Anyhow, if you really must capture the display using the CG APIs, please
    > note that there's different mechanisms for getting data onto the screen.
    > Search cocoa-dev and quartz-dev for the details on why you cannot use AppKit
    > with captured displays.
    >
    > If you must use AppKit, you can always use a call to SetSystemUIMode (to
    > hide menu bar and dock). Then, enumerate all screens and put up "blanking"
    > windows on each one. Then, put up your "content" window over a particular
    > blanking one. See the child window APIs for how you can ensure that the
    > content window is never brought forward over the blanking one.
    >
    > This latter approach is what I've done for the past few years and has
    > worked great.
    >
    > ___________________________________________________________
    > Ricky A. Sharp mailto:<rsharp...>
    > Instant Interactive(tm) http://www.instantinteractive.com
    >
    >
    >
    >
    >
    >
    >

    --
    dennis
  • Switch to fullscreen in a couple of line and without capturing display
    ('uiView' is your custom view with custom drawing code):

        SetSystemUIMode(kUIModeAllSuppressed, kUIOptionAutoShowMenuBar);
        NSScreen *screen = [[uiView window] screen];
        NSWindow *window = [[NSWindow alloc] initWithContentRect:[screen
    frame]

    styleMask:NSBorderlessWindowMask

    backing:NSBackingStoreBuffered
                                                            defer:NO
                                                          screen:screen];
        [uiView retain];
        [uiView removeFromSuperview];
        [window setContentView:uiView];
        [uiView release];
        [window makeKeyAndOrderFront:sender];
        [NSCursor setHiddenUntilMouseMoves:YES];

    Revert to the window mode is left as an exercice for the reader ;-)

    Le 13 mai 08 à 23:47, Dennis Munsie a écrit :

    > Other than me wanting to avoid re-writing my view drawing code?  :)
    >
    > I will probably look into doing this -- of the unanswered questions
    > that I have is will I be able to toggle (relatively) easily between a
    > full-screen context and a windowed context?  Do I need to completely
    > throw out my NS* drawing code?  Or can I legitimately get away with
    > throwing out my NSWindow and NSView usage while in fullscreen mode?
    >
    > Part of this stems from the fact that this is only a personal use app
    > right now -- so I'm not necessarily tied to the right way of doing
    > things at the moment.  If I decide to distribute this in any way, I
    > would be all for ripping things out and re-writing as necessary.  But
    > right now, I just need to have something working on my laptop only :)
    >
    > thanks!
    > dennis
    >
    > On Tue, May 13, 2008 at 5:00 PM, John Stiles <JStiles...>
    > wrote:
    >>
    >> None of this really refutes what Ricky posted.
    >> You are just lucky that it works in the one-display case. It really
    >> isn't
    >> designed to work, and on some configurations, it just won't.
    >> Is there anything preventing you from following Ricky's advice?
    >>
    >>
    >>
    >>
    >> Dennis Munsie wrote:
    >> In this case, what I am trying to accomplish is something along the
    >> lines of how Keynote and Powerpoint behave. I only want to take over
    >> one display, most likely connected up to a projector. But, I also
    >> occasionally want to have it in a window. I'm not expecting any
    >> controls to work -- this is strictly a view-only window.
    >>
    >> Also -- the code currently works just fine for the case of a single
    >> display machine or when the window is on the main display. I just
    >> need to make it work when the window is on another display.
    >>
    >> thanks!
    >> dennis
    >>
    >> On Tue, May 13, 2008 at 4:23 PM, Ricky Sharp <rsharp...> wrote:
    >>
    >>
    >> Ack. Do not expect to use AppKit with a captured display. I really
    >> wish
    >> all those archived code examples out there would just vanish; just
    >> leads to
    >> more folks doing this.
    >>
    >> Anyhow, if you really must capture the display using the CG APIs,
    >> please
    >> note that there's different mechanisms for getting data onto the
    >> screen.
    >> Search cocoa-dev and quartz-dev for the details on why you cannot
    >> use AppKit
    >> with captured displays.
    >>
    >> If you must use AppKit, you can always use a call to
    >> SetSystemUIMode (to
    >> hide menu bar and dock). Then, enumerate all screens and put up
    >> "blanking"
    >> windows on each one. Then, put up your "content" window over a
    >> particular
    >> blanking one. See the child window APIs for how you can ensure that
    >> the
    >> content window is never brought forward over the blanking one.
    >>
    >> This latter approach is what I've done for the past few years and has
    >> worked great.
    >
  • This code worked for me -- with one change: the NSRect from [screen
    frame] has the offset set to it's relative location to the main
    display.  This is what was throwing me off the entire time :)  By
    setting the offset to 0,0 I was able to get a visible full screen
    window.

    BTW -- not that it matters for the app that I'm working on, but since
    SetSystemUIMode is in Carbon, are there plans to move it to Cocoa?  Is
    this function available for 64-bit apps?

    Thanks to everyone that helped!

    regards,
    dennis

    On Tue, May 13, 2008 at 6:30 PM, Jean-Daniel Dupas
    <devlists...> wrote:
    > Switch to fullscreen in a couple of line and without capturing display
    > ('uiView' is your custom view with custom drawing code):
    >
    >
    > SetSystemUIMode(kUIModeAllSuppressed, kUIOptionAutoShowMenuBar);
    > NSScreen *screen = [[uiView window] screen];
    > NSWindow *window = [[NSWindow alloc] initWithContentRect:[screen frame]
    >
    > styleMask:NSBorderlessWindowMask
    >
    > backing:NSBackingStoreBuffered
    > defer:NO
    > screen:screen];
    > [uiView retain];
    > [uiView removeFromSuperview];
    > [window setContentView:uiView];
    > [uiView release];
    > [window makeKeyAndOrderFront:sender];
    > [NSCursor setHiddenUntilMouseMoves:YES];
    >
    >
    > Revert to the window mode is left as an exercice for the reader ;-)
    >
    >
    >
    > Le 13 mai 08 à 23:47, Dennis Munsie a écrit :
    >
    >
    > Other than me wanting to avoid re-writing my view drawing code?  :)
    >
    > I will probably look into doing this -- of the unanswered questions
    > that I have is will I be able to toggle (relatively) easily between a
    > full-screen context and a windowed context?  Do I need to completely
    > throw out my NS* drawing code?  Or can I legitimately get away with
    > throwing out my NSWindow and NSView usage while in fullscreen mode?
    >
    > Part of this stems from the fact that this is only a personal use app
    > right now -- so I'm not necessarily tied to the right way of doing
    > things at the moment.  If I decide to distribute this in any way, I
    > would be all for ripping things out and re-writing as necessary.  But
    > right now, I just need to have something working on my laptop only :)
    >
    > thanks!
    > dennis
    >
    > On Tue, May 13, 2008 at 5:00 PM, John Stiles <JStiles...> wrote:
    >
    > None of this really refutes what Ricky posted.
    > You are just lucky that it works in the one-display case. It really isn't
    > designed to work, and on some configurations, it just won't.
    > Is there anything preventing you from following Ricky's advice?
    >
    >
    >
    >
    > Dennis Munsie wrote:
    > In this case, what I am trying to accomplish is something along the
    > lines of how Keynote and Powerpoint behave. I only want to take over
    > one display, most likely connected up to a projector. But, I also
    > occasionally want to have it in a window. I'm not expecting any
    > controls to work -- this is strictly a view-only window.
    >
    > Also -- the code currently works just fine for the case of a single
    > display machine or when the window is on the main display. I just
    > need to make it work when the window is on another display.
    >
    > thanks!
    > dennis
    >
    > On Tue, May 13, 2008 at 4:23 PM, Ricky Sharp <rsharp...> wrote:
    >
    >
    > Ack. Do not expect to use AppKit with a captured display. I really wish
    > all those archived code examples out there would just vanish; just leads to
    > more folks doing this.
    >
    > Anyhow, if you really must capture the display using the CG APIs, please
    > note that there's different mechanisms for getting data onto the screen.
    > Search cocoa-dev and quartz-dev for the details on why you cannot use AppKit
    > with captured displays.
    >
    > If you must use AppKit, you can always use a call to SetSystemUIMode (to
    > hide menu bar and dock). Then, enumerate all screens and put up "blanking"
    > windows on each one. Then, put up your "content" window over a particular
    > blanking one. See the child window APIs for how you can ensure that the
    > content window is never brought forward over the blanking one.
    >
    > This latter approach is what I've done for the past few years and has
    > worked great.
    >
    >
    >

    --
    dennis
  • Yes, this function is available for 64bits app.

    Le 14 mai 08 à 05:30, Dennis Munsie a écrit :

    > This code worked for me -- with one change: the NSRect from [screen
    > frame] has the offset set to it's relative location to the main
    > display.  This is what was throwing me off the entire time :)  By
    > setting the offset to 0,0 I was able to get a visible full screen
    > window.
    >
    > BTW -- not that it matters for the app that I'm working on, but since
    > SetSystemUIMode is in Carbon, are there plans to move it to Cocoa?  Is
    > this function available for 64-bit apps?
    >
    > Thanks to everyone that helped!
    >
    > regards,
    > dennis
    >
    > On Tue, May 13, 2008 at 6:30 PM, Jean-Daniel Dupas
    > <devlists...> wrote:
    >> Switch to fullscreen in a couple of line and without capturing
    >> display
    >> ('uiView' is your custom view with custom drawing code):
    >>
    >>
    >> SetSystemUIMode(kUIModeAllSuppressed, kUIOptionAutoShowMenuBar);
    >> NSScreen *screen = [[uiView window] screen];
    >> NSWindow *window = [[NSWindow alloc] initWithContentRect:[screen
    >> frame]
    >>
    >> styleMask:NSBorderlessWindowMask
    >>
    >> backing:NSBackingStoreBuffered
    >> defer:NO
    >> screen:screen];
    >> [uiView retain];
    >> [uiView removeFromSuperview];
    >> [window setContentView:uiView];
    >> [uiView release];
    >> [window makeKeyAndOrderFront:sender];
    >> [NSCursor setHiddenUntilMouseMoves:YES];
    >>
    >>
    >> Revert to the window mode is left as an exercice for the reader ;-)
    >>
    >>
    >>
    >> Le 13 mai 08 à 23:47, Dennis Munsie a écrit :
    >>
    >>
    >> Other than me wanting to avoid re-writing my view drawing code?  :)
    >>
    >> I will probably look into doing this -- of the unanswered questions
    >> that I have is will I be able to toggle (relatively) easily between a
    >> full-screen context and a windowed context?  Do I need to completely
    >> throw out my NS* drawing code?  Or can I legitimately get away with
    >> throwing out my NSWindow and NSView usage while in fullscreen mode?
    >>
    >> Part of this stems from the fact that this is only a personal use app
    >> right now -- so I'm not necessarily tied to the right way of doing
    >> things at the moment.  If I decide to distribute this in any way, I
    >> would be all for ripping things out and re-writing as necessary.  But
    >> right now, I just need to have something working on my laptop only :)
    >>
    >> thanks!
    >> dennis
    >>
    >> On Tue, May 13, 2008 at 5:00 PM, John Stiles <JStiles...>
    >> wrote:
    >>
    >> None of this really refutes what Ricky posted.
    >> You are just lucky that it works in the one-display case. It really
    >> isn't
    >> designed to work, and on some configurations, it just won't.
    >> Is there anything preventing you from following Ricky's advice?
    >>
    >>
    >>
    >>
    >> Dennis Munsie wrote:
    >> In this case, what I am trying to accomplish is something along the
    >> lines of how Keynote and Powerpoint behave. I only want to take over
    >> one display, most likely connected up to a projector. But, I also
    >> occasionally want to have it in a window. I'm not expecting any
    >> controls to work -- this is strictly a view-only window.
    >>
    >> Also -- the code currently works just fine for the case of a single
    >> display machine or when the window is on the main display. I just
    >> need to make it work when the window is on another display.
    >>
    >> thanks!
    >> dennis
    >>
    >> On Tue, May 13, 2008 at 4:23 PM, Ricky Sharp <rsharp...> wrote:
    >>
    >>
    >> Ack. Do not expect to use AppKit with a captured display. I really
    >> wish
    >> all those archived code examples out there would just vanish; just
    >> leads to
    >> more folks doing this.
    >>
    >> Anyhow, if you really must capture the display using the CG APIs,
    >> please
    >> note that there's different mechanisms for getting data onto the
    >> screen.
    >> Search cocoa-dev and quartz-dev for the details on why you cannot
    >> use AppKit
    >> with captured displays.
    >>
    >> If you must use AppKit, you can always use a call to
    >> SetSystemUIMode (to
    >> hide menu bar and dock). Then, enumerate all screens and put up
    >> "blanking"
    >> windows on each one. Then, put up your "content" window over a
    >> particular
    >> blanking one. See the child window APIs for how you can ensure that
    >> the
    >> content window is never brought forward over the blanking one.
    >>
    >> This latter approach is what I've done for the past few years and has
    >> worked great.
    >>
    >>
    >>
    >
    >
    >
    > --
    > dennis
    >
  • On 5/13/08 11:30 PM, Dennis Munsie said:

    > This code worked for me -- with one change: the NSRect from [screen
    > frame] has the offset set to it's relative location to the main
    > display.  This is what was throwing me off the entire time :)  By
    > setting the offset to 0,0 I was able to get a visible full screen
    > window.
    >
    > BTW -- not that it matters for the app that I'm working on, but since
    > SetSystemUIMode is in Carbon, are there plans to move it to Cocoa?  Is
    > this function available for 64-bit apps?

    You can determine this yourself by looking at its declaration in the
    header. It is available in 64 bit. In 10.5, methods were added to NSView
    to support fullscreen, but they are buggy and do not support the various
    options that SetSystemUIMode provides.  Do file a Radar.

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • Am 14.05.2008 um 00:32 schrieb "dan sinclair" <dj2...>:

    > I was playing a bit with Cocoa and full screen and I wrote a quick
    > blog
    > entry about it: http://everburning.com/news/going-fullscreen-with-
    > medium/
    >
    > I'm not sure if it's the correct way, or the best way, but it does
    > seem to
    > work for me (although I believe it will limit the OS version you
    > can run
    > under).

    A bit late, I know but:

    1) When you pass 25 (seconds) for the reservation time of the fade
    reservation that value exceeds the documented bounds of
    0..kCGMaxDisplayReservationInterval (15.0 s). Use the constant instead.

    2) In fadeIn don't use the synchronous method (TRUE as the last
    parameter to CGDisplayFade). If you use async (FALSE) then the
    CGReleaseDisplayFadeReservation will allow the fade in to complete
    before releasing the token while your app can do other things like
    update the windows. This avoids the white flash of the original
    window (which it would have if it had any non-white content).

    3) CGAcquireDisplayFadeReservation is documented to return an error
    code != kCGErrorSuccess if it fails. You are ignoring that error. It
    might be unlikely that someone else has reserved the fade hardware
    but it is still possible. So you should deal with error conditions.

    4) You might want to add a comment saying that your code is for 10.5+
    only. NSView methods like isInFullScreenMode,
    exitFullScreenModeWithOptions: and enterFullScreenMode:withOptions:
    don't exist pre Leopard. It wouldn't be too hard to work around that
    though.

    Otherwise it's a nice tutorial.

    HTH
    Mike
    --
    Mike Fischer    Softwareentwicklung, EDV-Beratung
                                    Schulung, Vertrieb
    Note:            I read this list in digest mode!
          Send me a private copy for faster responses.
previous month may 2008 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