好吧，我对Cocoa和Objective-C以及OOP都很新。
作为背景，我正在开发一个可扩展的编辑器，用于将用户的文档存储在一个包中。这当然需要一些“乐趣”来解决NSFileWrapper的一些问题（即，有点偷偷摸摸的写作和加载过程，以避免对包中的每个单个文档进行NSFileWrappers）。我得到的解决方案是基本上将我的NSDocument子类视为一个shell - 使用它来创建bundle的文件夹，然后将文档的实际内容写入其他方法。
不幸的是，在某些时候我似乎完全搞砸了小狗。我不知道这是怎么发生的，但关闭文档窗口不再释放文档。即使窗口成功关闭，文档对象似乎也不会收到“关闭”消息 - 或任何相关消息。
最终结果是，如果我启动我的应用程序，创建一个新文档，保存它，然后关闭它，并尝试重新打开它，文档窗口永远不会出现。通过一些创造性的子类化和NSLogging，我设法弄清楚文档对象仍然在内存中，并且仍然附加到NSDocumentController实例，因此尝试打开文档时从未超过{{ 1}}“嗯，目前有一个打开”检查。
我确实有一个NSDocumentController's和NSWindowController个实例，但我已经将它们从我的项目中彻底清除了。我已经覆盖了NSDocumentController试图找出问题所在的几乎所有方法。据我所知，我的Interface Builder绑定都是正确的 - 主菜单中的“关闭”附加到第一响应者的NSDocument等，我尝试使用新的未受污染的MainMenu和Document xibs好。
我认为我的包编写代码可能有些奇怪，所以我基本上删除了它并从头开始，但这似乎不起作用。我取出了performClose:方法覆盖，但这也没有帮助。我这里没有任何简单文档应用程序的来源，所以我没有尝试下一个逻辑步骤（用-init和readFromUrl方法替换我的已知工作代码。 / p>
我现在已经遇到了大约16个小时的不间断故障排除问题，不用说，我已经走到了尽头。如果我无法理解，我想我将从头开始尝试使用基于捆绑文档混乱的更多代码和强度的项目。
答案 0 :(得分：1)
很难说没有代码，但我建议发送：
closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:
...到文档控制器，然后查看控制器，因为它被传递给委托以查看其状态如何变化。
如果控制器在发送显式消息时关闭文档，则问题在于绑定到窗口。