先日公開したSignUpAssistですが、esのプログラム実行用空き領域が少ない状態の時に利用すると上手くプロセスが取得出来ずちゃんと動作してくれないことが分かりました。
Operaでタブを沢山開いてプログラム実行用空き領域を減らした後で試してみたら現象が再現出来ました。
その状態の時にITaskMgrでプロセスを見てみると、
![](https://blogimg.goo.ne.jp/user_image/2b/3e/2b15a9560c3a310642498ec842348ef9.jpg)
あ、そういう仕様?と思ったのですが、TaskManagerの方ではこの通りちゃんとプロセスを表示してくれます。
![](https://blogimg.goo.ne.jp/user_image/21/28/347b3dfe95a02e147a356d4e2cf165e0.jpg)
ということはITaskMgrとTaskManagerでプロセス取得方法が違うということになりますよね。
TaskManagerはプロセス一覧が表示されるまでに多少時間が掛かるので何かやってるんだと思いますが、この点について現在調査中です。
Operaでタブを沢山開いてプログラム実行用空き領域を減らした後で試してみたら現象が再現出来ました。
その状態の時にITaskMgrでプロセスを見てみると、
![](https://blogimg.goo.ne.jp/user_image/2b/3e/2b15a9560c3a310642498ec842348ef9.jpg)
あ、そういう仕様?と思ったのですが、TaskManagerの方ではこの通りちゃんとプロセスを表示してくれます。
![](https://blogimg.goo.ne.jp/user_image/21/28/347b3dfe95a02e147a356d4e2cf165e0.jpg)
ということはITaskMgrとTaskManagerでプロセス取得方法が違うということになりますよね。
TaskManagerはプロセス一覧が表示されるまでに多少時間が掛かるので何かやってるんだと思いますが、この点について現在調査中です。
面白そうなのでちょっと調べてみました。たしかに動作メモリを多少減らしてProcess32Firstを呼ぶとfalseが帰ってくるようですね。おそらくメモリ残量よりはその状態が悪いんだと思いますが。
で、TaskManagerのプロセス取得ですが、多分DWORD GetProcessIDFromIndex(DWORD dwIndex);とかいうAPIを使っているのではないかと。dwIndexに0から順に値を投げ込むと、プロセスが存在する限りIDが帰ってきて、なくなった時点で0が帰ってくるみたいです。これをループして片っ端からOpenProcessしてるから時間がかかってるんじゃないかなと思います。
いつもお世話になっております!
withATOKやlock2suspend等便利に使わせてもらってますm(__)m
調査していただきありがとうございます。
GetProcessIDFromIndexというAPIがあることを知りませんでした。
MSDNには載ってなかったのですが、coredll.dllを覗いたら見つかったので試してみて「なるほど~」と♪
で、さらに調べていたら、GetWindowThreadProcessIdというAPIを使えば、対象ウィンドウのプロセスIDを取得できるんですね(苦笑
オンラインサインアップで「使用ソフトウェアの設定」というタイトルのウィンドウが生成された時にそのプロセスIDを取得した後にTerminateProcessすることで、求めていた動作をさせることが出来ました。
今回はプロセス一覧を取得しなくてもいい方法が見つかりましたが、今後プロセス一覧を取得して操作するようなアプリを作る時には、Process32FirstではなくてGetProcessIDFromIndexの方を利用した方が良さそうですね。
教えていただきありがとうございましたm(__)m