WinRT 是否仍然具有相同的旧 UI 线程限制？

发布于 2024-12-05 17:16:47 字数 416 浏览 3 评论 0原文

在 WinForms 中，几乎所有 UI 都是特定于线程的。您必须使用 [STAThread] 才能使通用对话框正常工作，并且您无法（安全）从创建 UI 元素的线程以外的任何线程访问 UI 元素。据我所知，这是因为 Windows 就是这样工作的——窗口句柄是特定于线程的。

在 WPF 中，保留了这些相同的限制，因为最终它仍然构建在相同的 Windows API 之上，仍然是窗口句柄（尽管主要仅适用于顶级窗口）等。事实上，WPF 甚至使事情更多< /em> 限制性的，因为你甚至不能跨线程访问位图之类的东西。

现在 WinRT 出现了，这是一种访问 Windows 的全新方式——一种全新的、干净的状态。我们是否仍然坚持相同的旧线程限制（具体来说：只能从创建 UI 控件的线程中操作 UI 控件），还是他们已经开放了这个限制？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

怎言笑 2024-12-12 17:16:47

我期望它是相同的模型 - 但更更容易使用，至少在C#和VB中，具有新的异步处理，可以让你编写一个看起来同步的当需要等待长时间运行的任务完成然后再继续时，只使用“await”方法。

鉴于强调使异步代码更易于编写，对于 MS 来说，放弃要求同时单线程访问 UI 的效率将是令人惊讶的。

回复收藏 0 原文

烟酒忠诚 2024-12-12 17:16:47

线程模型是相同的。仍然存在单线程和多线程单元 (STA/MTA) 的概念，它必须通过调用 Ro初始化。它的行为在名称、参数和错误返回方面非常类似于 CoInitialize。用户界面线程是单线程的，已在此视频。

回复收藏 0 原文

吻泪 2024-12-12 17:16:47

HTML/CSS UI 模型本质上是单线程的（直到最近 Web Workers 的出现，JS 才支持线程）。 Xaml 也是单线程的（因为开发人员确实很难向多线程 GUI 编写代码）。

回复收藏 0 原文

尘世孤行 2024-12-12 17:16:47

底层线程模型确实存在一些关键差异。当您的应用程序启动时，将创建一个 ASTA（应用程序 STA）来运行您的 UI 代码，如我在演讲中所示。此 ASTA 不允许重入 - 您在拨打电话时不会收到无关的电话。这是与 STA 的显着区别。

您可以创建异步工作项 - 请参阅 Windows.System.Threadpool 命名空间。这些工作项线程自动初始化为 MTA。正如 Larry 提到的，webworkers 是 JS 的等价概念。

您的 UI 组件是线程关联的。请参阅 Windows.UI.Core.CoreDispatcher class 了解如何在 UI 线程上执行代码的信息。您可以查看线程示例以获取一些示例代码，以通过异步操作更新 UI。

回复收藏 0 原文

岁月染过的梦 2024-12-12 17:16:47

事情在一些非常重要的方面有所不同。

虽然底层线程模型确实是相同的，但您的问题通常与逻辑并发如何与 UI 配合使用有关，而开发人员在 Windows 8 中看到的内容将是新的。

正如您提到的大多数对话框以前被阻止。对于 Metro 应用程序，许多 UI 组件不会全部阻止。还记得有关 WinRT 异步的讨论吗？它也适用于 UI 组件。

例如，此 .NET 4 代码不一定会杀死您的硬盘，因为 UI 调用会在 Show 上阻塞（C# 示例）：

bool formatHardDrive = true;
if (MessageBox.Show("Format your harddrive?") == NO)
    formatHardDrive = false;
if (formatHardDrive == true)
    Format();

在 Windows 8 Metro 中，许多 UI 组件（如 Windows.UI.Popups.MessageDialog）是由默认异步，因此 Show 调用将在检索用户输入之前立即（逻辑上）转到下一行代码。

当然，有一个基于等待/承诺设计模式（Javascript 示例）的优雅解决方案：

var md = Windows.UI.Popups.MessageDialog("Hello World!");
md.showAsync().then(function (command) { 
    console.log("pressed: " + command.label); });

要点是，虽然线程模型没有改变，但当大多数人提到 UI 和线程时，他们正在考虑逻辑并发以及如何实现并发。它影响编程模型。

总的来说，我认为异步范式转变是一件积极的事情。它需要一些视角的转变，但它与其他平台在客户端和服务器端的发展方式是一致的。

Things are different in pretty important ways.

While it's true the underlying threading model is the same, your question is generally related to how logical concurrency works with UI, and with respect to this what developers see in Windows 8 will be new.

As you mention most dialogs previously blocked. For Metro apps many UI components do not block all. Remember the talk of WinRT being asynchronous? It applies to UI components also.

For example this .NET 4 code will not necessarily kill your harddrive because the UI call blocks on Show (C# example):

bool formatHardDrive = true;
if (MessageBox.Show("Format your harddrive?") == NO)
    formatHardDrive = false;
if (formatHardDrive == true)
    Format();

With Windows 8 Metro many UI components like Windows.UI.Popups.MessageDialog, are by default Asynchronous so the Show call would immediately (logically) fall through to the next line of code before the user input is retrieved.

Of course there is an elegant solution to this based on the await/promise design patterns (Javascript example):

var md = Windows.UI.Popups.MessageDialog("Hello World!");
md.showAsync().then(function (command) { 
    console.log("pressed: " + command.label); });

The point is that while the threading model doesn't change, when most people mention UI and threading they are thinking about logical concurrency and how it affects the programming model.

Overall I think the asynchronous paradigm shift is a positive thing. It requires a bit of a shift in perspective, but it's consistent with the way other platforms are evolving on both the client and server sides.

回复收藏 0 原文

~没有更多了~