-[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (NSDictionaryController)
One of my testers (and, naturally, none of the test systems I can get my hands on) reports this Console error when performing a certain operation: -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (NSDictionaryController) I think I sorta know what some of it means, but I'm not sure about it all. I think it means NSKeyedUnarchiver had trouble. I think NSKeyedUnarchiver is probably involved in instantiating my nib. The nib involved in the failing operation does, indeed, have an NSDictionaryController. I guess that the fact that the message mentions that (relatively unusual) class means NSKeyedUnarchiver found the nib, and made at least a bit of sense of it all. But, does this mean "I found your NSDictionaryController, but something's wrong with it and I can't decode it"? That is, something busted inside my NSDC? Or, does it mean "I know I'm supposed to be looking for an NSDC, but dang if I can find the bugger"? That is, is there a platform version consideration here? The tester with the troubles runs Tiger; I build on Snow Leopard using SDK 10.4u and deployment target 10.4. I haven't heard from any other Tiger testers, troubled or not, so perhaps this is an SL->Tiger versionitis issue? But not-so-very-long-ago builds, from this same configuration, work for this tester, so that seems ruled out. Is Tiger simply not expected to grok Snow Leopard NSDCs? -==- Jack Repenning jackrepenn...@tigris.org Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (NSDictionaryController)
On Apr 26, 2010, at 4:34 PM, Chris Parker wrote: > if you're setting the deployment target for the nib correctly then IB should > warn you that you're encoding something that 10.4 knows nothing about. Ah, swell ... yet one more spot to configure this. With your help, I found "nib info" in IB, with a "Deployment Target" list, currently set to 10.5, and correcting it to 10.4 produces an error, just as you say. It seems like there ought to be a single central place to set deployment target, is there not? Is the fact that I somehow got mis-matched target settings in Xcode and IB worth a bug report? Bearing in mind that I may not be able to give solid historical info: this project has been under development since OS X 10.2, with multiple tool-chain upgrades, reconfigurations, and the like; I could imagine that some sequences of UI interactions would legitimately reach this confused state, and I certainly couldn't deny doing them. -==- Jack Repenning jackrepenn...@tigris.org Domain Administrator http://www.tigris.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Wrong placement with -[NSWindow initWithContentRect:styleMask:backing:defer:screen:]
Under certain rather complex circumstances (which I'll describe in a moment), the window created by initWithContentRect:styleMask:backing:defer:screen: doesn't appear where it should in my program. But the demo program WhackedTV, running in identical context, and with a cut-and-pasted copy of _my_ initWithContentRect call, does what it should. Apparently, window placement is subject to some condition I'm not expecting. Anybody got a hint? The complex circumstances: placement is only weird if - the desired location is on a secondary screen (one without the menu bar) - and outside a rectangle on that screen that's almost, but not quite, the same size as the primary If I move the desired location a couple pixels into the magic rectangle, the window gets placed as expected; a couple pixels out, and it doesn't. In both programs, my actual window creation code is: NSWindow *hiddenWindow = [[NSWindow alloc] initWithContentRect:NSMakeRect( 928, 1390, 640, 480 ) styleMask: NSTitledWindowMask | NSClosableWindowMask backing:NSBackingStoreNonretained defer:NO screen:screen]; My screen configuration (users with other configurations have reported similar misbehavior): The primary screen is the built-in LCD of a MacBook Pro, running at 1440x900. The secondary screen is an Apple 30" Cinema HD, 2560x2600. According to the "Arrangement" tab of the Displays prefs panel, the primary screen is centered below the secondary. With this arrangement, the visibleFrame of the secondary screen is: - origin.x: -593 - origin.y: 900 - size.width: 2560 - size.height: 1600 As I understand it, the content rectangle is "in screen coordinates," so the requested origin of (928, 1390) is near the horizontal middle of the secondary screen (928 from the left, out of a possible 2560), and fairly near the top (1390 of a possible 1600). And, indeed, that's where WhackedTV puts its window, after I've whacked it to use the window-creation code above. But my app puts its window elsewhere. For this content rectangle, the window comes up at (335, 1458) ([hiddenWindow frame].origin). These dimensions seem to be relative to the origin of the primary screen, or converting to the displayed screen's dimensions: - x: (335 -(-593)) == 928: correct - y: (1458 -(900)) == 558: incorrect, expected 1390 ... and, indeed, the window actually appears "near the horizontal center of the secondary screen," and yet in its lower third, not its upper third. Other positions give larger or smaller errors, and some positions and screen arrangements give errors in the horizontal direction instead of, or in addition to, the vertical error described here. I've also discovered cases where things make even less sense. For example, if I create the window at (928, 887), it appears where I expect it, as nearly as I can tell by eye-balling the coordinates, but the reported [hiddenWindow frame].origin is (928, 55) in absolute terms. There's a band of 20 pixels or so with this completely disconnected behavior; below that, both display and reported frame are as expected. -==- Jack Repenning jackrepenn...@tigris.org Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Wrong placement with -[NSWindow initWithContentRect:styleMask:backing:defer:screen:]
On Feb 6, 2010, at 10:17 PM, Graham Cox wrote: > So you're hard-coding the position of a window based on intimate knowledge of > how your personal system happens to be set up. Presumably you can see why > that might not be a good idea. Oh, sure: that was just to make the example as closed-form as possible. IRL, it's based on a mouse click (the "window" I'm creating is actually a menu). The point I was trying to make was, if I click in some spots, the net effect is that the menu appears just under the mouse, as expected, but if I click in other screen regions, even just a pixel or two away, behavior becomes very odd. In that regard, it's interesting to note that -[NSMenu popUpMenuPositioningItem:atLocation:inView:] behaves perfectly when passed the mouse location directly. That makes it about a hundred times easier than the approach I presently use, which involves several coordinate transformations between local-screen, whole-screen, and single-window coordinates (which, yes, I've checked again and again, but still might be the culprit, they being so convoluted). But this routine is new for 10.6, and I'm trying to support back to 10.4. > Initially placing windows can be a bit of an art, precisely because the exact > size, number and placement of screens in the real world varies enormously. > It's probably best to place any window initially somewhere guaranteed to > exist, which means asking NSScreen for information about the screens, and > placing the window somewhere valid. Then, allow the user to move it somewhere > else, and remember that location. NSWindow takes care of most of that for > you. You could place the window on the secondary screen initially provided > that you find out a) whether it actually exists and b) where it is, and also > provide a fallback case for when a) is false. Since my placement is based on a mouse click, it seems pretty safe to assume the location exists. > I'm not sure why you're seeing what you're seeing, given that in your case > you have special knowledge that suggests the rect is valid. It might be > something to do with detecting the so-called 'standard' and 'user' states of > the window which are based on being 'close to' the screen's available rect, > for some definition of 'close to'. "For some definition of 'close to'" sure sounds like it might be the behavior I'm seeing, but I'm unfamiliar with "the so-called 'standard' and 'user' states." Can you hint me a bit more on that? -==- Jack Repenning jackrepenn...@tigris.org Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Windows on main thread always only sometimes?
I've always been taught that one must only create and run AppKit objects on the main thread. Recently, though, over in objc-language, http://lists.apple.com/archives/Objc-language/2009/Jul/msg2.html it was pointed out that the threading Programming Guide seems to say otherwise: <http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html > says: "You can create a window on a secondary thread. The Application Kit ensures that the data structures associated with a window are deallocated on the main thread to avoid race conditions. There is some possibility that window objects may leak in an application that deals with a lot of windows concurrently. You can create a modal window on a secondary thread. The Application Kit blocks the calling secondary thread while the main thread runs the modal loop." But now I notice this only says you can *create* windows from secondary threads; it doesn't explicitly allow any other action, and it even refers to several automatic insurances that other things happen on the main thread. So what *are* the rules? Is the Thread Safety Summary implicitly strict, "you can create a window, but absolutely nothing else"? Or is there some set of other operations that are permitted from the secondary (and where do I learn those)? (This may already have been discussed on this list ... surely ... I tried to search it out first, but unfortunately every message in the archives matches "thread," due to the navigation links! If so, sorry.) -==- Jack Repenning jackrepenn...@tigris.org Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem with NSDecimalNumber truncating zeros
On Jul 6, 2009, at 1:35 PM, Eric Hermanson wrote: Because of the functionality I am trying to achieve, I need to know the difference between 22 and 22.00, Perhaps -[NSDecimalNumberBehaviors scale] will help? -==- Jack Repenning jackrepenn...@tigris.org Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: cross-development Problems
On May 14, 2008, at 5:59 PM, Celery01 Lin wrote: But When I switch to tiger , MyTest crashs because of "dyld: lazy symbol binding failed: symbol not found: HIShapeCreateWithRect .. Expected in : /system/library/Frameworks/ApplicationService.framework/Versions/A/ ApplicationServices " This is a very weird problem . HIShapeCreateWithRect is inside Carbon.framework. Why the linker trys to resolve it in ApplicationServices? Dose anyone have any suggestion ? dyld searches several places before giving up, at which point it seems to complain only about the last spot it looked. Of course, this is not the spot where the library actually is, since if it had found the library it wouldn't be complaining in the first place! You should ignore the curious location in the error message, and just understand that the desired library was not found. Since you know it's in Carbon.framework, check again your arrangements for making that framework available. -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Password entry dialog
On May 14, 2008, at 5:12 PM, Ron Aldrich wrote: Is there a public API for password entry dialogs? Or should I just roll my own? Perhaps NSSecureTextField would be what you want. -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: How to handle bad certificate error in NSURLDownload?
On May 19, 2008, at 7:40 AM, Jens Alfke wrote: If the issue is that the cert is self-signed, or uses a root authority that isn't trusted by the system, you can use Keychain APIs to add that cert and mark it as trusted. If you do that, NSURLDownload won't complain anymore. Does NSURLDownload end up using OpenSSL to certify? In which case, it would run afoul of the problem that OS X OpenSSL ships with no CA chain. -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Newbie Question re Allocation & Initialization
On May 19, 2008, at 5:18 PM, Brad Gibbs wrote: Is it because numberToPrint is simply pointing to newNumber objects in the array that have already been allocated and initialized? Yes, both newNumber and numberToPrint are merely pointers to some object. These objects are created in the first loop (the alloc/init sequence you noticed), and then stored into the array (the 1addObject: call). In the second loop, they already exist, but we want to grab onto one so we can print it; numberToPrint is set to point to an existing object inside the array (via -objectAtIndex:); since the object already exists, it doesn't need to be alloc'ed (allocated as sufficient blank memory to hold the object) or init'ed (fixed up to actually be such an object). -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: connections and the nib lifecycle
On May 21, 2008, at 11:00 AM, Vijay Malhan wrote: But the problem is still open for discussion. Is there any differences in sequence of events occurring while loading of Nib between Tiger and Leopard platforms? All UI-elements should be initialized by the time call reaches - (void)awakeFromNib. This is ensured to happen on Mac OS X 10.4. Has anyone seen problems in -awakeFromNib? I've noticed this shift to lazy load, but I don't have any problems in my -awakeFromNib, only in other routines of my own. The OP notes a problem in an "other" routine as well, -test:. The dox don't guarantee anything about "other routines," only about -awakeFromNib. The dox also say, of -[NSWindowController window], If the window has not yet been loaded, this method attempts to load the window’s nib file usingloadWindow. Before it loads the window, it invokes windowWillLoad, and if the window controller has a document, it invokes the document's corresponding methodwindowControllerWillLoadNib: (if implemented). After loading the window, this method invokeswindowDidLoad and, if there is a document, the NSDocument methodwindowControllerDidLoadNib: (if implemented). As illustrated in one of the replies in this thread, this means that - window is at least one way to ensure that the window is actually loaded. And that much is the same on Tiger and Leopard (that is, calling [super window] makes it safe to assume the window is loaded and bound). I think there's a change in behavior between Tiger and Leopard, but I think the change is within the undefined territory of the dox (and therefore legal, even if significantly troublesome to us programmers). -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Cocoa Training....
On May 21, 2008, at 11:53 AM, Uli Kusterer wrote: so in the worst case trying the book can get more costly than not trying it :-/ OTOH, I really need one at home and one at work -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: ANN: Step by step introduction to programming with Cocoa
On May 21, 2008, at 5:38 PM, Julius Guzy wrote: Actually the idea was to include a text box at the end of each section where people could post queries regarding that section, e.g. questions about something they did not understand or something which did not quite work as expected etc and which would then cause an email containing that query to be sent to a discussion list, e.g. like the present one, where people's replies would then be included in the section the query came from. This would give the thing the structure of an FAQ. I would keep it all very simple and very basic so it stays managable. If useful it would acquire its own dynamic. Apple does solicit feedback at the bottom of every page, for example http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSCopying_Protocol/Reference/Reference.html#/ /apple_ref/occ/intfm/NSCopying/copyWithZone: (that is, http://tinyurl.com/67r3nm) You must mean something different. Perhaps a public discussion area, sort of like MySQL does? For example, http://dev.mysql.com/doc/refman/4.1/en/select.html -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Still trying to refactor a category as a class
On Jun 13, 2008, at 12:16 PM, Paul Archibald wrote: Given my description of this project, does the two controller solution sound like the best one? Does anyone have any tips on how to re-factor this thing? My first effort kind of blew up in my face. I could not figure out how to do it gradually, so I just did a major cut/copy/paste/change-some-connections/rename-some-stuff kind of thing, and then built and ran it, but I don't know enough about the Cocoa/ObjC/IB/Xcode system to figure out what went wrong. Do you need an *additional* controller? It sounds to me as if you merely need a *different* controller, of a class you create which is a subclass of AppController. -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: interface builder 3 question
On Mar 17, 2008, at 11:44 PM, [EMAIL PROTECTED] wrote: Starting with Interface Builder 3, it is suggested that you don't define your class in IB and have it generate the code. Instead you define it in XCode and IB will stay in sync with those changes. I've been getting a sense of surprise over this, like it's not always working. Can anyone explain to me exactly when this synchronization happens? I feel it happens sometimes, and not others, and rather than be surprised I've gone back to reading the headers manually. Maybe if I understood the timing of this "stay in sync" thing, I wouldn't feel so timorous. -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: interface builder 3 question
On Mar 18, 2008, at 1:06 PM, Jonathan Hess wrote: IB syncs with Xcode whenever a document comes to the foreground and there is an open project for that document. IB only syncs the files as the appear on disk, so if you have unsaved changes in an editor window, IB won't pick them up. IB also only pulls in the headers from the project you are working with. If you're using multiple projects, you may need to read the headers for base classes manually. Ah: "as they appear on disk" was probably what I was missing. But the whole response is a model of clarity and concision; thanks! -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Simple messages problem
On Mar 20, 2008, at 6:32 PM, K. Darcy Otto wrote: Thanks for your help; that change did clear up the warning. I want to make sure I understand your explanation though: All these questions have the same answer. In Objective-C, you can arrange for your messages to go to objects (types) that didn't exist at compile time, so a lot of stuff that seems obvious to the human reader has to be handled more generically. So to express that same thought in the terms of each of your questions: How is [self.sequent objectAtIndex:lineCount-1] of type "id" as opposed to of type "DeductionLine" (since self.sequent is an NSArray of DeductionLine objects)? The return of that method is of type "id" because that's how it's declared in NSArray.h (and equally, in the NSArray documentation you probably read while writing this code). The point at this point is not so much "what will be the type of the object when eventually the program runs," but rather "how much can the compiler assume at compilation time?" And the answer is, pretty much nothing: it knows there'll be some sort of object there, but it doesn't know what (that's what "id" means). Is it that at compilation time, the compiler does not know what sort of object [self.sequent objectAtIndex:lineCount-1] is - but at runtime it turns out to be of type DeductionLine and so that's why everything runs smoothly? Right. But when there is the explicit cast accomplished by (DeductionLine *), the compiler then knows what sort of object [self.sequent objectAtIndex:lineCount-1] is? Something like that. To be finicky: when you put in the cast, the compiler just has to trust you. It doesn't so much "know" the answer at that point, as just take your word for it. If you listen very closely, you'll hear it grumble, under its breath, "OK, then, smarty- pants, let it be on your head!" When you say the compiler doesn't know which "justification" is going to apply - I take it this is because the Justification object has a justification method. How is it confused, since the class name begins with a capital, and the method begins with a miniscule? Thanks again. Not a question of "Justification" vs. "justification" (as you say, the spelling change is quite enough to make that distinction clear), but rather of the "justification" you're thinking of, compared to any other "justification" that anyone might ever define in any class that exists now or at any time in the future, and then sneak into this NSArray. -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Beginner with Cocoa
On Mar 21, 2008, at 12:21 PM, Jeff LaMarche wrote: As for books, I believe that a number of the stalwart Cocoa books, such as Aaron Hillegas' are in the process of being revised for the Leopard changes due out this year some time, but I don't think there is anything yet available that deals with the newest stuff like Objective-C 2.0. That being said, the bulk of the conceptual material is still applicable, so you won't be harmed by using one of the books available now. Hillegas has some words on his website about the differences between his second edition (Tiger) version and the brave new world of Leopard and Objective-C 2.0, so a book plus a web "errata" is pretty close. The main thing you'll have to watch for: Objective-C 2.0 has garbage collection available, like Java and scripting languages you're familiar with, but it's off by default, and earlier Macs don't have it. You'll probably have to learn the old way, "retain and release," which is unique to Objective-C. -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Intercepting retain/release of object
On Mar 21, 2008, at 2:36 PM, Sherm Pendley wrote: In short, the fact that you need a means to track down your -retain and -release calls is indicative of a deeper problem. Examining the retain count will not only fail to solve that problem, but will also obfuscate the issue even further. You'd be far better off asking yourself why your - retains and -releases are so scattered that they're difficult to find and verify in the first place - that's the *real* problem, not whatever arbitrary value you happen to get back from -retainCount. There are really two bits of advice, here, and they're separable. The first is: you'll never make any sense out of retainCount. Might as well just take that one to the bank. Forget retainCount. There's way too much stuff going on that you can't see in the code, you'll never make sense of it all. That's the easy part. The second is: it's best form to handle your retain/release stuff in the simplest, most on-sight verifiable way you possibly can. If you find yourself wondering where an extra or missing retain or release is, then your best conclusion is that your retain/release code is too confusing. Doing it in the accessors is the simplest, most at-a- glance policy, and it covers most use. In fact, Obj-C 2.0 provides you with a handy short hand to do it exactly this way, @property(retain). Breaking in reatain and release (and maybe autorelease) can tell you things that make sense (unlike retainCount), but if you have to do that, your code's too complicated -- you'll have to do it again and again, every time you make changes. Save yourself the trouble. Simplify. -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Intercepting retain/release of object
On Mar 23, 2008, at 9:50 PM, Stuart Malin wrote: For neary all of my code, I have nice, straightforward retain- release pathways. The one that had been giving me trouble is an oddball: I have a factory class that generates an instance. That instance is bounced around handlers of a state machine. All the time I was writing that "do it in the accessors" stuff, I was feeling guilty, because I have one case, quite like yours, where I've had to do something quite notably non-obvious. So I'm eager to hear if anyone has a better solution. What I've done is to make this object responsible for its own life cycle. Its users create it with a "whateverWithStuff" sort of routine, not an alloc or similar (that is, they do not acquire any responsibility for release merely by having a ref to the object; if they hang on to it somehow, then their in-the-accessors retain/release mechanisms still apply). Inside my whateverWithStuff constructor, I retain the object, or allow the implicit retain of the underlying alloc to remain in place, actually. Now, my state machines and threads can toss the object about freely, retaining when they hold it, releasing when they're done, letting their call-stacks fall down through autorelease pools and back to the user input looop, and never worrying about the object disappearing prematurely. At the end, the object itself actually knows (in my case) that it's all used up (because of its windowWillClose), and that routine autoreleases the object, eventually discharging the long-standing release obligation left open back in whateverWithStuff. This stretches the "at-a-glance" retain/release verifiability a bit, but at least the retains and releases are balanced within the class. Some objects explicitly provide a "close" method, or something of the sort, something that their users are responsible to call when they're done with the object, and the final autorelease goes there. -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Beginner with Cocoa
On Mar 24, 2008, at 7:13 AM, Erik Buck wrote: For the record, reference counting for memory management is one of the oldest techniques in software and is not unique to Objective-C or Cocoa. Microsoft Foundation Class CString uses it. COM/Active-X IUnknown uses it. It's essential to using DirectX. It's essential to using embedded controls. Reference counting is well established. Retain/release is not reference counting. The essential point of reference counting is that the language system does it for you, you don't have to think about it at all. Most Java and scripting developers never even learn to think that there are such things as allocation and disposal. The essential point of plain memory management is that you have to think about it constantly, and that the decision actually to free an object (or the research into why it was freed too early or too late) requires knowledge of the state of the entire system. Retain/release is a middle ground: it's not done automatically, you do have to think about it, a bit. But it's possible to pull it off with very limited thought and very simple constraints. But that mental model is, so far as I'm aware, utterly unique in language design, and turns out to be startlingly hard to learn, coming in either from a true ref-counting world (whence you have to learn to think about something you never before knew existed), or from vanilla do-it- yerself memory management (whence you have to learn to trust a simple system for something that has always meant life-or-death, sweaty palms, and late night aggravation). -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Garbage collection - was Beginner with Cocoa
On Mar 25, 2008, at 2:06 PM, Scott Ribe wrote: There's a *very* simple set of rules to follow regarding retain/ release. Yes, but where are they documented? Or, if they're so simple, can you quote them here? Not to sound querulous, but what I know of these very simple rules I picked up from multiple conversations like this on, where the experts seem to say "it's so simple" three to five times for every one time they let leak one of these simple rules. And I've never managed to locate these simple rules in any dox. There's a good, multipage memory-management doc, but that's a bit more than "a *very* simple set of rules." -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Garbage collection - was Beginner with Cocoa
On Mar 25, 2008, at 4:02 PM, Rob Napier wrote: On Tue, Mar 25, 2008 at 6:15 PM, Randall Meadows <[EMAIL PROTECTED] pc.com> wrote: I was thinking < http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#/ /apple_ref/doc/uid/2043 . If people will read nothing but "Practical Memory Management" (the page after the one you linked here, and all of 1500 words long), they will be fine for nearly everything. By the time they need more than that one page, they will probably know what they don't know and be able to figure it out. Both of those are good, thanks, and I agree that "Practical" is even better than the "Ownership" page alone. So, practicing what I preach, and seeing that there isn't an actual URL in the message pointing out the "Practical" page, I hereby provide the URL: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#/ /apple_ref/doc/uid/TP40004447 I'll even go one step further, and provide a "tiny" URL that won't get trashed by mail and archivers: http://tinyurl.com/3awv9a -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Making a window fit its contents?
How can I [someNSTextField setStringValue:someString] (to some value I only learn at run time), and then resize the window that contains it so the string is visible? Or, is there something I can set in Interface Builder that will make this resize happen automatically? I found a sizeToFit in the NSTextField, but not on the surrounding NSWindow or NSView. -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jackrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Making a window fit its contents?
On Mar 31, 2008, at 1:33 AM, Nick Toumpelis wrote: the most effective way to do this is by using Jerry Krinock's NS(Attributed)String+Geometrics categories [1]. Using this, you can determine the height or width of your text and size your window (and NSTextField) appropriately. [1] http://sheepsystems.com/sourceCode That is so unbeLIEVably cool! Works perfectly, only took about five minutes to grok and use. -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jackrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
NSCondition easter-egg hunt
So, what's the scoop on NSCondition? Can someone lead me out of the woods? I can't formulate a coherent question, only a list of bits of documentation which appear to me to contradict each other every way from Sunday. Am I misreading something, or are some few of these wrong? (1) When did NSCondition come to be? Cocoa Fundamentals Guide (as contained in my Leopard Xcode) has a Note: "The NSCondition class was introduced in Mac OS X v10.5. It is not available in earlier versions of the operating system." That would mean I can't use it, since I need to support 10.3.9 (and build on either 10.4 or 10.5). But clicking that word "NSCondition" in that very note leads to the class reference page, which says "Available in Mac OS X v10.0 and later." Eh? [Some of the individual methods are marked 10.5 (the name stuff), but I don't care about 'em.] (2) What are its methods? Thread Programming Guide's "Using the NSCondition Class" section shows examples with the methods -lock, - wait, -signal, and -unlock. The reference manual lists -wait, - waitUntilDate:, -signal, -broadcast, -setName:, and -name (nothing about lock, an odd omission for a semaphore class). None of these mention any special initializers. If I create one: NSCondition *theCondition = [[NSCondition alloc] init]; and then try these various names (for example, [theCondition lock]), I get "method not found" on -broadcast, -wait, -signal, -waitUntilDate:, and -setname: -- everything except -lock, -name, and -unlock. Well, OK, I guess I can formulate a question: how do I synchronize threads? In particular, I have a worker thread (which I spun off long ago, using detachNewThreadSelector:, which discovers that it wants to ask the user for additional info (a password, as it happens). I've registered a call-back for this purpose. When the call-back is called, I need to materialize a dialog for the user input, and as I understand it all GUI stuff needs to happen on the Main Thread, where at the moment I ain't. So I performSelectorOnMainThread:withObject:waitUntilDone:, but I need to block -- not only until the selector finishes (which is what I get from waitUntilDone:), but actually until the user completes the dialog. My original worker thread needs to wait on something, say an NSCondition, until the code supporting the dialog completes (and signals). Tmain: detachNewThreadSelector: and go on about your business Tworker: workee workee, oops, need a password Tworker: performSelectorOnMainThread:withObject:waitUntilDone: Tworker: suspend at this point somehow, but how? <<<<<<<<<< Tmain: post prompt sheet, collect input, close sheet, load answers somewhere shared Tmain: wake up Tworker (and go on about your business) Tworker: wake up, grab the values, and go on about your business -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: want to keep a main window still, not close
On Apr 8, 2008, at 2:31 PM, norio wrote: Would you tell me how to remain the main window? Of course, it must close if user clicks the close box of the window. I'm not certain I understand your whole question, but at least a part of the answer seems to be to define - (BOOL)windowShouldClose:(id)window as return NO; Well, you might have some more complicated determination that merely returning NO, but you get the idea. -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSString stringWithFormat woes
On Apr 8, 2008, at 12:33 PM, Stuart Green wrote: returnString = [NSString stringWithFormat:@"%c-%i-%i-%f", asciiString, firstDouble, secondDouble, thirdDouble]; Which is producing a weird output when used outside of an NSLog. Examining each parameter in the debugger shows exactly what I want, i.e. an ASCII string, a floored double (no decimals), another floored double (no decimals) and a double with a decimal. What do I need to do in order to display them correctly in the returnString? Maybe: returnString = [NSString stringWithFormat:@"%s-%i-%i-%f", asciiString, (int)firstDouble, (int)secondDouble, thirdDouble]; -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Making IB set maximum height but not width?
Is there a way to get Interface Builder to set a maximum height on a window, but not limit the width? I know some work-arounds, such as setting a max on both but making the max width huge, or enforcing it in the code, but is it doable as stated? -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: @dynamic and Programmatic Access to Setters
On Apr 17, 2008, at 8:15 PM, Mike Rossetti wrote: Bindings clearly work so I'm surprised the setTipName isn't synthesized and available for my use. You haven't given us enough info to be sure that tipName works in any sense, prior to your added class method that you mention. So when you say "binding works," I don't know if that means anything more than "no one actually complains." As I understand it, @dynamic is different from @synthesize. While @synthesize actually ... well ... synthesizes the accessor definitions, @dynamic only promises that someone else will; it's sorta like "@class", meaning "pretend you saw the definitions; trust me!" If you don't ever actually provide the definitions, then they never actually exist, and that of course turns ugly once you start trying to use them (or copy them to the clipboard). -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: @dynamic and Programmatic Access to Setters
On Apr 17, 2008, at 8:47 PM, Mike Rossetti wrote: Yes, that's my understanding. But according to the comments I mentioned in my earlier message, Core Data provides the implementations. And clearly it does since I can edit, save and restore the document. I'm just missing the 'magic' that tells me how to set/get a property being managed by Core Data. I don't know anything about those comments. They look suspiciously like the sort of thing that's might be always shown whether they're needed or not, so I was prepared to ignore them ;-) The fact that you've set, saved, and seen again the tip name seems much more interesting. But I think you have no certainty that it was saved in the place you think it was? -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Subclassing
On Apr 18, 2008, at 2:56 PM, K. Darcy Otto wrote: I want to subclass Dependency and override a few things. Can I do this without modifying DeductionLine? Perhaps you want to create a category instead? That allows you to add methods to Dependency without DeductionLine having to know about it. -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: horizontal sizeToFit of NSTextView or NSTextField
On Apr 19, 2008, at 8:31 AM, Manfred Schwind wrote: Now I want to be able to calculate the optimal width of the view so that the entire text is visible. This worked wonders for me: http://www.cocoabuilder.com/archive/message/cocoa/2008/3/31/202752 -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
NSScrollView "autoscroll" while adding data?
I have an NSScrollView to which I add data as the program proceeds. I would like to have it scroll itself automatically, so that the bottom (most recently added) line is always visible, instead of the top. As an example, Xcode's build transcript does what I'm after. I figured this would be called "autoscroll," and searched web, list, and dox for that, but it looks like "autoscroll" specifically refers to what happens while the user is dragging the scroll thumb about -- not what I meant. I can't find any reference to autoscroll-during-add. I confess what I actually want is a bit more complicated than always positioning at the bottom: if the user has moved the thumb about, then the user's chosen position should win; it's only if the thumb is bottomed at the moment I add the next line that I would "autoscroll." I suspect some further subtleties lurk in the neighborhood of the transition out of "not enough data even to fill one screen full." This seems familiar enough, and subtle enough, that surely it must be hiding in the library somewhere? I don't have to reinvent this wheel, do I? Because I went lookin' for the pieces to do that, and came up dry there as well! -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: horizontal sizeToFit of NSTextView or NSTextField
On Apr 20, 2008, at 11:37 AM, Manfred Schwind wrote: Getting the height of a text for a given width is easy and I've done that countless times. Also getting the width of a string (layed out in one line if it has no newlines) is no problem. But I have a different problem. I try to give an easier explanation of my problem: I have a text view that has a height that can hold three lines of text. Now I have one long string (without newlines). When putting this string into the text view, the text is automatically wrapped around. But maybe - for the initial width of the view - it will need four (or more) lines instead of just three. Now I want to calculate the optimal (minimum) width of the text view, to that the string is wrapped around in just three (or less) lines. Either I'm misunderstanding your question, or you're misunderstanding the Geometries code. I think you want -widthForHeight:attributes:, with the height specified for three lines (could just take it from what IB sets for you, or first get a heightForWidth:reallyBig, then triple that). The demo program has a -heightForWidth:attributes: case, just flip it around. This code _does_ work for a multi-line height, and does allow for correct wrapping, font changes in mid fly, multibyte characters, and all the rest. -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Need a native guide through "Cannot remove an observer" woods
I'm getting this message. I think I know what all the words mean, and
I've crawled the KVC and KVO manuals again just to be certain, but I'm
not getting any inspirations on what I'm supposed to do about this
situation. Having seen this message, if I let the program continue
very much longer (_not_ very much longer, actually), I'm likely to get
a BAD_ACCESS crash, which I suppose must be related.
2008-04-25 17:13:11.191 SCPluginUIDaemon[20884:10b]
Exception raised during posting of notification. Ignored.
exception: 'Cannot remove an observer
for the key path "kind" from
because it is not registered as an observer.'
invoked observer method: '*** -[SVNInfoUI windowWillClose:]'
observer: 0x34c380
notification name: 'NSWindowWillCloseNotification'
I guess part of my confusion is the paradox between "cannot remove an
observer" and "it is not registered as an observer." If it's not
registered, who's trying to remove it? And why? And what have I done
to confuse the poor bloke?
The SVNInfoUI is File's Owner to the NIB, and delegate, and this
happens when I close the window (all that sounds right). -[SVNInfoUI
windowWillClose:] does, indeed, do [self setEntry:nil], where entry is
an SVNWCEntry, and -setEntry: looks like this:
- (void) setEntry:(SVNWCEntry *)value
{
[self willChangeValueForKey:@"entry"];
[value retain];
[entry release];
entry = value;
[self didChangeValueForKey:@"entry"];
}
I can see how this could lead to some vigorous unregistering of
observers.
will/didChanging @"entry.kind" in setEntry makes no discernible
difference.
"kind" is a property of SVNWCEntry, and the purpose of the SVNInfoUI
is to display all those SVNWCEntry properties, including "kind", so I
dare say someone's observing the thing, but I can't trace down who, or
where the connection's made, or how to unmake it. Kind is not a
member variable, it's an entry in a dictionary held by SVNWCEntry, so -
[SVNWCEntry kind] is actually
- (NSString *) kind {
return [data valueForKey:@"kind"];
}
which I believe is still KVC-compliant and KVOable, though I'm
mystified as to why it was originally coded that way.
And yes, I've been changing all that code furiously, in particular
because all these objects were formerly leaked and I'm trying to get
them released and cleaned up, and so even though this stuff has been
in our product for a long time, this is probably the first time on any
stage that an SVNInfoUI and its associated SVNWCEntry have ever
actually been dealloc'ed, so nearly any surprising thing might be true
of them.
-==-
Jack Repenning
[EMAIL PROTECTED]
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Need a native guide through "Cannot remove an observer" woods
On Apr 25, 2008, at 7:42 PM, Keary Suska wrote:
on 4/25/08 6:49 PM, [EMAIL PROTECTED] purportedly said:
- (void) setEntry:(SVNWCEntry *)value
{
[self willChangeValueForKey:@"entry"];
[value retain];
[entry release];
entry = value;
[self didChangeValueForKey:@"entry"];
}
If you haven't turned off automatic KVO notifications, the above is
very
wrong, and could be the source of your problem.
Thanks. I think your hint worked. That is, I'm not sure what you were
suggesting, but I took a guess, and it seems to have worked. But I
still don't quite grasp what's going on, so I'm begging for a touch of
background?
What I did: remove the will/didChange stuff.
What happened: I no longer get the unable-to-remove-observer warning,
nor the subsequent BAD_ACCESS crash.
Don't willChange and didChange merely notify and observers there may
be that change is happening? Why would redundant notification be a
problem (other than perhaps performance, or possibly some obscure
double-entry kind of response to the change, like adding up each value
placed into an integer field)?
-==-
Jack Repenning
[EMAIL PROTECTED]
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Something like "validation," only not?
My app presents a table of values to the user. The table has two columns, "name" and "value," which are managed by an NSDictionaryController bound to an NSDictionary. I have enabled my users to edit these values (their changes propagate back to the underlying NSDictionary, and I can then do whatever it is I planned to do with the new values). But I would like to add some user feedback (changed values are bold, or red, or flashing thirteen times a second, something like that), as well as enabling/disabling a "save" button I've provided, depending on whether any of the values have been changed. I think this might be a case for "Validation." Only, my reading on validation only takes it as far as enabling/disabling controls (the Save-button case); it does not seem to extend to other kinds of UI actions, such as changing the display font. Is the "change the appearance" case buried somewhere in Validation, and where should I dig that I apparently missed? Or, if this is not "Validation," what is it and where do I read more? -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Cannot remove an observer ... because it is not registered as an observer.
On May 4, 2008, at 10:07 PM, Jens Alfke wrote: The usual cause of this is that you have a property that isn't KVO- compliant. Something accesses your 'foo' property and registers as an observer of that property, and also as an observer of the object that's the property's current value; you change the value of 'foo' without letting anyone know; the observer then later decides to stop observing, gets your 'foo' property, and removes itself as an observer of that object. But it's no longer the same object that it registered as an observer for... I also recently had a case of this message caused because my property, which was otherwise perfectly KVO-compliant, *also* had "willChange / didChange" stuff, so it was being excessively change-notified. Removing those (because the automatic notifications were sufficient) made it all happy.> -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Passing argument with different width due to prototype: warning
On May 13, 2008, at 6:10 PM, R.L. Grigg wrote: NSSocketPort *socketPort=[[NSSocketPort alloc] initWithTCPPort:1234]; . . . warning: passing argument 1 of 'initWithTCPPort:' with different width due to prototype I checked the NSPort header file for the NSSocketPort method prototype, /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ Foundation.framework/Versions/C/Headers/NSPort.h: - (id)initWithTCPPort:(unsigned short)port; What am I doing wrong? Have you tried this? NSSocketPort *socketPort=[[NSSocketPort alloc] initWithTCPPort: (unsigned short)1234]; -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Development workflows for signed code?
I'm just dipping my toes into the world of signed code. After spending some time with the Code Signing guide, I'm still not clear on how this affects the work flows around my product (SCPlugin, http://scplugin.tigris.org , which adds Subversion capabilities to Finder), partly because of some peculiarities it has: - It's a Finder plugin, not an app - It's open-source, so the developers don't work for the same company, and I need to make it very easy for developers to start - Many devs work on Tiger, where codesign is not available (release happens from Leopard) I think I know how to generate "identities" and sign the plugin bundle. I see claims that self-signed certs are good enough for developers. What I'm not clear on, primarily, is what are the effects of mixing up copies of the same bundle signed with different identities? Will there be pop-ups that mention the certifying identity, for instance? Will there be difficulties installing one version over another (where the signing identity changes)? My experiments so far seem to show that none of those things happens. In fact, even if I modify one of the files, so that "codesign -v" no longer likes the bundle, it still seems to work. Is "codesign -v" the only (Leopard) thing that cares about all this? -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Development workflows for signed code?
On Dec 9, 2008, at 6:36 AM, Chris Suter wrote: By the way, you should post code signing questions to the apple-cdsa list rather than the Cocoa list as you'll get a better response there. Thanks for that. I did look for a more focused list, but I guess that acronym didn't catch my eye. -==- Jack Repenning [EMAIL PROTECTED] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
controllers, delegates, retain, release ...
I have some code inherited from someone else (so I have no answers to
why it's the way it presently is) that's handling retention in a way I
find confusing, and think is not in accordance with the spirit of the
law. But I can't quite figure out how to do it "right". Is there a
pattern I should be following, and at what point am I diverging from it?
The quandary involves two classes, call them "Controller" and "UI".
Controller is created when the NIB is loaded, and lives effectively
forever. From time to time, Controller needs to create an instance of
UI, to manage some user interaction (take some parameters, do some
work, show status, you know the drill). It's possible for there to be
several UI objects alive and on-screen at once. My problem concerns
the retention of the UI objects.
In the current structure, Controller performs
{
UI *ui = [[UI alloc] initWithContext: context];
[ui run: @selector(doSomething) title: @"Title"];
}
That is: the UI object is alloc'ed (creating a release obligation),
but is not (auto)released here, nor is any reference to it saved
anywhere so it may be (auto)released later. Controller has nothing to
do with releasing this object, which is the bit that sticks in my craw.
Rather, over in UI we have:
-(void)windowWillClose:(NSNotification *)aNotification
{
[self autorelease];
}
That is: after UI has done all it needs to do, and the user clicks the
final button (connected here), it autoreleases itself, completes, and
the pool finishes it off.
This is all working; nothing leaks, nothing is prematurely
dealloc'ed. But having the alloc and (auto)release in separate
classes seems unsound.
I found an earlier thread in this list,
http://lists.apple.com/archives/cocoa-dev/2002/Jul/msg01001.html
which is darned close to my situation (almost, but not quite, totally
like). This thread solves its very similar problem by having
Controller keep a ref to UI, and release it during Controller's
dealloc. I can't quite see how to handle that in my case. A minor
problem is that I may have an unpredictable number of these UI objects
about, so I'd need an NSMutableArray of them or something, not just a
scalar field. But a bigger problem is that Controller isn't
dealloc'ed until the end of the program, which is far too late: it's a
long-lived, server-like program, I'd be accumulating these UI objects
forever.
- Is my eternal, shared Controller bogus, and I should be finding
some way to create multiple Controllers, and destroy them more often?
- Is there some way to get the windowWillClose event passed back to
Controller, rather than to UI, so the autorelease can happen there?
- Is there some other rotation I should consider?
- Or, is this actually The Way It's Done?
The code, if you're curious, may be found via Subversion at http://scplugin.tigris.org/svn/scplugin/trunk/
. The players are actually:
"Controller": SCUIDaemonController+SubversionSupport
"UI": several, but most illustratively NewGenericUI
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: controllers, delegates, retain, release ...
On Feb 22, 2008, at 1:13 PM, Keith Duncan wrote: This would be a problem should the code base ever be compiled with GC support. Interesting point, that retain/release supports a lifecycle model (free-floating, self-managed object) that can't be supported by GC -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: controllers, delegates, retain, release ...
Interesting discussion, thanks. Not surprising, I suppose, if there's some split on a "matter of taste" like whether it's legitimate to have an object manage its own lifecycle ([self autorelease]). FWIW, I chose Quincey's solution, [[alloc]init]autorelease] in Controller, and [[super init]retain] plus [self autorelease] in UI. This keeps the number of lines you have to scan to verify retain/release balance to a minimum, anyway. GC compatibility can wait until I have more time to think about the new GC. Since I'm still supporting Panther clients, this may be a long time -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
disowning a bundle?
In my -(id)initWithContext:, I [NSBundle loadNibNamed:@"SCCommitUI" owner:self]. Among other things, this retains me a few times inside the bundle. When I'm done, I want "self" to go away, but it does not: the retain count never goest to zero (my dealloc is never called), because of those retains inside the bundle. How do I make the bundle / nib let me go? Doubtless this is also a clue, though not for noobs like me: if I add an extra autorelease, I get dealloc'ed, but I also get an error, "An instance of class MyClass is being deallocated while key value observers are still registered with it." And often, following this, I get a BAD_ACCESS crash, which I assume is happening 'cause one of those observers tries to observe the now-deallocated object. So I want to deregister them, too (or perhaps "they" are the bundle dictionary above). -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: disowning a bundle?
On Feb 23, 2008, at 6:44 PM, Hamish Allan wrote: On Sun, Feb 24, 2008 at 2:25 AM, Jack Repenning <[EMAIL PROTECTED]> wrote: In my -(id)initWithContext:, I [NSBundle loadNibNamed:@"SCCommitUI" owner:self]. Among other things, this retains me a few times inside the bundle. When I'm done, I want "self" to go away, but it does not: the retain count never goest to zero (my dealloc is never called), because of those retains inside the bundle. How do I make the bundle / nib let me go? A similar question came up recently on the list, and the short answer is: if the bundle wants to retain you, let it do so; if you want the resources you release in your dealloc method gone sooner, create an API for that (c.f. [NSFileHandle closeFile]). I must not be fully understanding this solution, and I can't seem to locate the thread. Can you hint me some keywords, or an URL or something? I understand the part about providing a closeMe method, to do all the releasing new done in my unused -dealloc. But there's the "me" itself to release or leak, and there see still to be references to it that seem still to be used in some way or other (to judge from my BADACCESS crashes if I over-release myself). And I do want to create new instances of "me", bound once again to the same nib (or an identical one), to post the window yet again. Are you saying I should just let that stuff leak? -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: disowning a bundle?
On Feb 24, 2008, at 5:42 PM, Ricky Sharp wrote: I do this myself since I also load/unload the same nibs throughout the lifetime of my app. How do I unload a nib? I see NSBundle's several loadNibBlahBlah methods, but no unloadNibBlahBlah's. Sorry if I sound querulous, but I keep getting these answers that don't seem to match the reality of the code I'm looking at. Should it be loadNibbing from the (permanent, singleton) Controller rather than the (ephemeral, multiple) View? -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 mobile: +1 408.835.8090 raindance: +1 877.326.2337, x844.7461 aim: jackrepenning skype: jrepenning ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
