C# 控制台应用程序 事件处理

发布于 2024-07-18 09:02:04 字数 561 浏览 5 评论 0原文

大家好。 我正在尝试了解如何在控制台应用程序中处理事件。 我宁愿不使用静默 WinForms(尽管我知道这是一种方法)来做到这一点。 我读过类似的问题及其答复。 请参阅下面的响应文本(链接):

STA线程的基本要求 是它需要运行一条消息 泵。 在 Windows 窗体中,您可以使用 应用程序.运行. 或者你可以写 手动消息泵,使用 user32!GetMessage & 调度消息。 但使用它可能更容易 WinForms 或 WPF 中的一个。

使用“user32 -> GetMessage”和“user32 -> GetMessage”的程序的基本结构是什么? “user32 -> DispatchMessage”?

Hey all. I'm trying to see about handling events in a console application. I would prefer to not use silent WinForms (though I understand that that's one way) to do it. I've read over a similar question and its response. See response text below (link):

The basic requirement of an STA thread
is that it needs to run a message
pump. In Windows Forms, you can use
Application.Run. Or you could write
the message pump by hand, using
user32!GetMessage & DispatchMessage.
But it's probably easier to use the
one in WinForms or WPF.

What the basic structure of a program that uses "user32 -> GetMessage" & "user32 -> DispatchMessage"?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

转瞬即逝 2024-07-25 09:02:04

请参阅 MSDN 中的“使用消息和消息队列”主题(在 Win32 和 COM 开发 > 用户界面 > Windows 用户体验 > Windows 管理 > Windows 用户界面 > 窗口 > 消息和消息队列下;您可能会需要查看同一部分中的其他文章和示例)。 快速总结,省略错误处理并使用 C 语法而不是 C#,原因如下:

RegisterClass(...);
CreateWindow(...);
ShowWindow(...);  // probably not in your case
while (GetMessage(&msg, NULL, 0, 0)) {
  TranslateMessage(&msg);
  DispatchMessage(&msg);
}

正如您从窗口设置样板中看到的,这仍然依赖于“静默窗口”,尽管它是通过 Win32 API 创建和消息泵送的,而不是通过WinForms。 所以你这样做并没有真正获得任何好处。 因此,我觉得将这些东西翻译成 C# 没有多大意义——如果问题的唯一解决方案是一个不可见的窗口,那么您也可以使用不可见的 Windows 窗体以及该平台附带的所有友好包装器。

但是,如果您实际上并未使用 Windows 窗体控件(如链接问题的海报),那么您可以非常愉快地在控制台应用程序中使用 .NET 事件。 对 STA 的限制和对消息泵的需求特定于从 WinForms 和 ActiveX 控件(如 WebBrowser)接收事件(或来自 Win32 HWND 的消息,尽管这不一定需要 STA)。

See the topic "Using Messages and Message Queues" in MSDN (under Win32 and COM Development > User Interface > Windows User Experience > Windows Management > Windows User Interface > Windowing > Messages and Message Queues; you'll probably need to take a look at the other articles and samples in the same section). Quick summary, omitting error handling and using C syntax rather than C# for reasons discussed below:

RegisterClass(...);
CreateWindow(...);
ShowWindow(...);  // probably not in your case
while (GetMessage(&msg, NULL, 0, 0)) {
  TranslateMessage(&msg);
  DispatchMessage(&msg);
}

As you can see from the window setup boilerplate, this still relies on "silent windows," albeit created and message-pumped via the Win32 API rather than through WinForms. So you're not really gaining anything by doing this way. Hence my feeling there's not much point translating this stuff into C# -- if the only solution to your problem is an invisible window, you may as well use an invisible Windows Form and all the friendly wrappers that come with that platform.

However, if you're not actually using a Windows Forms control like the poster of the linked question, then you can quite happily use .NET events in a console application. The restriction to STA and the need for a message pump is specific to receiving events from WinForms and ActiveX controls like the WebBrowser (or messages from Win32 HWNDs, though that doesn't necessarily require STA).

久隐师 2024-07-25 09:02:04

您想处理什么类型的事件? 设置消息泵将允许您处理 Windows API 消息。 但由于这是一个控制台应用程序,我想不出任何有趣的 Windows API 消息。

我们倾向于将“事件”视为与 Windows 消息相关联,因为 Windows 窗体应用程序中的控件使用 EventHandler 委托来响应用户输入,这些委托是为了响应 Windows API 消息而调用的。 但是,您没有理由不能在控制台应用程序中使用委托; 而且你不需要消息泵。 您甚至可以使用 EventHandler 委托,尽管它看起来不太合适,因为它不会响应 Windows API 消息。

当然,您可能会对其他类型的“事件”感兴趣。涉及控制台应用程序的最常见的事件场景是等待来自控制台(stdin)的输入。 如果有多个线程正在使用,则阻塞 WaitHandle 或其他同步对象也很常见。 这两种情况都可以被视为一种事件处理。

如果您创建隐藏窗口(历史悠久的做法),您仍然需要 Windows 消息来响应。 所以问题是:你想回应什么或回应谁?

What kind events do you want to handle? Setting up a message pump will allow you to process Windows API messages. But since this is a console app, I can't think of any Windows API messages that would be of interest.

We tend to think of "Events" as being associated with Windows messages because controls in Windows Forms application respond to user input using EventHandler delegates, which are called in response to Windows API messages. However, there's no reason you can't use delegates in a console app; and you don't need a message pump. You can even use the EventHandler delegate, altough it will seem out of place because it won't be resonding to Windows API messages.

Of course there are other kinds of "events" that you might be interested in. The most common kind of event scenario involving a console app is to wait for input from the console (stdin). It's also common to block on a WaitHandle or other synchronization object if there are multiple threads in use. Both of these cases could be considered a type of event handling.

If you create a hidden window (a time honored practice), you'll still need a Windows message to respond to. So the question is: to what, or to whom, are you trying to respond?

留蓝 2024-07-25 09:02:04

我会使用 Application.Run 方法。 我不认为它会自动创建隐藏窗口,它只是泵送消息,这正是满足 STA 要求所需要的。

使用 PInvoke 编写自己的消息泵不会提供任何优势,并且引用 System.Windows.Forms 也不会造成太大负担,因为它已经存在于您可能遇到的每台计算机上。

I would use the Application.Run method. I don't think it creates a hidden window automatically, it just pumps the messages, which is what you need to satisfy the STA requirement.

Writing your own message pump using PInvoke doesn't offer any advantage and referencing System.Windows.Forms isn't much of a burden because it's already on every machine you may encounter.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文