碳接收线和次要线

Question

想象一个跨平台库，该库必须创建自己的窗口而不依赖Winforms/gtk＃/wpf/monomac/etc（这是 Opentk 如果有人有兴趣）。

以下是交易：Windows和X11功能的Unices支持（或可以使用）多个事件循环，每个线程在一个线程上。这意味着（a）您可以每个线程创建一个窗口，并让它们独立工作，并且（b）您可以在一个线程上运行Winforms（或GTK＃，WPF，...）窗口，并在另一个线程上打开一个Opentk窗口没有干扰。

现在，据我所知，碳不支持这一点。操作系统事件仅交付到“主”事件循环中，并且所有辅助线程都在烟雾上运行（即，接收者始终返回EventloopTimedouterr，找不到任何事件）。 Opentk本身可以遵守此限制，这没问题，但是这对试图将Opentk与其他工具包（例如Monomac）混合的应用程序构成了一个有趣的问题，以提供配置窗口。

两个选项：

• 放弃这个想法，因为疯狂，不允许将Opentk与不同的工具包混合（坏）。
• 选择战斧，然后攻击碳（良好）。

这是您进来的：您能想到任何做出这项工作的方法吗？想象以下情况：

1. 线程＃1（MAIN）运行我们自己选择的一些初始化代码，并产生第二个线程（我们可以自由修改）。
2. 线程＃1（主）打开一个本机窗口并运行RAEL循环（RunApplicationEventloop）。尽管我们仍然可以安装计时器来运行代码，但它取消了我们的直接控制。
3. 线程＃2（次级）打开一个迅速悬挂的Opentk窗口（事件仅交付到线程＃1，而ReceivEnextevent一无所获）。

是否可以从线程＃1过滤事件并根据需要将其传递到线程＃2？ CF可以以某种方式提供帮助吗？ Mac OS X的大师，请帮忙！

（编程语言无关紧要，请使用您熟悉的任何东西。我更喜欢基于碳的解决方案，但是可可症可以正常工作。）

Answer 1

将事件从一个线程传递到另一个线程，应该只是简单地完成事件。棘手的部分是，即使核心碳事件处理是，许多与UI相关的API都不是安全的。任何涉及更新控件和绘图的内容都应在主线程上重新处理。这将需要大量的来回，并且可能不值得尝试使它起作用。

Answer 2

看一眼 Application.AddMessageFilter 和 iMessageFilter 界面。你 可能 能够使用自定义逻辑拦截和转发消息。我过去曾经使用过这种技术（过去非常遥远），但是很久以前，我不记得所有随之而来的警告。我什至不确定消息过滤器会收到所有消息。 .NET可能不会在将它们发送到幕后过滤掉 IMessageFilter, ，但值得一试。