Re: Trouble centering window after mode switch (solved)
Re: Trouble centering window after mode switch (solved)
- Subject: Re: Trouble centering window after mode switch (solved)
- From: "Matt R" <email@hidden>
- Date: Tue, 30 Jan 2007 23:50:06 -0800
I'm sorry if I missed that, and I've been doing more research into it and
have taken out the capture display code. Although I might mention one thing
I found, which is that although NSScreen returns the incorrect values after
the switch, the CG functions work fine, so calling CGDisplayPixelsHigh or
CGDisplayPixelsWide return the appropriate values. However the point is moot
because if you then try to use AppKit's positioning methods to reposition
the window with these new correct values, those methods themselves don't
seem to work properly. The results I'm getting are really strange.
Horizontal positioning works, vertical does not. There was a similar thread
to this in the archives but I never found a posted solution.
Now the problem is just finding a non-display-capture alternative to take
over the screen. I've experimented with putting a backdrop window at
shielding level to block out the screen, and then having the smaller main
windows float ontop of that at shielding level also. Now my problem is
trying to prevent users from bringing the backdrop window to the front. I
overrode the custom window's MouseDown event and did [NSApp
preventWindowOrdering], but it doesn't seem to work. Only solution is if I
add [backdropWindow orderBack:nil] which seems a hackish way of doing things
and at certain times causes a flicker to occur as the windows quickly swap.
Just seems like a bad idea. I thought of overriding NSApp's sendEvent method
to completely block out any mouseclick events sent to the backdrop window,
but that seems like overkill. But I can't seem to get [NSApp
preventWindowOrdering] to work and there seems to be no flag or BOOL value
to tell AppKit not to let the window get ordered in front when clicked. I'm
actually kind of stumped at this point :[
anyhow, thank you for the feedback~
On 1/30/07, Ricky Sharp <email@hidden> wrote:
On Jan 30, 2007, at 6:21 PM, John Stiles wrote:
> As I understand it, you can't capture a display and then use the
> window server to draw on it. It will work sometimes on some
> machines, but not all the time on all machines.
> I think a captured display is basically only good for OpenGL, or
> you can blit on it yourself (the OS provides a CG call to get the
> base address and rowbytes of the framebuffer).
> If this is an overgeneralization, I hope someone else on-list can
> provide clarification.
This is correct. I did respond to the original e-mail, but perhaps
it never got through. Basically, yes, you cannot mix AppKit with
captured displays. Things may or may not work.
Avoid the cocoa-dev sample (named 'slideshow' something). There are
Apple examples that show how to use OpenGL or even direct-pixel
access to draw into a captured display.
For details as to the why, search quartz-dev (subject 'Alerts above a
shielding window').
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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