4

ActiveX コントロールとして公開される WinForms コントロールに埋め込まれた WPF コントロールがあります。この ActiveX は、サードパーティによって開発された C++ アプリケーションで最終的に使用されます。

ある時点で、ActiveX コントロールの UI がフリーズしますが、C++ アプリケーションの残りの部分は正常に動作します。デバッグを行った後、Application.Current.Dispatcher.Invoke を呼び出すたびに WPF コントロールがブロックされていることに気付きました。ただし、WinForms コントロールは Control.Invoke の呼び出しを正常に処理します。デバッガーを一時停止するたびに、UI スレッドが C++ アプリケーションで何らかの作業を行っていることがわかりますが、ブロックされたり、何かを待ったりしているようには見えません。UI スレッドが突然、不可解にも WPF デリゲートの実行を拒否したかのようです。

C++ アプリケーションが長時間 (数分間) UI スレッドを独占すると、WPF コントロールがこの状態になることがあります。私が最初に行うことは、このような時間のかかるタスクに別のスレッドを使用することですが、既に述べたように、C++ アプリケーションが何を行っているかについて私は責任を負いません。とにかく、これは私の WPF コントロールがそのような方法で動作する理由にはなりません。ただし、この問題を解決する方法がわかりません。任意の助けをいただければ幸いです。

4

2 に答える 2

1

MS Debug Diagnostics Tool - http://support.microsoft.com/kb/2580960を実行することをお勧めします。

これを使用して、COM 相互運用のブロックの問題を特定するために素晴らしい結果を得ることができました。さまざまなモードで実行できますが、.NET 分析で実行すると、ファイナライザー キューなどの問題が強調表示されます。実行するのは少し面倒ですが、得られる情報は優れています。

于 2012-10-05T18:29:05.943 に答える
0

問題Invokeは、マルチスレッド呼び出しのように動作することです。しかし、実際にはそうでInvokeはなく、ブロックしています。一度に 1 つのスレッドしか許可していません。 Invoke実際には、アクションが UI スレッドで実行されることを確認するだけです。これは、メッセージをメッセージ ポンプに強制し、そのように実行することによって行われます。そのアクションは、スレッド呼び出しInvokeがアクションを続行するために実行する必要がある何かでブロックされる可能性があります。例えば：

lock(someLock)
{
    dispatcher.Invoke(SomeMethod);
}

//...

public void SomeMethod()
{
  lock(someLock)
  {
  //... do some work here
  }
}

この例では、ロックを保持している間Invokeは呼び出しがブロックされます。SomeMethodしかし、SomeMethod同じことを望んでいるlockので、 を待ってブロックされていlockます。デッドロックがあります。

代わりに使用することをお勧めしBeginInvokeます。

コードを提供していないため、それがあなたの問題かどうかはわかりません。しかし、それは非常に一般的な問題Invokeです。通常、必要な理由はありませんInvoke。必要があると思われる場合は、通常、問題があることを示しています。

于 2012-09-05T16:23:59.273 に答える