doc based apps automatically load the last document they had open, even if you never saved it.
well, sometimes during development, this is incredibly bad behavior.
I've changed my document class, the old file did not save variables that the new docuent structure expects. So my App crashes on discovering a nil value in a file that should not be opening.
how do I stop it?
You can disable the behavior during development by editing the scheme -> Run -> Options -> Launch application without state restoration.
This ignores the existing state information, so when you later turn off the option, you might still get an error if there's out-of-date information saved. You might need to run it once to get new state information saved. (You might need to temporarily add code to prevent a crash, but you're better off making the restoration code bullet-proof, so that it ignores wrong information instead of crashing. After all, you might change it in the future, and you don't want your updated app crashing on user's systems.)
well, that just avoids the problem.
there is a file somewhere in the computer, that if I remove it, this problem will go away. I need to know where that is.
the changes i made are not questionable. The recurrance of that information in a file is not a possibility. I removed an entire class hierarchy that is unproductive, and will never use again. I have never saved a single file with these objects in them. But the app, retains that information itself, and is not relevant to the app under any circumstances.
I need to know where that file exists. or how to force regenerate it.
There is no reason for me or anyone to be forced to write more robust code to deal with objects that will never be used.
this is an inanity.
>There is no reason
Nothing at all that sounds reasonable in the HIGs? Because Apple falls under 'anyone', and it may be their position (which it frequently helps to go with), is that the user is trained to expect otherwise.
As always, a use case demoing your position should be filed via bug reporter to have it's best chance of being heard, otherwise.
Good luck
Ken
We don't know where the information is saved, since it's private to Apple. Presumably it's in a subfolder of ~/Library, but it's certainly possible that it's elsewhere. There's no direct way to delete it, AFAIK. Normally, it's sufficient to re-run the application and let it terminate normally to get updated restoration information save (which will work only if your app doesn't crash, which is why I suggested that).
I agree it would be better if that run-scheme option deleted the existing information, rather than ignoring it until later, because normal termination does not save new information when you use this option. I believe you can also force an app to ignore existing information if you launch it (outside Xcode, I would presume) with a modifier key held down (Shift or Command, I guess, though I don't remember exactly). You can also disable state restoration globally for your Mac in System Preferences. I don't know if that causes existing information to be deleted, but it might.
>> There is no reason for me or anyone to be forced to write more robust code to deal with objects that will never be used.
Don't be ridiculous, of course there is. If you change (say) your document format, you need to write code that is robust enough to not crash when presented with the old format. Also, there are mutliple reasons why data files might be corrupted outside your control, and coding defensively to avoid a crash doesn't take a lot of effort. You don't necessarily need to interpret the old format, just ignore something that's not in the current correct format.
If you think there ought to be a more direct method of cleansing your Mac of state information during development — not a bad idea, as I've already said — then submit a bug report.
this is not release code. It is still under active development, seeing these kinds of changes, over and over and over again.
you are promoting best practices. Great! Thats not applicable here. The App isn't yet on it's feet. There is not a single reason to support this class, it no longer exists, no user will ever be able to create it, I have never saved a version that contains it. It can safely be ignored as I try to get the app WORKING first, and turned into release-leve code, second.
Sorry, I think I misunderstood your original question.
When you quit with a document open, the system saves state restoration information, including the URL of the document file, plus UI state such as window position and possibly custom information you provide. I thought you were asking about getting rid of this UI state, which is unnecessarily tricky to do.
What I think you actually want is to not re-open the previous document at all. That's not especially difficult, and you can approach it different ways:
— You can use the scheme option during development, and leave it on. The state information is ignored, so your document should not re-open. (But you'll have to do something when you eventually turn the option off, because really old state information will be there.)
— If your app crashes or stops at an exception, you can use the debugger to find the URL of the old document, and delete it manually via the Finder.
— If your document hasn't been saved yet, the normal place for the untitled document file is ~/Library/AutoSave Information. You can look in there for a file or folder with a name like "Unsaved XXX Document", where "XXX" is your app, and move it to the trash.
My advice still stands, though. Regardless of what stage of development you're at, your document opening code should handle an invalid file reasonably gracefully, and early in development there's nothing terrible about a couple of lines of temporary code that deals with the situation. It's up to you if you don't want to do this, but you're gonna have to write code that anyway, sometime.
there you go. Thank you.
of course the code need to be robust... at delivery. we're at formula stage, nothing quite works yet, and i am faced with wave after wave of refactoring to accomodate waves of new approaches to the exact same problems. the boiler plate code of "robustness" adds an exponential amount of work to that process.
I'll get there, I just want to get there sooner rather than later.
