1

私がやろうとしているのは、ユーザーがタッチ入力を使用して 2 番目のアプリケーションに影響を与えることができるヘルパー アプリケーションを用意することです。キーストロークを 2 番目のアプリケーションに送信することはできましたが、問題はボタンを押したままにすることです。

たとえば、私のアプリケーションでは、ctrl キーを押したままにするボタンを押したままにできるようにしたいと考えています。そして、このボタンを押している間、2 つ目のアプリケーションを操作できるようにしたいと考えています。ユーザーがボタンを離すと、ctrl キーが取り除かれます。ユーザーが2番目のアプリケーションで何かをした場合を除いて、これを機能させることができます.押されていたボタンは押されていません(他のアプリケーションがフォーカスを得たため)。

動作させることができる限り、WPF または Windows フォームに移動する必要があるかどうかは気にしません。Windows 8 または 8.1 のみも使用できます (すべてのクライアントが 8.1 になります)。

どんな助けでも大歓迎です！

以下のコメントに追加したことに注意してください。

2 番目のアプリケーションは、私が作成したものではありません。実際には何でもかまいません。シナリオは、たとえば、押したままにして、outlook でリンクをクリックできる ctrl ボタンを持つアプリケーションです。または、アプリのシフトボタンを押したまま、Photoshop でペンで描画して直線を描きます。キーストロークを送信できますが、「ホールド」タッチコマンドを処理できません。

4

2 に答える 2

1

長くなってしまったので、新しい回答を作成しています。私は調査を行い、何が起こっているのかを知っていると確信しています。しかし、結論を出す前に調べたすべての公式リソースについて言及します。

可能なパッケージ ソリューション

まず第一に、新しいWindows 入力シミュレーターは、箱から出してすぐにすべての問題を解決する可能性があります。以下で説明する Windows API が必要な場合は、まずPInvoke.netをチェックして、実行しようとしている呼び出しに関するドキュメントがあるかどうかを確認してください。

Windows API の方法

開始するのに最適な場所は、MSDNのユーザー インタラクションの記事です。そこには新しい Winu8 Touch API がたくさんありますが、おそらく古いキーボード入力の記事に興味があるでしょう。

アプリケーションのすべてのウィンドウには、関連するメッセージ (ボタンのクリック、ウィンドウが GUI を描画する必要があることを示すメッセージ、ウィンドウを適切に破棄するよう警告するイベントなど) に対応するWindows プロシージャ(別名) が必要です。 Window によって保持されるリソース. このプロシージャは、マウスクリックやキーボードのキーなどの入力デバイスからのメッセージの処理も担当します。WindowsProcWM_QUIT

あなたの場合、ウィンドウにキーボードからのメッセージがないときにメッセージがあると思わせることにもっと興味があります。それがSendInputAPI 呼び出しの目的です。INPUTキーボード、マウス、その他の入力デバイスなど、一連のメッセージをキューに直接挿入できるため、ユーザーが物理的に操作する必要がありません。この簡単な API 呼び出しは、具体的MOUSEINPUTには、、、KEYBDINPUTまたはHARDWAREINPUTメッセージを受け入れます。

キーボードの場合、キーが押されたWM_KEYDOWNとき ( ) とキーが離されたとき ( WM_KEYUP) にメッセージが表示されるため、 のようなホットキーを決定するには、キーの後に受け取った文字CTRL+Cのメッセージを監視する必要があります。そのメッセージ。WM_KEYDOWNCWM_KEYDOWNCTRLWM_KEYUP

入力デバイス メッセージの管理

入力デバイスをシミュレートするには、および/またはメッセージをターゲット ウィンドウSendInputに渡すために使用します。ただし、アプリケーションは複数のウィンドウを持つことができることを忘れないでください。さまざまな Windows を取得するための API 呼び出しがありますが、それを使用する前にそれを見つけるためのコードを作成する必要があります。WM_KEYDOWNWM_KEYUPSendInput

ウィンドウが入力デバイスについて何を信じているかを調べるには、 を使用しますGetAsyncKeyState。入力デバイス関連の API をいじったことがあると、信頼できなくなる可能性があります。

ブロックしたスレッドからの呼び出しをBlockInput除くすべてのメッセージを拒否するウィンドウの呼び出しがあります。SendInputほとんどの場合、できるだけ早く入力を再度有効にするのが正しいことです。ドキュメントによると、ブロッキング スレッドが停止するBlockInputと無効になります。EnableWindowウィンドウが入力フォーカスを受け取るのを防ぐ呼び出しは、同様ですがそれほど厳しくはありません。

Windows 用の API には、フックを登録する機能が含まれています。これにより、メッセージの種類や特定のウィンドウを指定して、ユーザー指定の関数で確認することができます。

于 2014-12-23T09:16:03.663 に答える
0

これを 2 つの異なるアプリケーションで使用する必要がある理由を知りたいのですが、私が考えることができる最善の方法は次のとおりです。

アプリケーションでは、KeyDown、KeyUp、Focus、および Blur (フォーカスを失った) をサブスクライブできる必要があります。これが実際のボタンなのか、それともタッチ入力なのかはわかりませんが、どのような場合でも、ユーザーが ctrl キーを押して「シミュレート」しているときに KeyDown が発生するイベントであり、KeyUp が発生するイベントであると仮定します。ユーザーが ctrl キーが押されていることを「シミュレート」するのをやめたとき。

App1 がフォーカスを取得したときに App2 と状態 (押されているか押されていないか) を通信するように、App1 を設定します。KeyDown または KeyUp が発生するたびに、メッセージを App2 に送信します。

App1 の Blur イベントが発生したら、App2 へのメッセージの送信を停止します。App1 ではボタンが押されなくなりますが、App2 はそれを認識せず、App2 がフォーカスを取り戻してメッセージの送信に戻ることができるまで、ボタンが押されたように動作し続けることができます。

私だったら、App2 に App1 とまったく同じロジックを持たせるので、App2 がフォーカスに入った瞬間にアップ/ダウン状態自体の処理を開始します。ブラー/フォーカス イベントが発生したときに、切り替え時に状態が保持されるように、2 つのアプリケーションに何らかの「ハンドシェイク」を実行させたい場合があります。App2 が Blur イベントを取得すると、状態が App1 に転送され、再び握手されるので、App1 は状態を管理する責任があることを認識します。

これは基本的に「タッグチーム」でアプリを連携させることです。それらは、blur/focus イベントが発生したときに責任を「引き継ぎ」、互いに同期された状態を維持します。Focus が別のアプリで起動する前に、一方のアプリで Blur が起動するかどうかを知ることはできないため、この「シミュレートされたボタン」の状態を伝える同じメカニズムを使用して、アプリが互いに干渉しないように調整する必要があります。

これであなたの問題が完全に解決するわけではないと何かが教えてくれますが、なぜ解決しないのかを聞くことで、誰もが残りの方法を考えることに確実に近づくことができます. ひねりの結末を教えてくださいね。

于 2013-11-07T04:42:41.987 に答える