On 01/27/09 02:54, "Christiaan Hofman" <cmhof...@gmail.com> wrote:
>
> On 27 Jan 2009, at 2:05 AM, Maxwell, Adam R wrote:
>
>> On 01/26/09 16:00, "Christiaan Hofman" <cmhof...@gmail.com> wrote:
>>
>>> Yes, but that's all about the window title, not the represented file.
>>> I can only find one vague reference to the represented file, and as
>>> soon as they get specific they forget to mention it.
>>
>> Well, for my original comment I was actually going off of the API
>> docs,
>> which say this:
>>
>> "synchronizeWindowTitleWithDocumentName
>> Synchronizes the displayed window title and the represented filename
>> with
>> the information in the associated document."
>>
>> I think that's pretty clear in referring to "the represented
>> filename."
>> Indeed, if you set a breakpoint on -[NSWindow setRepresentedURL:],
>> it's
>> called from -[NSWindowController
>> synchronizeWindowTitleWithDocumentName].
>>
>
> And it's the one I was referring to. When it gets explicit, it
> completely misses it.
Misses what? It tells you in the summary that it's going to update the
window title and represented filename, then in the description it tells
which document methods are called.
> And the method name is absolutely anti-
> suggestive.
I do agree on that point.
> Moreover, my biggest point: how do I know this is THE way
> it happens, in other words, how do I know that overriding this method
> will not bite me somewhere else?
The AppKit release notes link I posted says that it's called whenever the
document has changed such that window title needs updating. Since that's
dependent on the filename (by default), it must be called whenever the
filename changes as well.
> The point is: the docs don't tell me,
> so it's just an assumption and a guess. We've run into the trap of
> making assumptions from the docs that later proved wrong often enough.
> That's why I think this really is a documentation bug: the docs should
> be explicit about what needs to be done to override the default
> behavior.
I think the docs are pretty explicit on this, but I guess we can read
anything we want into them. I would add that no invented examples are
necessary to describe how the category override + swizzling can break...
>
>> Anyway, it's probably not worth this discussion; it was just a
>> suggestion
>> that I thought might avoid future breakage. (apologies to the users
>> list
>> for dragging this out here)
>
> As a case in point why I don't like making assumptions when the docs
> are not explicit: when you set the representedFilename to nil, you'll
> get a proxy icon for something weird like /path/to/home/path/to/app/~/
> path/to/app.
That didn't match my recollection, so I did a quick test. Passing nil
raises an exception, so if you don't crash, you'd certainly get weird
behavior:
2009-01-27 08:12:40.997 FileView Program[22970:10b] *** Assertion failure in
-[NSWindow setRepresentedFilename:],
/SourceCache/AppKit/AppKit-949.43/AppKit.subproj/NSWindow.m:1985
2009-01-27 08:12:41.001 FileView Program[22970:10b] An uncaught exception
was raised
2009-01-27 08:12:41.003 FileView Program[22970:10b] Invalid parameter not
satisfying: filename != nil
2009-01-27 08:12:41.004 FileView Program[22970:10b] *** Terminating app due
to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid
parameter not satisfying: filename != nil'
So if you want to eliminate the proxy icon, use setRepresentedFilename:@""
or setRepresentedURL:nil (this is inconsistent, but there is no empty URL).
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
