我本质上是一个绘图编辑器，允许您根据现有几何上的关键点定义几何。然后，用户可以添加一些有关他们刚刚添加的内容的信息，例如名称，预期大小等。我用来完成它的API是非常棒的Reversible API，但我希望这个问题可以延伸超出我正在使用的API。
基本上有几个问题我想要澄清一下：
1）如果您支持使用支持Master / Detail方式选择的应用程序的Undo / Redo，那么更改绘图对象的状态是否也会导致它被选中？示例是撤消操作更改了元素的名称，除非选择了元素，否则该更改不会很明显。对于这样的事情，是否考虑过标准行为？
2）当处理某些类型的增量更改（拖动框或使用数字微调器）时，它似乎是一组标准形式，可将一组更改分组为单个用户交互（鼠标滑动或行为释放微调按钮），但在处理MVVM时，我目前只知道属性已更改，而不是更改的来源。是否有一种标准方法可以将这些类型的交互传播到视图模型而不会完全分解模式？
答案 0 :(得分：0)
如果有疑问，最好的方法是查看平台上操作系统控件和其他应用程序的典型行为，以便与用户熟悉的内容保持一致。特别是与最常用的应用程序的一致性。如果您检查其他应用程序如何处理UI问题，您通常可以学到很多东西，特别是在您自己的设计中可能没有考虑过的微妙案例。
1）传统上，撤消倾向于选择更改的项目，以突出显示已更改的内容并将用户的输入焦点移回上一次编辑，以便它们可以继续。这对于像文本这样的内容特别有效，因为如果你撤消/重做你输入的内容，你可能想要继续编辑你刚刚撤消/重做的文本区域。使用主/细节进行制作的主要选择是，是仅选择主对象，还是选择更改的精确细节。
2）您的撤消管理员可以使用某些智能将类似的操作集成到一个撤消步骤中。例如，如果用户在一行中键入多个字符，则可能会注意到这些操作完全相同，并将它们连接到一个撤消步骤中。它是如何做到这取决于你如何存储和处理撤消，但有一个体面的面向对象设计，这应该是一个简单的添加选项（即，如果它们可以集成，请询问撤消记录，以便您可以轻松添加新的类型将来撤消记录）。请注意，在一个步骤中累积太多更改可能会非常令人恼火，因此您可能会发现一个操作= 1步骤的更懒惰的实现实际上实现了比尝试过于聪明的更好的用户体验。只有当你发现最终会有大量重复的撤消序列（比如100个单像素左移动而不是只有一个100像素的跳跃）时，我才会从蛮力开始并添加聚合