トップページ⇒tech
1001コメント241KB

Win32API質問箱 Build71

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2008/10/23(木) 15:59:18
スレ立てるまでもない、Win32APIのついての質問はこちらへどうぞ。
やさしいお兄さんやお姉さんたちが答えてくれるかも。

過去スレ、関連リンクは>>2-10くらい。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。英語版(http://msdn2.microsoft.com/library/)の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

- Win32API質問箱 wiki
http://wiki.livedoor.jp/program1/d/FrontPage

Win32API質問箱 Build70
http://pc11.2ch.net/test/read.cgi/tech/1221446107/
01521482008/10/28(火) 00:05:42
WINVERには確実に数値が入ってそうですね

定義されてないとそのヘッダファイルのリリース時の最新バージョンが定義される
ってかんじなんですかね
気をつけてないと無意識にVistaでしか動かないアプリとか作ってしまいそうです

明示的にターゲットのバージョンを定義するのが良い作法の様ですね

>>149
>>151
ありがとうございました
0153デフォルトの名無しさん2008/10/28(火) 01:56:16
プロポーショナルフォントの場合、文字の横幅はバラバラなんですよね？
で、TEXTMETRIC構造体のtmAveCharWidthというメンバで文字横幅の平均値は
得られるようですが、この横幅を基準に文字列がどのくらいのフィールドを
必要とするかを考えても、文字の組み合わせによっては、想定したフィールドの
横幅からはみ出すこともあるってことで、OK？
対処法は余裕をもって場所確保しておけってことなのかな。
0154デフォルトの名無しさん2008/10/28(火) 02:01:52
それでいいと思われ
万全を期すならGetTextExtentPoint32使った方がいいんだろうけど
0155デフォルトの名無しさん2008/10/28(火) 02:06:36
レスどうもです。
GetTextExtentPoint32というのは、文字列ごとに計算するって奴ですよね。
0156デフォルトの名無しさん2008/10/28(火) 02:51:07
最大字数が決まってて、どんな組合せでもはみ出さないようにしたい
という用途みたいだから、tmMaxCharWidth*nでないの
0157デフォルトの名無しさん2008/10/28(火) 03:42:24
たしかにそのやり方がよさげですね。
大文字の場合も考慮に入れてくれるんですよね、その関数。
0158デフォルトの名無しさん2008/10/28(火) 07:23:44
.exeと同じフォルダに○○.chmがあれば
ShellExecute(hwnd,"open","○○.chm",NULL,NULL,SW_SHOWNORMAL);
って書けばふつーにchmが開くんですか？
0159デフォルトの名無しさん2008/10/28(火) 07:36:28
>>158
やってみれば？
01601582008/10/28(火) 08:32:13
嫌です
0161デフォルトの名無しさん2008/10/28(火) 09:05:07
いやーん
0162デフォルトの名無しさん2008/10/28(火) 09:16:37
>>159
できました、どっかでID、ヘッダーファイルがどうこうと見たので
たんに開くだけの場合も何か必要と思い込んでました…
0163デフォルトの名無しさん2008/10/28(火) 09:51:10
パス省略できるのはカレントディレクトリだから
0164デフォルトの名無しさん2008/10/28(火) 10:32:37
「カレントディレクトリ」≠「exeのあるディレクトリ」の時に正常動作しない糞アプリの完成ですね
0165デフォルトの名無しさん2008/10/28(火) 14:15:49
GetObject( hbmp, sizeof( BITMAP ), &bmp );
とした時の BITMAP::bmBits は解放する必要ないのでしょうか？
0166デフォルトの名無しさん2008/10/28(火) 14:27:05
LocalFreeで開放しろと書いてあるだろ
01671652008/10/28(火) 14:40:05
>>166
http://msdn.microsoft.com/ja-jp/library/cc410355.aspx を見ただけでは
その記述を見つけることはできませんでした。
ありがとうございました。
0168デフォルトの名無しさん2008/10/28(火) 14:51:21
いや、DIBSECTION以外はNULLのままじゃないか？
0169デフォルトの名無しさん2008/10/28(火) 14:55:22
CreateDIBSectionのppvBitsに入るのと同じアドレス値でしょ
0170デフォルトの名無しさん2008/10/28(火) 15:02:51
>>167のリンク先なんだけど

> この関数は、、、、、、or いずれかの構造体、またはテーブル内のエントリ数（論理パレットに対応）を格納します。

何これ
0171デフォルトの名無しさん2008/10/28(火) 15:05:38
>>170
8ビット以下のbmpはパレット付き
0172デフォルトの名無しさん2008/10/28(火) 15:09:15
>>171
いやそうじゃなくて、機械翻訳がおかしいと言いたいのだが・・・
01731652008/10/28(火) 15:15:15
>>166
LocalFree() するとアクセス違反が起こりました
問題なく処理は進んでいますが、
念のためコメントアウトしておきます

>>168
ヘルプを見る限りそのようなので、
CreateDIBSection() でBITMAPを作成しています

>>169
同じアドレスということは
メモリの管理はAPI側がやってくれるということなのでしょうか？

>>170
日本語版ヘルプはそういうのが多いですね
特にWin32APIで
0174デフォルトの名無しさん2008/10/28(火) 15:17:04
>>173
自分で作ったバッファのアドレスが入ってるだろうってことじゃないか？
01751652008/10/28(火) 15:20:01
>>174
自分でバッファを作ったわけではなく、
CreateDIBSection() の引数で void** を渡し、
そこにアドレスが入っています。
なのでシステムが用意したバッファだと思っているのですが・・・
0176デフォルトの名無しさん2008/10/28(火) 15:21:29
自分で（CreateDIBSectionで）作ったバッファの（中のどこかの）アドレスが入ってるだろうってことじゃないか？
0177デフォルトの名無しさん2008/10/28(火) 15:25:32
だからCreateDIBSectionで作ったやつはGetObjectに関係なくDeleteObjectすればいい
01781652008/10/28(火) 15:27:37
>>176
すみません読み違えていました

>>177
つまり DeleteObject() さえしていれば
解放の必要はないということですね？
ありがとうございました。
0179デフォルトの名無しさん2008/10/28(火) 15:28:24
>>168-169が正解
>>166は大嘘
0180デフォルトの名無しさん2008/10/28(火) 17:43:45
タスクマネージャで見てハンドル値とかが増加していかなければおｋ
0181デフォルトの名無しさん2008/10/28(火) 19:11:35
おれつえええええええええええええええ
0182デフォルトの名無しさん2008/10/28(火) 23:47:58
タスクトレイに常駐して、任意のキーが押されたらある処理をするアプリを作ろうと思ってます

実現するには、アプリケーションのウィンドウがアクティブではない時も
キーイベントを拾う必要があると考えてます

この場合、
・キーボードフックを使う
・GetAsyncKeyStateでポーリングしながらキー入力をチェックする

以外の方法が思いつかないんですが、他にやり方はありますか？
0183デフォルトの名無しさん2008/10/28(火) 23:59:36
>>182
ホットキー
01841822008/10/29(水) 00:08:47
>>183
おぉぉぉぉ
正にこの機能が欲しかったです

RegisterHotKey（）
で頑張ります
0185デフォルトの名無しさん2008/10/29(水) 00:11:24
がんばらなくてもいいじゃないか、にんげんだもの
0186デフォルトの名無しさん2008/10/29(水) 00:45:37
Win32APIを勉強し始めて、今スクロールバーの処理について学んだんですが
けっこうスクロールバー1つ付けるにしても、メッセージを処理しなくちゃ
いけないんだなぁなんて思ってるところでありまして、これがC#などの
いわゆる高級言語だと、どれくらい楽に実装できちゃうんでしょうか。
あまり変わらないのでしょうか。
0187デフォルトの名無しさん2008/10/29(水) 00:53:29
今は言語何使ってんだよ
0188デフォルトの名無しさん2008/10/29(水) 01:03:02
C/C++です
0189デフォルトの名無しさん2008/10/29(水) 06:15:49
pythonです
0190デフォルトの名無しさん2008/10/29(水) 06:45:25
無料で使える Express 版があるんだから、ちょっと試してみればいいじゃん。
0191デフォルトの名無しさん2008/10/29(水) 08:31:05
>>186
C#は何も知らなくても基本的なGUIアプリ作れるくらいにラク
0192デフォルトの名無しさん2008/10/29(水) 09:00:29
>>186
C#だと、プロジェクトを作っただけで、既にウインドウが１つ作られてて、
それだけで既に一通り動作する。
そして、デザイン画面でボタンをD&Dで貼り付けてダブルクリックするだけで、
ボタンクリック時のメッセージハンドラが作られる。
0193デフォルトの名無しさん2008/10/29(水) 09:01:34
これはC++でMFCの場合も同じだが。
0194デフォルトの名無しさん2008/10/29(水) 09:26:22
労力は半分以下
0195デフォルトの名無しさん2008/10/29(水) 09:41:45
スクロールバーで何やってるのかわからんけど
一般的な動作以外をやらせてるなら手間はあまり変わらんぞ、そこの部分だけは。
0196デフォルトの名無しさん2008/10/29(水) 10:06:11
６４ビット版WindowsではWin64APIってのを使うのかい？
他の呼び方があるの？
0197デフォルトの名無しさん2008/10/29(水) 10:10:34
APIはWIN32APIのままだよ
0198デフォルトの名無しさん2008/10/29(水) 11:02:45
>>192
C#はって言うより十数年前のVBで既にそうだった訳だが
0199デフォルトの名無しさん2008/10/29(水) 16:25:12
IntelliPointでブラウザなんかをホイールクリックすると任意方向へスクロールさせることができるけど
あれを自前のアプリへで対応させるのってどうやるの？
どっかにドキュメントがあったら教えてください。
0200デフォルトの名無しさん2008/10/29(水) 16:49:45
DoReaderMode
02011862008/10/29(水) 18:06:15
レスどうもです。
MFCなんかでは、ウィザードである程度コードの骨格を作ってくれるというのは
知っていたので、C#も同じような感じですか。
ただ、それならWin32APIでも、一度自分でひな形を作れば、それほど手間は
変わらないのかなと。それよりも、スクロールに付随する複雑な描画の部分を
魔法のように解決してくれるってことはないんですね。
そういう意味ではあまり変わらないのかなぁという印象です。
0202デフォルトの名無しさん2008/10/29(水) 18:10:02
いや、状況にもよるが例えば画像のスクロールに対応済みのコントロールはあるから
それ貼るだけでいい、というのはあるよ。
0203デフォルトの名無しさん2008/10/29(水) 20:48:29
スクロールバーってそんなに面倒かな
コモンコントロールの方がよっぽど面倒なのたくさんあるぞ
0204デフォルトの名無しさん2008/10/29(水) 22:09:40
64ビット版のプログラムって何が違うの？
long型が64ビットとかになるのかな。
32ビット版プログラムも動くの？
Win32APIの知識でそのまま移行できるのかい？
0205デフォルトの名無しさん2008/10/29(水) 22:12:50
その質問からして32ビットプログラムの何が32ビットなのかも分かってないだろ
0206デフォルトの名無しさん2008/10/29(水) 22:14:03
LLP64
0207デフォルトの名無しさん2008/10/29(水) 22:23:05
>>205
自慢じゃありませんが、よくわかっていません。
CPUが一度に処理できるデータのサイズが32ビットである
アーキテクチャ用のプログラムが32ビットプログラムと
違うの？
0208デフォルトの名無しさん2008/10/29(水) 22:23:14
Win32APIを最低限理解していれば64ビットへの移行の際に問題は一切発生しません
0209デフォルトの名無しさん2008/10/29(水) 22:25:22
>>205
で、正解は？
0210デフォルトの名無しさん2008/10/29(水) 22:54:32
>>209
プログラムが32ビットにきまってるだろう
0211デフォルトの名無しさん2008/10/29(水) 22:55:06
いや、つまんないから
0212デフォルトの名無しさん2008/10/29(水) 23:17:09
けっきょくみんな半信半疑なんだろ
64ビットプログラムって奴がさ
0213デフォルトの名無しさん2008/10/29(水) 23:49:29
>204
「long型が64ビットとかになるのかな。」って、
32ビット版のプログラムは、long型は何ビットなんだ？
0214デフォルトの名無しさん2008/10/29(水) 23:53:56
32ビットやろう、intと同じで。
0215デフォルトの名無しさん2008/10/30(木) 00:25:26
>>202
>画像のスクロールに対応済みのコントロール
どれ?
0216デフォルトの名無しさん2008/10/30(木) 01:00:05
それ
0217デフォルトの名無しさん2008/10/30(木) 01:04:21
なるほど
0218デフォルトの名無しさん2008/10/30(木) 01:20:14
LLP64は long long とポインタが64bitだから
int とlongは32bitのまま
0219デフォルトの名無しさん2008/10/30(木) 01:48:56
他のウィンドウに隠れたウィンドウをキャプチャすることはできる？
もしくは画面外のウィンドウをキャプチャすることはできる？

だいぶ調べたけど一番上のウィンドウ（もしくはデスクトップ全体）かつ
デスクトップ画面内しか無理という結論に達しつつあるんだけど・・
0220デフォルトの名無しさん2008/10/30(木) 01:50:07
無理
0221デフォルトの名無しさん2008/10/30(木) 02:00:57
で、ぼちぼち64ビットプログラムのイメージを抱かせてくれないか…
たとえばwPramとかlParamが64ビットになるのか？
それともlong longをふんだんに使えばいいのか？
0222デフォルトの名無しさん2008/10/30(木) 02:07:02
64bitになるのは、ポインタだけだよ。
0223デフォルトの名無しさん2008/10/30(木) 02:09:43
アドレスが６４ビットになるということはwParam, lParamも６４ビットになるということなのかという話ですよね。
0224デフォルトの名無しさん2008/10/30(木) 02:14:45
wParamやlParamがポインタのtypedefだったら64bitになるけど、そうじゃないよね？
ちなみに、Windowsのカーネルも32bitと64bitでソースコードベースは統一されている。
0225デフォルトの名無しさん2008/10/30(木) 02:17:26
あと、ポインタのtypedefである(#defineだっけ？)ハンドル型も64bitになるね。
0226デフォルトの名無しさん2008/10/30(木) 02:21:32
>>221
いまいち覚えてないしPSDKも手元にないのでアレだが、typedef LONG_PTR LPARAMになるんじゃないか？WPARAMは多分変わらないだろう。
64ビットになることで今まで無邪気にint型相当のデータ型にポインタぶち込んでたところが64ビット整数型を使わなければならなくなる。
UINT_PTRとかDWORD_PTRなんてデータ型見たことないか？
従来ポインタ-整数間のやり取りをしていた箇所が「ポインタを収められるサイズ相当の整数型」を使うようになって、具体的に32ビットか64ビットかを問わずHOGE_PTRとかで抽象的に扱えるようになってる。
その点Win32APIの方でも64ビットを意識した修整が入ってるから、ポインタは絶対32ビットだ〜みたいなことしてなければ「多分」従来どおりでいい。
02272242008/10/30(木) 02:23:06
すまん、思いっきり勘違いしていた。
wParam,lParam両方とも64bitになるな。
0228デフォルトの名無しさん2008/10/30(木) 02:25:14
typedef UINT_PTR WPARAM
typedef LONG_PTR LPARAM

だね。ポインタだから64bit
02292262008/10/30(木) 02:28:07
すんません。>>228のとおり。
WPARAMも64ビットになるね。windef.hを急いで確認したよ。
0230デフォルトの名無しさん2008/10/30(木) 02:43:10
HOGE_PTRを見るとPHOGEみたいな感覚になるから嫌い
0231デフォルトの名無しさん2008/10/30(木) 02:45:06
>>219
PrintWindow()
0232デフォルトの名無しさん2008/10/30(木) 02:54:57
↑デタラメ言うな
0233デフォルトの名無しさん2008/10/30(木) 02:59:52
とにかく普段から抽象データ型を使うように努めればいいわけか。
0234デフォルトの名無しさん2008/10/30(木) 03:03:31
Windwos7なんてものが遠くない内に出るようだが、
新しいOSを機にぼちぼち64ビットWindowsに乗り換えるべきだろうか。
0235デフォルトの名無しさん2008/10/30(木) 03:15:00
>>219
他人のウィンドウが自分のウィンドウエリアに描画するから無理だよ。
Vistaならできるかも。
0236デフォルトの名無しさん2008/10/30(木) 03:23:17
>>232
いやXP以降だけどPrintWindow()でいいだろ。

2000なら対象ウィンドウを一旦レイヤードウィンドウにするとかいう強引な手もあるが。
0237名無し募集中。。。2008/10/30(木) 03:23:24
>>215
CStatic
0238デフォルトの名無しさん2008/10/30(木) 09:09:41
>>236
デタラメ言うな
0239デフォルトの名無しさん2008/10/30(木) 09:48:05
このでたらめ言うやつは何なの？
自分が間違ってたことを認めないためには質問者に嘘教えるのも厭わないのか。
0240デフォルトの名無しさん2008/10/30(木) 09:48:41
>>238のことね、もちろん
0241デフォルトの名無しさん2008/10/30(木) 09:48:53
印刷したいんですが。
DCに書けばいいのか？
0242デフォルトの名無しさん2008/10/30(木) 09:55:20
もちろんDCに書くけど、準備がいろいろあるから
まずはサンプルコードをコピーしてくるところから
始めた方がいいよ。
0243デフォルトの名無しさん2008/10/30(木) 10:58:48
64ビットでもSysListView"32"なんだろ？
意味わかんねぇ
MSの中の人、頭おかしいんじゃないの
0244デフォルトの名無しさん2008/10/30(木) 11:05:17
>>243
64ビットでも kernel32.dll だし、システムフォルダは c:\windows\system32 だよ。
逆に、64ビット環境での 32 ビット用が WOW64。

最初は戸惑うよね。
0245デフォルトの名無しさん2008/10/30(木) 11:15:48
過去のしがらみのないOSがいいならGNU Hurdでも使っておけと。
0246デフォルトの名無しさん2008/10/30(木) 12:41:48
>>244
こういうのってやっぱシステムフォルダ = "c:\windows\system32"って
ハードコードしてる糞アプリの為の互換性なんだろうな

シェアが高すぎるOSってのも大変だなぁ・・・
0247デフォルトの名無しさん2008/10/30(木) 13:13:11
PostMessageとSendMessageの違いですが
ぶっちゃけメッセージループのためのメッセージキューに送られるのがPostで
直接WindowProcに送られるのがSendってことでOKですか？
0248デフォルトの名無しさん2008/10/30(木) 13:52:23
おｋ
0249デフォルトの名無しさん2008/10/30(木) 13:54:01
どっちもキューに入るけどな。
WindowProcの戻り値がわかるのがSendで、わからないのがPost
もちろん、SendはWindowProcが終わるまでリターンしない。
0250デフォルトの名無しさん2008/10/30(木) 14:14:56
>>231
すげえ、できた！
まじありがとう

>>235
>Vistaならできるかも。
kwsk
0251デフォルトの名無しさん2008/10/30(木) 14:37:28
>>250
え？できたの？理解できない。
もしかしてOSはVista？
Vistaはアプリケーションごとにサーフェイスを持ってるから、描画したのが残ってるんじゃないかと。

WM_PAINTですら描画しないと消えるのに
WM_PRINTなんかでなんの処理もしてないのに描画されるはずがないと思う。
もちろんWM_PAINTをWindowsまかせにしてるアプリならWM_PRINTにも対応してるだろうけど。
0252デフォルトの名無しさん2008/10/30(木) 14:42:55
逆だろ。
WM_PRINTをWindows任せにしてるとWM_PAINTと同じ内容になる。
■ このスレッドは過去ログ倉庫に格納されています