 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / September 2005How can i identify the screen a window is on in cocoa?
I need to identify the screen number so I can store that into the prefs file so the window can open up in the proper screen the next time. I'm using obj-c with osx 10.4.2 server. the following the compiler doesn't like. [prefsData appendString: @"</string>\n<key>buttonpalettescreen</key>\n<string>"]; if (buttonpalettevisible) { buttonpalettescreen = [buttonpalette screen]._screenNumber; }; sprintf(tmpstr,"%d",buttonpalettescreen); tmpstring = [NSString stringWithCString: tmpstr]; [prefsData appendString: tmpstring]; [prefsData appendString: @"</string>\n<key>reqswindowscreen</key>\n<string>"]; it appears there's no such animal as _screenNumber by the way, i'm hand parsing the prefs in order to keep the user from having to delete the old prefs when a new update comes in. when the user runs the update there are defaults already set for certain variables and if they are not in the list, they are left alone until a save is done to save a new copy of the prefs. Apple's way of reading prefs for plist files doesn't include anything for adding anything to the prefs and accessing those prefs simply takes way too much cpu time. > I need to identify the screen number so I can store that into the prefs > file so the window can open up in the proper screen the next time. I'm [quoted text clipped - 14 lines] > > it appears there's no such animal as _screenNumber If you read the NSScreen docs, you'll find a method called -deviceDescription. Following the links to the constants section turns up a constant called @"NSScreenNumber". Of course, I have no idea if this number will remain meaningful across restarts or even screen configuration changes, but it's what you asked for. > by the way, i'm hand parsing the prefs in order to keep the user from > having to delete the old prefs when a new update comes in. when the [quoted text clipped - 3 lines] > prefs for plist files doesn't include anything for adding anything to > the prefs and accessing those prefs simply takes way too much cpu time. What are you talking about? NSUserDefaults and CFPreferences can manipulate the plist completely at will. The manipulation you want to make is trivial with them. *Not* using them will in fact cause a lot of issues if you're still trying to use your ~/Library/Preferences/com.yourcompany.yourproduct.plist because a lot of Apple code stores its own settings in that file, and writing to it yourself will completely bypass any synchronization or protection that exists against multiple writes. Also, as of Tiger, user defaults plists are saved in a binary format by default, so there's a whole new dimension of why this approach could go wrong in spectacular ways. As far as speed goes, I have never seen any issues. Unless you're accessing user defaults tens of thousands of times a second, it's hard to see how there could possibly be a speed issue. Even if you are, it's hard to see how your code could be faster than Apple's presumably-optimized plist parser.  SignatureMichael Ash Rogue Amoeba Software > > by the way, i'm hand parsing the prefs in order to keep the user from > > having to delete the old prefs when a new update comes in. when the [quoted text clipped - 6 lines] > What are you talking about? NSUserDefaults and CFPreferences can > manipulate the plist completely at will. From what I've read about the routines, they create a new dictionary that you access. if there's no forkey for an object, it stops right there when you try to access it and emits a concole log entry. yes, i AM checking the prefs almost at the rate of thousands of times per second in fact. hard static variables are much faster than indexed, indirect, calculated location variables. every time a line comes in from the net, I have to check over a hundred prefs to see if it needs some different processing and more testing. in a real-time internet game, it would tend to slow down the machine if i used something like the following: if ([[[myprefs objectAtIndex: j] objectForKey: @"doTestExperienceLevels"] boolValue]) instead of this if (doTestExperienceLevels) my program slows down to a slow crawl and I need to wait sometimes several minutes for text to be displayed. doing it my way, it's displayed immediately. people make the improper mistake of saying to themselves that speed doesn't matter if you have a fast machine with lots of memory. I say keep to the old school and hand tune your programs to get the most speed. Also, static variables are always in physical memory and object variables are in virtual memory which can reside on a hard drive. > Also, static variables are always in physical memory and object variables are > in virtual memory which can reside on a hard drive. The rest of your post didn't make too much sense to me, but this line in particular is completely wrong. Variables are variables. They're either in registers or memory (and they'll go back and forth as needed), and if they're in memory they'll be paged in or out as needed. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > yes, i AM checking the prefs almost at the rate of thousands of times per > second in fact. in that case, you shouldn't be using prefs. that's just for saving persistent state data to disk when the program exits, and reading it back in at startup. you should be copying things you access that frequently into main memory, and accessing them there. >> > by the way, i'm hand parsing the prefs in order to keep the user from >> > having to delete the old prefs when a new update comes in. when the [quoted text clipped - 9 lines] > that you access. if there's no forkey for an object, it stops right > there when you try to access it and emits a concole log entry. Wolfgang Pauli summed this up best. "This isn't right. This isn't even wrong." Quite simply, you aren't making any sense. If you do [[NSUserDefaults standardUserDefaults] objectForKey:...] with a nonexistent key, it will simply return nil. If you do [[NSUserDefaults standardUserDefaults] setObject:... forKey:...] with a nonexistent key, that key is created for you. The design you seem to believe they have would be so useless that you could never do anything with them, and yet the evidence is that almost every singlne GUI app on the Mac uses NSUserDefaults or CFPreferences to store their settings. > yes, i AM checking the prefs almost at the rate of thousands of times > per second in fact. hard static variables are much faster than indexed, > indirect, calculated location variables. So? Are you calling your XML parser a thousand times a second? I doubt you are. You're calling it once, then saving the values in some variables. You can do the *exact same thing* with NSUserDefaults. You are creating and imagining problems that don't actually exist. SignatureMichael Ash Rogue Amoeba Software > I need to identify the screen number so I can store that into the prefs > file so the window can open up in the proper screen the next time. I'm > using obj-c with osx 10.4.2 server. Are you sure you need the screen number to do that? I would think that storing the global coordinates of your windows should be sufficient. I think that would also work in cases such as the following: - single-monitor system, 1600 by 1200 pixels - user moves window to top-right corner - user exits app - user changes config to dual-screen, both 1024 by 768 pixels - user starts app Reinder > I need to identify the screen number so I can store that into the prefs > file so the window can open up in the proper screen the next time. How do you know it's on one screen? (It could be spanning two) It seems to me that storing the coordinates of the window is the way to go. Cocoa makes that easy, with the - [NSWindow setFrameUsingName:] method. It sounds like you're trying to reinvent that. [...] > by the way, i'm hand parsing the prefs in order to keep the user from > having to delete the old prefs when a new update comes in. Wouldn't the user want to save his current preferences for the new version? > when the > user runs the update there are defaults already set for certain > variables and if they are not in the list, they are left alone until a > save is done to save a new copy of the prefs. Apple's way of reading > prefs for plist files doesn't include anything for adding anything to > the prefs Sure it does. To set "default" preferences (preferences that are discarded when the application quits and overridden by any in the preferences file), user -[NSUserDefaults registerDefaults:]. Set the default preferences early in your code, every time the application launches. When you want to add something to the preferences, simply add it to these defaults. > and accessing those prefs simply takes way too much cpu time. You've found that reading the preferences via NSUserDefaults takes more time than parsing the plist with say, NSPropertyListSerialization? Or you're rolling your own parser entirely? -Peter SignaturePull out a splinter to reply. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.