Re: Find no longer working
Re: Find no longer working
- Subject: Re: Find no longer working
- From: j o a r <email@hidden>
- Date: Wed, 24 Sep 2008 11:05:26 -0700
On Sep 24, 2008, at 8:50 AM, Steve Mills wrote:
On Sep 24, 2008, at 10:39:50, j o a r wrote:
Sure, but that's not a supported way of resolving such problems.
The contents of the preference file is private, and subject to
change. You can guess at the keys involved, and their inter-
relationship, but if you guess wrong you might end up breaking Xcode.
Well, it's the official supported way of storing the prefs, because
the new prefs file *will be newly created by Xcode* in the steps I
suggested.
The fact that Xcode automatically creates a new com.apple.Xcode.plist
preference file when the old one is deleted does not make it "the
officially supported way of storing the prefs" for, or a supported
anything - if we are to talk a about this in general terms.
Applications on Mac OS X may store their user preferences and state in
more than one file, and as long as the existence of, and contents of,
these files are a private implementation detail, you can't presume to
know that it's OK to delete or modify any of them.
That said, in practice I would expect it to be OK to delete the
preference files of most Mac OS X applications, including Xcode. From
a robustness and troubleshooting point of view I would even argue that
it's probably incorrect to not handle this gracefully.
What's not supported about that?
Your original suggestion went beyond just deleting the preference file
and allowing Xcode to create a new one. You also suggested that the OP
should copy and paste sections from the new file to his original
preference file.
While most Cocoa applications use NSUserDefaults to manage their
preferences, and while this makes the contents of their preference
files recognizable and technically editable, that's not in any way the
same thing as saying that the editing of these files by outsiders is
generally supported.
That would have been for a "Definitions" search though, right? As
far as I can tell, the OP was referring to a standard "Textual", or
possibly "Regular Expression", search operation.
No. I said Xcode forgot which files in my project were *header
files*, even when doing a regular Textual search. I rarely do a
Definitions search.
That's not quite what you said the first time, but never mind. This
description of your problem is clearer, but it still doesn't quite
make sense to me. I would argue that a Textual search in Xcode, out of
the box, doesn't really care about file types - it searches through
anything that it can recognize as being a text file (That's a kind of
file type too, of course). A failure to recognize text files in your
project is not something that I would have expected to be fixed by a
rebuild of your project. If you see something like this, it would be
great if you could file a bug report.
Thanks,
j o a r
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden