NSDocument 子类没有被 NSWindowController 关闭？

Question

好吧，我对 Cocoa 和 Objective-C 以及一般的 OOP 还很陌生。

作为背景，我正在开发一个可扩展编辑器，它将用户的文档存储在一个包中。这当然需要一些“乐趣”来解决 NSFileWrapper 的一些问题（即，有点偷偷摸摸的编写和加载过程，以避免为捆绑包中的每个文档创建 NSFileWrappers） 。我找到的解决方案本质上是将我的 NSDocument 子类视为一个外壳 - 使用它来为捆绑包创建文件夹，然后将文档的实际内容写入其他方法。

不幸的是，在某些时候，我似乎完全把狗搞砸了。我不知道这是怎么发生的，但是关闭文档窗口不再释放文档。即使窗口成功关闭，文档对象似乎也没有收到“关闭”消息或任何相关消息。

最终结果是，如果我启动应用程序，创建一个新文档，保存它，然后关闭它，并尝试重新打开它，则文档窗口永远不会出现。通过一些创造性的子类化和 NSLogging，我设法发现文档对象仍在内存中，并且仍然附加到 NSDocumentController 实例，因此尝试打开文档从未通过 NSDocumentController 的“嗯，当前已打开”检查。

我确实有一个 NSWindowController 和 NSDocumentController 实例，但我已将它们从我的项目中完全清除。我已经重写了 NSDocument 的几乎所有方法，试图找出问题所在。据我所知，我的 Interface Builder 绑定都是正确的 - 主菜单中的“关闭”附加到第一响应者的 performClose: 等，并且我尝试过使用新鲜的未污染的 MainMenu以及文档 xibs。

我认为我的捆绑编写代码可能有点奇怪，所以我基本上将其全部删除并从头开始，但这似乎不起作用。我拿出了我的 -init 方法覆盖，但这也没有帮助。我这里没有任何简单文档应用程序的源代码，因此我没有尝试下一个逻辑步骤（在 readFromUrl 和 writeToUrl 中替换我的已知工作代码代码>方法）。

我现在已经连续十六个小时不间断地解决这个问题了，不用说，我已经束手无策了。如果我无法弄清楚，我想我会从头开始尝试该项目，使用更多的代码和基于捆绑文档混乱的强度。

Answer 1

没有代码很难说，但我建议发送：

closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:

... 到文档控制器，然后在控制器传递给委托时查看它的状态如何变化。

如果控制器在您发送显式消息时关闭文档，则问题出在与窗口的绑定上。