有没有办法判断窗口是由用户还是以编程方式调整大小？

Question

简短的问题

我想根据调整大小的真正原因处理SizeChange事件 - （1）由于用户的交互或（2）其他内容。我怎么能分辨出来呢？

背景（简称）

我的窗口里面有datagrid，窗口应该适合它的内容。为此，我必须将所有列宽设置为自动。但是，当用户手动调整窗口大小时，会出现其他“虚拟”列 - 这很难看。所以我的解决方案就是这样 - 将列的宽度设置为Auto，但是一旦用户调整窗口大小，datagrid的最后一列就会切换为“*”。

但要做到这一点，我必须阅读调整大小的原因。

更多细节（编辑1）

目前（！）第一件事是窗口在内部调整大小，因为它已创建。然后再次调整大小，因为从磁盘恢复位置和大小（这是我的代码）。然后再次调整大小，因为数据已加载到datagrid中。调整大小的原因都是用户不进行交互。 因此，所有列的宽度应为= Auto。

第一个用户（！）调整大小时应切换到“星形”模式，即“*”。

更多细节（编辑2）

看来，很多人都没有意识到这个问题。您可以将最后一列的宽度设置为“自动”或“*”（所有其他列的宽度均为“自动”）。但是因为我使用SizeToContent，所以只有Auto才有意义。最初

现在，有几个人认为答案是对每个调整大小事件做出反应。这意味着我会立即将宽度设置为“*”。但是为什么我会在事件中将Width设置为“*”，直到我可以在XAML中直接设置它？

如果有人仍然没有到达这里是预期行为的工作流程（假设我有3列）：

1. 宽度=自动，自动，自动
2. 创建窗口，调整大小
3. 宽度=自动，自动，自动
4. 恢复窗口大小，调整大小
5. 宽度=自动，自动，自动
6. 加载数据，调整大小
7. 宽度=自动，自动，自动
8. 用户手动调整窗口大小，发生调整大小
9. 宽度=自动，自动，“*”（！）

请注意，在每个步骤窗口看起来都很好，用户互动当然是“可选的”。

现在，将它与建议的“解决方案”进行比较。

1. 宽度=自动，自动，自动
2. 创建窗口，调整大小
3. 宽度=自动，自动，“*”（此时，窗口看起来很丑）
4. 恢复窗口大小，调整大小
5. 宽度=自动，自动，“*”
6. 加载数据，调整大小
7. 宽度=自动，自动，“*”
8. 用户手动调整窗口大小，发生调整大小
9. 宽度=自动，自动，“*”（看起来不错，因为它是用户的意愿）

这个“解决方案”100％相当于：

1. 宽度=自动，自动，“*”
2. 创建窗口
3. 窗口大小已恢复
4. 已加载数据
5. 用户手动调整窗口大小

我不再关心调整大小，代码更简单，唯一的缺点是窗口看起来很难看。嗯，事实是，它实际上是一个交易破坏者。

请将您的答案作为答案发布，我已经有2条评论解决了我的问题，我无法标记它们，因为它们是评论。提前谢谢。

Answer 1

一般来说，除了用户之外，唯一调整窗口大小的是你的应用程序。虽然在Windows sdk中可以改变你有句柄的窗口的大小，（比如Cody）我不明白为什么同样的逻辑不适用。

但是，我建议采用不同的方法，可能是多值转换器。

获取原始/所需的列宽（ocw），原始屏幕尺寸（oss）和当前屏幕尺寸（css），然后列宽应为（css x ocw）/ oss，并在将自动更新时窗口大小发生变化。

Answer 2

如果您的窗口最初设置为 SizeToContent="WidthAndHeight"（或 "Width"），那么您可以绑定到此属性并检测它何时更改为 "Manual"，表明用户调整大小操作已开始了。当它切换到 "Manual" 时，您可以激活对任何进一步调整大小作出反应的绑定或事件。 SizeToContent 的值会在用户点击（按下鼠标按钮）窗口边框时立即更新，即在任何实际调整大小发生之前。

从评论来看，很多人没有理解问题的重点。有两种截然不同的情况涉及改变窗口大小：

1. 窗口的内容会发生变化（这可能是由于多种原因），并且窗口大小会更改以适应内容。由于窗口大小的更改是为了适应内容而进行的，因此无需随后更改内容的大小。
2. 用户更改了窗口大小。在这种情况下，新的窗口大小将与内容的大小不匹配，因此应调整内容的大小以填充新的窗口大小。

当然，正如一些评论中所建议的，由于其他限制（可以通过添加具有 ScrollViewer 可见性的 "Auto" 控件来处理），窗口可能无法变得足够大以容纳内容)，但对于许多应用程序来说，窗口变得大于内容要求的唯一情况是用户手动调整窗口大小。

我自己使用这种方法来限制当用户手动调整窗口大小时禁用的窗口可能的自动高度或宽度 - 在我的应用程序中，有些窗口不应自动占据屏幕（但应该以其他方式适应内容），但如果用户想要扩展窗口，他们应该可以自由地这样做。