none
SendInputが通らない場合がある? RRS feed

  • 質問

  • こんにちは。
    マウスポインターの位置を設定するプログラムを作成しています。

    SendInput関数を使用してマウスポインターの位置が動くことはソースは出来ました。しかし、何故かコマンドプロンプトのウィンドウを選択されているときにはマウスのポインターは動かないのです。これはなぜでしょうか?

    SendInputやGetSystemMetrics関数等、コマンドプロンプトスクリーンが選択されていたら不都合が起きるようには思えないのですが・・・

    私が製作しているアプリケーションの性質上、コマンドプロンプトのウィンドウでも必ず動かなければいけませんよ、というわけではないのですが、この事象をこのまま放置しておくのもどうかと思いますし、また全く別のアプリケーションをWINDOWを選択したときにも同じ事象が起きないとも限らないので、質問させて頂きます。ご教授いただけると幸いです。

    ちなみに当方、OSはOWINDOWS VISTA, 環境はVisual Studio 2008です。

    ~~~~~~~~~~~~~~~~~~~
    下記参考:

    #define MOUSE_EVENT_X(x)    1 + ((DWORD)x * WORD(-1) / ::GetSystemMetrics(SM_CXSCREEN))
    #define MOUSE_EVENT_Y(y)    1 + ((DWORD)y * WORD(-1) / ::GetSystemMetrics(SM_CYSCREEN))
    //x&y are in pixel of the screen
    void SetMousePt(int x,int y){
      INPUT input[2];
      input[0].type = INPUT_MOUSE;
      input[0].mi.dwFlags = MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE;
      input[0].mi.dwExtraInfo = 0;
      input[0].mi.dx = MOUSE_EVENT_X(x);
      input[0].mi.dy = MOUSE_EVENT_Y(y);
      input[0].mi.mouseData = 0;
      input[0].mi.time = 0;
      input[1].type = INPUT_MOUSE;
      input[1].mi.dwFlags = MOUSEEVENTF_ABSOLUTE;
      input[1].mi.dwExtraInfo = 0;
      input[1].mi.dx = MOUSE_EVENT_X(x);
      input[1].mi.dy = MOUSE_EVENT_Y(y);
      input[1].mi.mouseData = 0;
      input[1].mi.time = 0;
      ::SendInput(2, input, sizeof(INPUT));
     }

    参考サイト:
    http://orangeknowledge.jpn.org/tips/sdk002.html
    2010年2月13日 4:40

回答

  • たしか、Vistaにおいては、コマンドプロンプトのウインドウは不思議に高い特権で動いているとみなされるので、
    セキュリティのからみで(ドラッグドロップが効かなくなったのと同じように)SendInputでの介入が弾かれるのではないかとおもわれます。
    またほかにも、昇格されたアプリの出すウインドウには触れない現象が発生するのでは、と思います。いずれも確信はありませんが。

    jzkey
    • 回答としてマーク yneedshelp 2010年2月13日 11:29
    2010年2月13日 11:04
  • >MS-DOSプロンプトのウィンドウ

    NT 系 OS に MS-DOS プロンプトはありません。
    正しい呼称は「コマンドプロンプト」です。(キャプションにもそう書いてあるはず)

    >>Vistaにおいては、コマンドプロンプトのウインドウは不思議に高い特権
    >なるほど、プライオリティということでしょうか…であれば納得です。ありがとうございました。

    不思議な現象ではありません。
    Vista 以降の OS の仕様です。

    Vista から、UAC と呼ばれる仕組みが導入されました。
    UAC が有効な場合、管理者権限を持ったアカウントでログオンしていても、プロセスを「昇格」をしないと、システムに致命的なダメージをもたらすような操作は実行することができなく(=失敗する)ようになっています。

    同じユーザ権限で実行されているプロセスであっても、昇格済みのプロセスと未昇格のプロセスの間では、ウィンドウズメッセージのやりとりができないなど、様々な制約が課せられています。
    本件もこれに該当するものと思われます。
    2010年2月14日 4:06

すべての返信

  • たしか、Vistaにおいては、コマンドプロンプトのウインドウは不思議に高い特権で動いているとみなされるので、
    セキュリティのからみで(ドラッグドロップが効かなくなったのと同じように)SendInputでの介入が弾かれるのではないかとおもわれます。
    またほかにも、昇格されたアプリの出すウインドウには触れない現象が発生するのでは、と思います。いずれも確信はありませんが。

    jzkey
    • 回答としてマーク yneedshelp 2010年2月13日 11:29
    2010年2月13日 11:04
  • >Vistaにおいては、コマンドプロンプトのウインドウは不思議に高い特権
    なるほど、プライオリティということでしょうか…であれば納得です。ありがとうございました。
    2010年2月13日 11:28
  • >MS-DOSプロンプトのウィンドウ

    NT 系 OS に MS-DOS プロンプトはありません。
    正しい呼称は「コマンドプロンプト」です。(キャプションにもそう書いてあるはず)

    >>Vistaにおいては、コマンドプロンプトのウインドウは不思議に高い特権
    >なるほど、プライオリティということでしょうか…であれば納得です。ありがとうございました。

    不思議な現象ではありません。
    Vista 以降の OS の仕様です。

    Vista から、UAC と呼ばれる仕組みが導入されました。
    UAC が有効な場合、管理者権限を持ったアカウントでログオンしていても、プロセスを「昇格」をしないと、システムに致命的なダメージをもたらすような操作は実行することができなく(=失敗する)ようになっています。

    同じユーザ権限で実行されているプロセスであっても、昇格済みのプロセスと未昇格のプロセスの間では、ウィンドウズメッセージのやりとりができないなど、様々な制約が課せられています。
    本件もこれに該当するものと思われます。
    2010年2月14日 4:06
  • 渋木様、
    >正しい呼称は「コマンドプロンプト」です。
    また私の間違ったターミノロジーでしたね。すみません。質問するときには正しく記述を心がけます。

    >Vista から、UAC と呼ばれる仕組みが導入されました。
    なるほど、参考になります。

    確かに
    SetPriorityClass(GetCurrentProcess(),HIGH_PRIORITY_CLASS);
    をプログラムの頭に入れると解決できました。ありがとうございました。
    (プロセスプライオリティがかわったことによる他プログラムの挙動チェックをこれからしなければならないですが。)

    2010年2月14日 4:16
  • >SetPriorityClass(GetCurrentProcess(),HIGH_PRIORITY_CLASS);
    >をプログラムの頭に入れると解決できました。ありがとうございました。

    プロセスのプライオリティと UAC は、まったくの別物で、SetPriorityClass() は UAC で定義されている「昇格」の操作を行うものではありません。

    プロセスのプライオリティのせいで SendInput() が動作しない、というのはちょっと腑に落ちません。(フォーカスの操作なんかで問題を生じるならまだ分かりますが)
    2010年2月14日 5:33