macos – NSTextView的insertText：*真的*不适合编程修改文本吗？

概述我编写了一个NSTextView子类,它对文本本身进行频繁的编程修改(有点像IDE的代码格式化 – 例如自动插入紧密括号). 我最初的实现使用了NSTextView的insertText：.这实际上看起来完全正常.但是在阅读NSTextView documentation(我有时为了好玩)时,我注意到了Discussion section for insertText: This method i 我编写了一个NSTextVIEw子类,它对文本本身进行频繁的编程修改(有点像IDE的代码格式化 – 例如自动插入紧密括号).

我最初的实现使用了NSTextVIEw的insertText：.这实际上看起来完全正常.但是在阅读NSTextView documentation(我有时为了好玩)时,我注意到了Discussion section for insertText:

This method is the entry point for inserting text typed by the user and is generally not suitable for other purposes. Programmatic modification of the text is best done by operating on the text storage directly.

哦,我的坏,我想.因此,我尽职尽责地将所有insertText调用更改为对底层NSTextStorage的调用(replaceCharactersInRange：withString：,主要是).这似乎工作正常,直到我注意到它完全搞砸了Undo(当然,因为Undo是由NSTextVIEw处理的,而不是NSTextStorage).

所以在我把文件存储器中的buncha撤销代码拖出来之前,我想知道我是不是Punk’d,并且真的是insertText：是不是很糟糕？

是的,所以我的问题是：NSTextVIEw的insertText：调用真的“不适合”编程修改NSTextVIEw的文本,如果是这样,为什么？

解决方法 insertText：是NSResponder的一种方法 – 通常这些方法被认为是响应用户事件的方法.在某种程度上,它们意味着“用户行为”.当文档告诉您直接编辑NSTextStorage时,如果您想以编程方式更改内容,则“编程”一词用于区分用户意图和应用程序 *** 作.如果您希望您的更改可以撤消,就像它们是用户 *** 作一样,那么insertText：似乎可以使用.也就是说,大多数情况下,如果修改不是由用户 *** 作启动的,那么用户将不会认为它是可撤销的 *** 作,并且使其成为可撤销 *** 作的单元将导致混淆.

例如,假设我在文本视图中粘贴了一个单词“foo”,然后您的应用程序将该单词着色为红色(无论出于何种原因).如果我然后选择撤消,我希望我的行动是撤消的,而不是着色.着色不是我的用户意图的一部分.如果我再次打击Cmd-Z以实际取消我的动作,我就会想,“WTF？”

NSUndoManager支持通过beginUndoGrouPing和endUndoGrouPing对事件进行分组.这可以允许用户意图单元(粘贴 *** 作)与应用程序着色分组为单个“撤消单元”.在最简单的情况下,您可能想要尝试的是将NSUndoManager上的groupsByEvent设置为YES,然后找到一种方法来触发应用程序的 *** 作在runLoop的同一行中作为用户 *** 作发生.这将导致NSUndoManager自动对它们进行分组.

除此之外,如果您的程序化修改需要异步或某种形式,您需要自己以某种方式管理这些分组,但这可能是非常重要的实现.

总结

以上是内存溢出为你收集整理的macos – NSTextView的insertText：*真的*不适合编程修改文本吗？全部内容，希望文章能够帮你解决macos – NSTextView的insertText：*真的*不适合编程修改文本吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。