Fixes

[pjrobertson]

Another fixes branch. This one I came across going Catalog Prefs → Quicksilver → internal commands → drawer → contents.

Seems like internal message/commands aren't correctly being created, that's the real problem. But this'll stop a crash if there's ever a nil string again.

[pjrobertson]

The 2nd commit will stop what the 1st commit fixed from ever happening (in this case).

Seems like QSInternalObjects and QSInternalMessages are completely messed up.
Anybody able to explain what they are? @skurfer? @tiennou ? :(

[tiennou]

The only default Internal Object I know is the Trash in the Finder plugin. And it doesn't work correctly too. Internal objects are supposed to be like proxies for things related to the plugin (like Trash), and I think Internal Messages are just simple wrappers around plain Obj-C calls. But yeah, I seem to remember they behave strangely.

[skurfer]

What if identifier is nil too? It's not required (though I think it should be).

[pjrobertson]

Yeah, that actually happened once. I was going to just change it to add a
string if nothing was found. Any recommendations?

@"Unknown" ?

On 4 February 2013 18:35, Rob McBroom notifications@github.com wrote:

What if identifier is nil too? It's not required (though I think it
should be).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1371#issuecomment-13091734.

[skurfer]

Sure.

[skurfer]

Should we also use nameString (instead of [drawObject displayName]) on lines 492 and 493?

[pjrobertson]

nameString and displayName should be treated separately. If we did as you're suggesting, then the string in the UI at this point would be:

nameString ⟷ nameString which is silly of course :)
You're right that we should probably check to make sure [drawObject displayName] != nil