FROM : Quincey Morris
DATE : Thu Feb 28 22:22:25 2008
On Feb 28, 2008, at 12:25, Mike Fischer wrote:
> OK, nobody answered so I did a further test:
...
> Then I relaunched the app, used the IBAction to remove the Auto Save
> Name and quit the app again. The key was still there! So it's a bug
> in AppKit/Cocoa it seems. NSWindow -removeFrameUsingName: does
> nothing at all AFAICT.
Well this time I got interested enough to go read the NSWindow class
reference for removeFrameUsingName. It doesn't say that this method is
supposed to remove the key from the preferences. It *seems* to say
that it leaves the key but removes the frame data (in the sense of
setObject: @"" forKey: windowAutosaveName, it looks like, but I'm
guessing).
You didn't say whether you saw any non-blank saved frame data
associated with the key after using removeFrameUsingName.
DATE : Thu Feb 28 22:22:25 2008
On Feb 28, 2008, at 12:25, Mike Fischer wrote:
> OK, nobody answered so I did a further test:
...
> Then I relaunched the app, used the IBAction to remove the Auto Save
> Name and quit the app again. The key was still there! So it's a bug
> in AppKit/Cocoa it seems. NSWindow -removeFrameUsingName: does
> nothing at all AFAICT.
Well this time I got interested enough to go read the NSWindow class
reference for removeFrameUsingName. It doesn't say that this method is
supposed to remove the key from the preferences. It *seems* to say
that it leaves the key but removes the frame data (in the sense of
setObject: @"" forKey: windowAutosaveName, it looks like, but I'm
guessing).
You didn't say whether you saw any non-blank saved frame data
associated with the key after using removeFrameUsingName.
| Related mails | Author | Date |
|---|---|---|
| Mike Fischer | Feb 26, 21:23 | |
| Mike Fischer | Feb 28, 21:25 | |
| Quincey Morris | Feb 28, 22:22 |






Cocoa mail archive

