0

100 を超える多くの要素を持つリスト (コンボボックスの標準) を含む ComboBox があります。特定のエントリを見つけて選択したいと考えています。エントリを見つけるために、特定のパターンを各要素の名前と比較します。

パフォーマンス上の理由 (100 を超える要素) から、すべての子のスコープを持つ親で CacheRequest を使用しているため、すべての子を適切かつ非常に迅速に調べて、選択したい子の正しいインデックスを見つけることができます。

ここで問題が発生します。必要な正しいインデックスがあり、キャッシュされた AutomationElement もありますが、CacheRequest で AutomationElementMode.None を指定したため (パフォーマンスに影響があるかどうかをまだテストする必要があります)、そうではないようです。キャッシュされた要素を、将来の呼び出しに使用できる要素 (「ライブ」要素) に変換できます。

NativeWindowHandle経由で変換してみました(AutomationElement.FromWindowHandleという関数があるので)が、ハンドルが0らしいのでこれは仕方ありません。

また、キャッシュされたSelectionPatternをまだ使用しようとはしていません.ComboBoxesはカスタムビルドされることがあるため、すべての場合に機能するかどうかはわかりません.

child-index があり、キャッシュできるすべての値を取得できます。キャッシュされた要素の動作中/ライブの AutomationElement を取得するにはどうすればよいですか?

ありがとうアンドレアス

（Windows 7 64でwin32アプリケーション（自動化ターゲットとして）でC＃を使用しますが、大きな違いはありません）

4

2 に答える 2

0

インデックスに加えて必要な子テキストはありますか? もしそうなら、自動化要素を取得しようとする代わりに、ユーザーが必要な子を選択するために入力しているかのように、子テキストをコンボ ボックスに送信することは可能でしょうか?

フォールバックする IUIAutomationLegacyIAccessiblePattern は常にありますが、それはコア API のみにあり、クライアント (AutomationElement) にはないと思います。

于 2012-06-05T15:14:14.600 に答える
0

実際、AutomationElementMode.None を使用することは、最善のアイデアではないようです。キャッシュ リクエストにかかる時間は、ライブ要素をリクエストするかどうかと、リクエストするプロパティの数によってわずかに影響を受けるだけのようです。(間違っていたら訂正してください - 体系的にテストしたわけではありませんが、最近、キャッシュ リクエストのいくつかのオプションをいじっていると、そのように感じました。)

そもそもリクエストするUI要素の数に大きく影響されるようです。

そのため、最初にライブ リンクをリクエストできました。

そのため、Win32SDK 関数を介したアクセスがより高速になるかどうか疑問に思っています..

于 2012-08-09T08:40:45.687 に答える