Re: Fullscreen on secondary displays
Re: Fullscreen on secondary displays
- Subject: Re: Fullscreen on secondary displays
- From: "Dennis Munsie" <email@hidden>
- Date: Tue, 13 May 2008 23:30:03 -0400
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
<email@hidden> 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 <email@hidden> 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 <email@hidden> 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:email@hidden
> Instant Interactive(tm) http://www.instantinteractive.com
>
>
>
>
>
>
>
>
>
>
> --
> dennis
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
>
--
dennis
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden