Re: Removing the Filename flag in Doc. based Application
There's some advice about this in the "Advice for Overriders of - [NSDocument displayName]" section of the AppKit release notes at http://developer.apple.com/releasenotes/Cocoa/AppKit.html. (Searching for "advice" on that page turns up a couple of other tidbits too.) -- Mark On May 24, 2008, at 1:02 AM, Caleb Strockbine wrote: On May 23, 2008, at 2:51 PM, [EMAIL PROTECTED] wrote: How do I set my document based application to omit the filename reference at the top of each opened document window? Kyle Sluder's explanation is quite informative, but it may also be more complicated than you need. If you really just want to change the name of your document, you can override -[NSDocument displayName] like this: // Adding this method to your document subclass will cause the // title of every document window to be "Foo". - (NSString *)displayName { return @"Foo"; } If you want to also remove the file proxy icon (small icon next to the window title), you'll likely want to create a custom window controller as described by Kyle and implement either the - windowDidLoad: or -awakeFromNib methods such that you get a reference to the icon button and send it a -setHidden: message, like this: // Put the following in your custom window controller where it'll // be executed soon after the window is loaded. NSButton *fileButton = [window standardWindowButton:NSWindowDocumentIconButton]; if (fileButton != nil) { [fileButton setHidden:YES]; } The reason for putting the code above in a custom window controller is that ideally, your document class shouldn't be in the business of defining what the window should look like. The window controller is a better place for that. cheers, Caleb Strockbine ___ 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/markp%40apple.com This email sent to [EMAIL PROTECTED] ___ 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: KVO strangeness under 10.5
You can copy-and-paste to find out what the surprising observers are, as in: (gdb) po 0x19e5a0 -- Mark On Apr 12, 2008, at 2:59 PM, Sean Todd wrote: I have a Cocoa document app that uses bindings. After installing 10.5 and Xcode 3.0, I started seeing console output stating that objects were being deallocated while observers are still registered with them. After some investigation, I found that the objects being deallocated had an extra observer that I never registered (see the final observance instance listed in the -observationInfo output below: (gdb) po [theItem observationInfo] ( Options: Context: 0x0, Property: 0x19e5c0> category, Options: Context: 0x0, Property: 0x1a3c80> Options: Context: 0x0, Property: 0x192920> isDropped, Options: Context: 0x0, Property: 0x1a3cd0> Options: Context: 0x0, Property: 0x192920> grade, Options: Context: 0x18ea60, Property: 0x192920> ) I have no idea what sort of object 0x6503f00 is or how/when it was registered. Looking at the address in memory did not give me any clues. The one interesting bit of info is that the address listed with its Context is the same as the first 4 observers. Continuing on predictably leads to the console output: 2008-04-12 16:18:20.760 MyApp[329:813] An instance 0x1c3d40 of class Assignment is being deallocated while key value observers are still registered with it. Observation info is being leaked, and may even become mistakenly attached to some other object. Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger. Here's the current observation info: ( grade, Options: Context: 0x1c3ce0, Property: 0x192920> ) When I debug this app with Xcode 2.4 on 10.4.x, there are no extra observers and everything works well. I did not see anything addressing this issue in the foundation release notes. Nor have I found any discussion of this problem in the archives. Am I missing something? Do I need to file a bug? Any help would be appreciated. ___ 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/markp%40apple.com This email sent to [EMAIL PROTECTED] ___ 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: KVO strangeness under 10.5
Yikes, that's not good. I'd try running with NSZombieEnable = YES to see if that turns up anything. That should also set NSDeallocateZombies = NO, which might make gdb po work. -- Mark On Apr 12, 2008, at 5:14 PM, Sean Todd wrote: Unfortunately, that doesn't work: grade, Options: Context: 0x1957c0, Property: 0x18edf0> ) (gdb) po 0x6500210 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xc007391b 0xfffeff18 in objc_msgSend_rtp () The program being debugged was signaled while in a function called from GDB. GDB has restored the context to what it was before the call. To change this behavior use "set unwindonsignal off" Evaluation of the expression containing the function (_NSPrintForDebugger) will be abandoned. On Apr 12, 2008, at 5:18 PM, Mark Piccirelli wrote: You can copy-and-paste to find out what the surprising observers are, as in: (gdb) po 0x19e5a0 -- Mark On Apr 12, 2008, at 2:59 PM, Sean Todd wrote: I have a Cocoa document app that uses bindings. After installing 10.5 and Xcode 3.0, I started seeing console output stating that objects were being deallocated while observers are still registered with them. After some investigation, I found that the objects being deallocated had an extra observer that I never registered (see the final observance instance listed in the - observationInfo output below: (gdb) po [theItem observationInfo] ( name, Options: Context: 0x0, Property: 0x19e5c0> category, Options: Context: 0x0, Property: 0x1a3c80> grade, Options: Context: 0x0, Property: 0x192920> isDropped, Options: Context: 0x0, Property: 0x1a3cd0> grade, Options: Context: 0x0, Property: 0x192920> grade, Options: Context: 0x18ea60, Property: 0x192920> ) I have no idea what sort of object 0x6503f00 is or how/when it was registered. Looking at the address in memory did not give me any clues. The one interesting bit of info is that the address listed with its Context is the same as the first 4 observers. Continuing on predictably leads to the console output: 2008-04-12 16:18:20.760 MyApp[329:813] An instance 0x1c3d40 of class Assignment is being deallocated while key value observers are still registered with it. Observation info is being leaked, and may even become mistakenly attached to some other object. Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger. Here's the current observation info: ( grade, Options: Context: 0x1c3ce0, Property: 0x192920> ) When I debug this app with Xcode 2.4 on 10.4.x, there are no extra observers and everything works well. I did not see anything addressing this issue in the foundation release notes. Nor have I found any discussion of this problem in the archives. Am I missing something? Do I need to file a bug? Any help would be appreciated. ___ 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/markp%40apple.com This email sent to [EMAIL PROTECTED] ___ 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: KVO strangeness under 10.5
Sean -- Nothing in KVO's guts registers arrays as observers, and nothing in Cocoa Bindings either as far as I know. For the curious, NSKeyValueObservances are instances of an internal class that gets instantiated and put in the observation info of observed object. (Hugely subject to change; no one should write apps that depend on these details.) In 10.5 they are also used as observers when key paths are being observed. For example, the observance for an object's "category.color" is itself an observer of the "color" of the object's current "category" and forwards notifications to the ultimate observer. When the object's "category" changes it also removes itself as an observer the old value's "color" and adds itself as an observer of the new value before sending the notification to the ultimate observer. So, it makes sense that you're seeing NSKeyValueObservances as observers. One possible cause of what you're seeing might be bad KVO-compliance for "category." If KVO itself doesn't get notified of changes to that value the machinery just described gets pretty confused. There are exceptions thrown for many instances of that mistake but perhaps not all. Anyway, an app that works on 10.4 but not on 10.5 always smells like a backward binary incompatibility in our stuff regardless of where the actual programming mistake is. Please file a bug report with instructions on how to reproduce this problem. Hopefully your app is something you can attach or point us to. Thanks… -- Mark On Apr 13, 2008, at 1:35 PM, Sean Todd wrote: Thanks Mark (and Jim) for the NSZombieEnabled/NSDeallocateZombies reminder. This showed me that the object has indeed been deallocated by the time that breakpoint was reached. Setting an earlier breakpoint I was able to get some more information on this unknown observer: grade, Options: Context: 0x1e00b0, Property: 0x1e1040> ) (gdb) po 0x620c180 ( Options: Context: 0x1e6450, Property: 0x1e2ca0> ) So this object is some array that contains single NSKeyValueObservance. Following the trail of observers shows: (gdb) po 0x182180 category.color, Options: Context: 0x0, Property: 0x62059d0> (gdb) po 0x62005f0 {object: , bindings: content=arrangedObjects, selectionIndexes=selectionIndexes, sortDescriptors=sortDescriptors} Unfortunately, I am still puzzled by how/why this array is set as an observer. Setting a breakpoint with -addObserver:... (as suggested by Chuck Steinman) did not help as gdb could not provide any data via info args when this breakpoint was hit. I am sure that this is due to changes in the KVO system in 10.5 but not sure if this is revealing a bug in that system or uncovering a problem with my use of KVO (perhaps some workaround code to a problem with KVO and bindings pre-10.5). On Apr 12, 2008, at 7:42 PM, Mark Piccirelli wrote: Yikes, that's not good. I'd try running with NSZombieEnable = YES to see if that turns up anything. That should also set NSDeallocateZombies = NO, which might make gdb po work. -- Mark On Apr 12, 2008, at 5:14 PM, Sean Todd wrote: Unfortunately, that doesn't work: grade, Options: Context: 0x1957c0, Property: 0x18edf0> ) (gdb) po 0x6500210 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xc007391b 0xfffeff18 in objc_msgSend_rtp () The program being debugged was signaled while in a function called from GDB. GDB has restored the context to what it was before the call. To change this behavior use "set unwindonsignal off" Evaluation of the expression containing the function (_NSPrintForDebugger) will be abandoned. On Apr 12, 2008, at 5:18 PM, Mark Piccirelli wrote: You can copy-and-paste to find out what the surprising observers are, as in: (gdb) po 0x19e5a0 -- Mark On Apr 12, 2008, at 2:59 PM, Sean Todd wrote: I have a Cocoa document app that uses bindings. After installing 10.5 and Xcode 3.0, I started seeing console output stating that objects were being deallocated while observers are still registered with them. After some investigation, I found that the objects being deallocated had an extra observer that I never registered (see the final observance instance listed in the - observationInfo output below: (gdb) po [theItem observationInfo] ( name, Options: Context: 0x0, Property: 0x19e5c0> category, Options: Context: 0x0, Property: 0x1a3c80> grade, Options: Context: 0x0, Property: 0x192920> isDropped, Options: Context: 0x0, Property: 0x1a3cd0> grade, Options: Context: 0x0, Property: 0x192920> grade, Options: Context: 0x18ea60, Property: 0x192920> ) I have no idea what sort of object 0x6503f00 is
Re: Cannot Remove Observer Error
How are KVO notifications for the Wine class' wineType property being done? KVO is complaining that not enough of them are being sent out. The rule for KVO-compliance in this case is that something must do [wine willChangeValueForKey:@"wineType"] before the value returned by [wine valueForKey:@"wineType"] would change and then something must invoke [wine didChangeValueForKey:@"wineType"] after the value returned by [wine valueForKey:@"wineType"] has changed. Automatic KVO notification does that, but only for changes done with [wine setWineType:aWineType], if there is such a method, or [wine setValue:aWineType forKey:@"wineType"]. If the wine type is stored in an instance variable and something changes the value of that ivar without doing -willChangeValueForKey:/-didChangeValueForKey: you'll get this exception. What changed in your app? One guess is that nothing was observing any Wine's "wineType.name" before but you're now doing something different with Cocoa Bindings that is causing it to be observed. -- Mark On Apr 14, 2008, at 6:12 PM, Thaddeus Cooper wrote: Starting earlier today, I started getting the following error in my software. 2008-04-14 17:59:41.535 WineCellar[4928:10b] Cannot remove an observer for the key path "wineType.name " from , most likely because the value for the key "wineType" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the Wine class. I haven't changed anything significant (well at least I don't think I did) and I definitely have not been messing around with the WineArrayController and/or the Wine classes. I can't figure out how to track this error down -- I've tried a number of things including putting a removeObserver:forKeyPath method in the array controller so I could look at the back trace and I've also put in enter and exit debug messages in a large portion of the code. Still the error seems to come from nowhere and I am stumped as to how I might find what the root cause of the problem is. Does anyone have any suggestions as to how to track down this type of error. Thanks very much. Thaddeus O. Cooper ([EMAIL PROTECTED]) ___ 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/markp%40apple.com This email sent to [EMAIL PROTECTED] ___ 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: AppleScript - occasional crashes on Leopard
Is this a garbage-collected app? If so the crash is a known bug. -- Mark On Apr 22, 2008, at 10:47 AM, Steve Cronin wrote: Folks; I've seen some inconsistent behavior on AppleScript running under Leopard. Here's an example: ... NSString *theScript =@"some valid dynamic script text" NSDictionary *errorDict = [NSDictionary dictionary]; NSAppleScript *appleScriptObject = [[NSAppleScript alloc] initWithSource:theScript]; NSAppleEventDescriptor *eventDescriptor = [appleScriptObject executeAndReturnError: &errorDict]; ... will OCCASIONALLY crash at the NSAppleEventDescriptor specification: #0 0x932c3d5c in getDescDataType #1 0x932c7ab7 in aeCoerceDescInternal #2 0x932cc055 in AECoerceDesc #3 0x1d4a8150 in ComponentCoerceDesc #4 0x1d48cbec in ASCompile #5 0x903bacb8 in CallComponentFunction #6 0x1d487ae2 in AppleScriptComponent #7 0x1d4a3927 in AGenericManager::HandleOSACall #8 0x903755cd in CallComponentDispatch #9 0x953fc513 in OSACompile #10 0x93e6edaf in -[NSAppleScript compileAndReturnError:] #11 0x93e6f096 in -[NSAppleScript(NSPrivate) _executeWithMode:andReturnError:] #12 0x93e6ee51 in -[NSAppleScript executeAndReturnError:] Is there a new/better means in Leopard of accomplishing the execution of dynamic scripts? NO the crash is NOT related to the validity of the script, of this I am absolutely certain! (It only crashes sometimes using the same resulting script!!) Is a dual processor Intel creating a risk here? Is there something better I can do to handle the error? Why should I have to use a @try block here? I thought that was what the executeAndReturnError parameter was for!! But I don't get a chance to examine the errorDict. It will crash only every so often My hunch is that crashes are more likely when machine is under load and memory swapping might be involved. This is running on a 4G MacBook... Any wisdom appreciated! Steve ___ 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/markp%40apple.com This email sent to [EMAIL PROTECTED] ___ 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: AppleScript - occasional crashes on Leopard
Yes. But we intend to fix it in a software update. (And I can't say anything more specific than that. A fix isn't a fix until it's shipped.) -- Mark On Apr 22, 2008, at 1:01 PM, Michael Watson wrote: Mark, So GC + NSAppleScript == avoid for now? -- m-s On 22 Apr, 2008, at 15:53, Mark Piccirelli wrote: Is this a garbage-collected app? If so the crash is a known bug. -- Mark On Apr 22, 2008, at 10:47 AM, Steve Cronin wrote: Folks; I've seen some inconsistent behavior on AppleScript running under Leopard. Here's an example: ... NSString *theScript =@"some valid dynamic script text" NSDictionary *errorDict = [NSDictionary dictionary]; NSAppleScript *appleScriptObject = [[NSAppleScript alloc] initWithSource:theScript]; NSAppleEventDescriptor *eventDescriptor = [appleScriptObject executeAndReturnError: &errorDict]; ... will OCCASIONALLY crash at the NSAppleEventDescriptor specification: #0 0x932c3d5c in getDescDataType #1 0x932c7ab7 in aeCoerceDescInternal #2 0x932cc055 in AECoerceDesc #3 0x1d4a8150 in ComponentCoerceDesc #4 0x1d48cbec in ASCompile #5 0x903bacb8 in CallComponentFunction #6 0x1d487ae2 in AppleScriptComponent #7 0x1d4a3927 in AGenericManager::HandleOSACall #8 0x903755cd in CallComponentDispatch #9 0x953fc513 in OSACompile #10 0x93e6edaf in -[NSAppleScript compileAndReturnError:] #11 0x93e6f096 in -[NSAppleScript(NSPrivate) _executeWithMode:andReturnError:] #12 0x93e6ee51 in -[NSAppleScript executeAndReturnError:] Is there a new/better means in Leopard of accomplishing the execution of dynamic scripts? NO the crash is NOT related to the validity of the script, of this I am absolutely certain! (It only crashes sometimes using the same resulting script!!) Is a dual processor Intel creating a risk here? Is there something better I can do to handle the error? Why should I have to use a @try block here? I thought that was what the executeAndReturnError parameter was for!! But I don't get a chance to examine the errorDict. It will crash only every so often My hunch is that crashes are more likely when machine is under load and memory swapping might be involved. This is running on a 4G MacBook... Any wisdom appreciated! Steve ___ 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/markp%40apple.com This email sent to [EMAIL PROTECTED] ___ 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/mikey-san%40bungie.org This email sent to [EMAIL PROTECTED] ___ 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: Observing with GC
On Feb 26, 2008, at 2:36 PM, Graham wrote: I hesitate to weigh in on an established thread, but I ran into this myself a while back. Isn't part of the purpose of the observer mechanism to allow observees to proceed with their normal activities blissfully unaware of any observers that might be looking at 'em? Yes. As long as an object's class is properly KVO-compliant for a property you, as the author of that class, shouldn't have to care even a little bit about what other objects are observing that property. In which case they won't be keeping track of their observers so have no easy way to tell them to get lost when they are about to disappear. Obviously one can design observees to keep a reference to their observers, but if they need to do that they may as well message them directly with state changes (though KVO as it stands is obviously still more convenient). Right. In general observed objects being destroyed should never try to shrug off their observers and shouldn't have to. There are a few reasonable uses for objects observing themselves, and such objects have to stop observing themselves at some point during their lifecycle, but I've never seen code like [self removeObserver:someObjectOtherThanSelf forKeyPath:aKeyPath] that couldn't be improved upon. I've probably misunderstood something about the design philosophy behind KVO, but as everything is up to the observer to decide when to safely start and stop observing, the possibility of the observee being dealloced out from underneath the observer is a realistic possibility that the current design doesn't handle very nicely. Surely it would be more useful and easier to use if the pattern was for an observer to observe an object until it decides to stop OR UNTIL the observee goes away, whichever occurs first. I don't understand why this second case has to cause an error, as it does now. Perhaps someone better acquainted with the design can explain why it's not done this way? Working around this one issue vastly overcomplicates an observer/observee situation which to my mind makes KVO less useful than it appears to be. Situations in which the observee goes away before the observer are always pretty fishy, and we'll probably never support them. Observers in general should start observing in response to some event and stop observing in response to the inverse event. In between something should be retaining (or strongly referencing, in GC land) the observee, if only so the observer can stop observing it properly and not make KVO itself leak memory. In Leopard Sketch for example an SKTGraphicView starts observing SKTGraphics when its "graphics" property is bound and stops observing them when the property is unbound. In between it also starts observing SKTGraphics when they're added to the bound-to to-many relationship and stops observing them when they're removed. (SKTGraphicView is doing two levels of observation here; see the source code.) Pretty straightforward balancing in both cases. There's no possibility of SKTGraphics being deallocated out from under the observing SKTGraphicView because they should be being retained by the array that is the value of the bound- to to-many relationship, an SKTDocument's "graphics" in the case of Sketch, anyway. In this example, an SKTGraphic being deallocated while something's observing it would be symptomatic of either: • Something that's not really a memory leak but might as well be. An SKTGraphicView could probably get away with not removing itself as an observer of SKTGraphics as they're removed from the bound-to relationship, but the memory that the KVO machinery allocated when the SKTGraphicView was added as an observer to the SKTGraphic would never get deallocated. Even if we (Apple) had just made KVO silently deallocate that memory when the observee was deallocated it would have been a waste of memory in the meantime. A potentially large one in this example, taking into account that many SKTGraphics might be extant but no longer visible in an SKTGraphicView because of stuff like undo support. • Something bad like faulty KVO-compliance for "graphics" in SKTDocument resulting in the SKTGraphicView not being notified that it should stop observing individual SKTGraphics. These sorts of problems are why KVO, in non-GC'ed apps anyway, logs so crabbily about objects being deallocated while observed. In every case where the logging happens there was always a moment before that when the observing should have stopped. In GC land KVO still has the same requirement that every invocation of -addObserver:… is balanced by an invocation of -removeObserver:… This is bad and we know it. The "inverse event" mentioned up above is easy to make happen when every significant observer has a -dealloc method anyway. -[SKTGraphicView dealloc] for example does the unbinding mentioned a