Re: ScreenSaverView with multiple displays
Re: ScreenSaverView with multiple displays
- Subject: Re: ScreenSaverView with multiple displays
- From: patrick <email@hidden>
- Date: Thu, 27 Jan 2005 19:29:02 -0800
I found the source of my problem. My screen saver splits the screen up
into a grid, and I keep track of where I'm drawing using some
variables (xPos and yPos). This is my first Objective-C/Cocoa project,
and as it turned out, I was not declaring my instance variables
properly. Rather than putting them within the @interface { } block in
my header file, I was just putting them at the top of my class file.
As a result, although I had multiple instances of my ScreenSaverView
(one for each screen), each instance was updating static variables
that were being shared among all instances.
This is actually the second revision of this response. In the first
revision, I was going through everything I had done, and that process
was what got me thinking about that, and then re-reading some
Objective-C documentation within Xcode. So, while I ended up answering
my own question, I do thank everyone for engaging in the discussion
and getting me to think through the problem better than I was.
My screen saver is happily working on both of my displays, and I am
proud to say that all you lucky people with three or more (who would
have thought there were so many of you!) will one day perhaps enjoy my
work on *all* of your displays. :)
Thanks for making this such a great forum,
Patrick
On Wed, 26 Jan 2005 23:04:43 -0800, Steve Christensen <email@hidden> wrote:
> You didn't say what you're trying to do exactly, but it sounds like
> you're moving object(s) around on the screen(s) and need to determine
> which screen the drawing should occur on. I suppose you could use an
> array, but you could also just add the state variables to your custom
> ScreenSaverView class and then iterate over each of the instances as
> necessary. No point in going back to the NSScreen array again since all
> the relevant info (is/is not menu bar screen, the view bounds, etc.) is
> available in your class instances. Just a thought...
>
> steve
>
>
> On Jan 26, 2005, at 8:46 PM, patrick wrote:
>
> > To follow up on the problem of screen savers and multiple screens, I'm
> > wondering if you or someone can help me wrap my head around something:
> >
> > My screen saver is written such that I maintain state information
> > about where I am on the screen for the next iteration of
> > animateOneFrame(). I currently am only drawing to the main screen
> > (using the isMenuBarScreen() method you so kindly helped me with)
> > because I haven't figured out a good way to reliably tell to which
> > monitor I am drawing. Well, the current way with isMenuBarScreen works
> > great for two monitors, but not three or more. While it probably is
> > pretty uncommon for someone to have three or monitors, it bothers me
> > that I can't solve this problem for n number of monitors.
> >
> > I would like to create a struct of some sort to store the state
> > information for each screen to be put into an array, indexed one for
> > each screen. While I can get an array of screens using [NSScreen
> > screens], and I [think] I can get the NSScreen by doing [[self window]
> > screen], should it work if I were to test for the current screen by
> > doing:
> >
> > NSScreen *currentScreen = [[self window] screen];
> > NSArray *screens = [NSScreen screens];
> >
> > int i;
> > int size = [screens size];
> > int currentScreenIndex = -1;
> >
> > for (i = 0; i < size; i++)
> > {
> > if ((NSWindow)[screens objectAtIndex:i] == currentScreen))
> > {
> > currentScreenIndex = i;
> > }
> > }
> >
> > // go on to get my state struct out of a array indexed one-for-one
> > with the [NSScreen screens] array...
> >
> > Patrick
> >
> >
> > On Wed, 29 Dec 2004 16:19:02 -0800, Steve Christensen
> > <email@hidden> wrote:
> >> How about something like this?
> >>
> >> 1. Add a BOOL _isMenuBarDisplay to your screensaver view class.
> >>
> >> 2. Override -initWithFrame: and -initWithFrame:isPreview:.
> >> In each, call the super's method, then
> >> if -isPreview, set _isMenuBarDisplay to true, else check if
> >> frameRect has
> >> the same bounds as the main screen and set _isMenuBarDisplay
> >> accordingly.
> >>
> >> 3. Override -animateOneFrame (and -drawRect: ?), check
> >> _isMenuBarDisplay and
> >> do the appropriate thing.
> >>
> >> This assumes that the view bounds are in global coordinates and are
> >> aligned with individual screens, but this is just a guess since I
> >> haven't yet written a screensaver. :-) If it works, it should get you
> >> away from messy issues like the order in which the views are
> >> initialized.
> >>
> >> As for counting the number of screens, how about:
> >>
> >> unsigned int screenCount = [[NSScreen screens] count];
> >>
> >> And finding the menu bar screen:
> >>
> >> - (BOOL) isMenuBarScreen
> >> {
> >> NSArray* listOfScreens = [NSScreen screens];
> >>
> >> if ((listOfScreens != nil) && ([listOfScreens count] > 0))
> >> return NSEqualRects([self frame], [listOfScreens
> >> objectAtIndex:0]);
> >>
> >> return false;
> >> }
> >>
> >> steve
> >>
> >>
> >> On Dec 29, 2004, at 3:09 PM, patrick wrote:
> >>
> >>> I'm creating a screensaver, and I would like to be able to draw
> >>> something different on displays other than the primary. Through trial
> >>> and error, I've learned that initWithFrame() gets called for each
> >>> display, although it doesn't seem like any useful information is
> >>> passed into initWithFrame() or animateOneFrame() to help the
> >>> developer
> >>> know which display is being used.
> >>>
> >>> By using a counter in my ScreenSaverView and incrementing it each
> >>> time
> >>> initWithFrame() is called (where isPreview is false) I am able to
> >>> count how many displays there are, and it seems like
> >>> animateOneFrame()
> >>> is called in order of display: animateOneFrame() for display 1,
> >>> animateOneFrame() for display 2, and then back to 1 again, etc. So by
> >>> using another counter, I can [sort of] keep track of to which display
> >>> I'm drawing, though it doesn't seem like that great a way of doing
> >>> this, nor does it seem that foolproof.
> >>>
> >>> Does anyone have any suggestions as to a better way of knowing a) how
> >>> many displays there are to begin with, and b) a good way in
> >>> animateOneFrame() to tell which display is being used?
> >>>
> >>> Many thanks,
> >>>
> >>> Patrick
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden