ユーザー コントロールを独自の UI スレッドで実行する方法を見つけようとしています。これは可能ですか?単一のモジュールが原因でモジュール ベースのアプリケーションがクラッシュしないようにしようとしています。
何かご意見は?
残念ながら、すべてのUIコントロールは同じUIスレッドで実行されます。したがって、ハング状態につながる可能性のあるこのスレッドで実行されているコードは、何らかのタイムアウトロジックを使用してコーディングする必要があります。
DateTime startTime = DateTime.Now;
while(DateTime.Now.Subtract(startTime).TotalSeconds < 30)
{
//do something
}
そうしないと、Orlangurが前述したように、すべてのイベントハンドラーコードを別々のスレッドで実行する必要があります。ただし、これらのスレッドを監視して、実行時間が長すぎるかどうかを判断し、シャットダウンする必要があります。そのため、作業が大幅に減り、保守が容易になるため、上記のタイプのロジックを実装することをお勧めします。
それは可能ではありません。ただし、一部の重要なコードでは、別のウィンドウを別のスレッドで実行できます。各ウィンドウには、独自のメッセージ ループがあります。
アップデート:
考えられるもう 1 つの方法は、特別な方法でコントロールを記述することです。すべてのロジックを実行する新しいスレッドを作成することで、コントロール内のすべてのイベントを処理できます。
プログラムのクラッシュの問題ではないと思います。もちろん、例外はキャッチできますが、問題はコントロールのハングにあります。この状況のために、以下に例を示します。
public void Button1_Click(object sender, EventArgs args)
{
while(true) {}
}
このコードがコントロールで実行された場合、例外はスローされませんが、ハングします。これをキャッチして、アプリケーションから制御モジュールを削除する方法を決定しようとしています。
異なるスレッドでコントロールを実行できる必要があります。少しのハッキングとウィンドウのオーバーライドがあれば、実行できるはずです。
別のスレッドで GUI コントロールを作成し、win API SetParent を使用して共通ウィンドウ (メイン GUI スレッド) に移動できると考えています。SetParent を使用して他のウィンドウを「乗っ取る」ことができるため、この方法でコントロールを取得できるはずです。もちろん、フォーカスの問題やその他の問題があるかもしれませんが、実行可能かもしれません.
私はそれを使って、MS Messenger に自分のボタンを配置しました。