Carbon ReceivenExteventおよびセカンダリスレッド

Question

Winforms/gtk＃/wpf/monomac/etcに依存せずに独自のウィンドウを作成する必要があるクロスプラットフォームライブラリを想像してください（これは opentk 誰かが興味を持っている場合）。

契約は次のとおりです。WindowsとX11対応のUnicesサポート（または、各スレッドの1つ）の複数のイベントループをサポート（または動作させることができます）。これは、（a）スレッドごとに1つのウィンドウを作成して独立して動作させることができることを意味します。干渉なし。

さて、私の - 明らかに限られた - 知識の最高の状態では、カーボンはこれをサポートしていません。 OSイベントは「メイン」イベントループにのみ配信され、すべてのセカンダリスレッドが煙で実行されます（つまり、recevenexteventは常にeventlooptimedouterrを返し、イベントを見つけません）。 Opentk自体はこの制限で動作することができますが、問題はありませんが、これはOpentkと別のツールキット（Monomacなど）を混合して構成ウィンドウを提示しようとするアプリケーションに興味深い問題をもたらします。

2つのオプション：

• アイデアを狂ったように放棄し、Opentkをさまざまなツールキット（悪い）でミキシングすることを許可しません。
• バトル軸を選び、カーボンをハックして提出（良い）にします。

ここに来ましたか：この仕事をする方法を考えてもらえますか？次のシナリオを想像してください。

1. スレッド＃1（メイン）は、独自の選択コードを選択し、2番目のスレッドをスポーンします（これを自由に変更できます）。
2. スレッド＃1（メイン）がネイティブウィンドウを開き、Raelループ（runapplicationeventloop）を実行します。必要に応じて、コードを実行するためにタイマーをインストールすることができますが、直接制御から抜け出すことができます。
3. スレッド＃2（セカンダリ）は、速やかにハングするOpentKウィンドウを開きます（イベントはスレッド＃1にのみ配信され、redivenexteventは何も得られません）。

スレッド＃1からイベントをフィルタリングし、必要に応じてスレッド＃2に配信することは可能ですか？ CFはどういうわけかここで助けることができますか？ Mac OS Xの達人、助けてください！

（プログラミング言語は重要ではなく、よく知っているものを使用します。カーボンベースのソリューションを好みますが、ココアはうまく機能します。）

Answer 1

イベントをあるスレッドから別のスレッドに渡すだけで、イベントを配信するだけで動作するはずです。粘着性の部分は、コアカーボンイベントの取り扱いがあっても、UI関連のAPIの多くはスレッド安全ではないということです。コントロールと図面の更新を伴うものはすべて、おそらくメインスレッドで処理する必要があります。それには多くのやり取りが必要であり、それを機能させる価値がないかもしれません。

Answer 2

を見てみましょう Application.AddMessageFilter そしてその imessagefilter インターフェース。君 そうかもしれない カスタムロジックを使用してメッセージを傍受および転送できるようにします。私は過去（非常に遠い過去）にこの手法を使用しましたが、それはずっと前にあったので、それに伴うすべての警告を覚えていません。メッセージフィルターがすべてのメッセージを受信することさえ確信していません。 .NETは、舞台裏でそれらを送信する前にそれらをフィルタリングしていない可能性があります IMessageFilter, 、しかし、それはショットの価値があります。