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

Win32API質問箱 Build81

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2009/08/02(日) 00:20:49
スレ立てるまでもない、Win32APIのついての質問はこちらへどうぞ。
やさしいお兄さんやお姉さんたちが答えてくれるかも。
「知らないならレスしないで下さい。ウザイだけです。 」なんて言わないでねっ！

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

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

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

Win32API質問箱 Build80
http://pc12.2ch.net/test/read.cgi/tech/1244057140/l50
0082デフォルトの名無しさん2009/08/04(火) 19:21:03
Aero有効にしていてGetWindowRect等で正確なサイズを得る方法を教えろ
0083デフォルトの名無しさん2009/08/04(火) 19:26:17
ThemeAPIで頑張って計測、とかいう話じゃなかったっけ？

>>76
タブとかツールバーはクライアント領域の載せているものだから、
その上で空き領域を一定サイズ確保したいというなら当然必要。
0084デフォルトの名無しさん2009/08/04(火) 19:59:08
>>ThemeAPIで頑張って計測
ハズレ
0085デフォルトの名無しさん2009/08/04(火) 20:04:29
うそつくなよｗ
0086デフォルトの名無しさん2009/08/04(火) 20:15:48
知らないならレスしないで下さい。ウザイだけです。
0087デフォルトの名無しさん2009/08/04(火) 21:45:04
http://msdn.microsoft.com/ja-jp/library/ms633519(en-us,VS.85,loband).aspx
0088デフォルトの名無しさん2009/08/04(火) 21:50:14
VistaとXPではステータスバーの大きさが異なるんだけど
ステータスバーの大きさって変えられない？
自分でステータスバーもどきのウィンドウ作った方が速いかな？
0089デフォルトの名無しさん2009/08/04(火) 21:55:00
デバッグビルドでLoadLibraryA("MSVCP90.dll")実行するとNULLが返ってくるんだけど、MSってバカなの？何なの？
0090デフォルトの名無しさん2009/08/04(火) 21:58:05
>>88
SB_SETMINHEIGHTとか
0091デフォルトの名無しさん2009/08/04(火) 22:40:01
>>89
side-by-sideアセンブリ
0092デフォルトの名無しさん2009/08/04(火) 23:21:42
CランタイムをLoadLibraryする方がバカ
0093デフォルトの名無しさん2009/08/05(水) 04:12:25
ネットで公開されているAPIってサイドパーティ含めてどのくらいか？
把握している人はエロい
0094デフォルトの名無しさん2009/08/05(水) 06:51:42
は？
0095デフォルトの名無しさん2009/08/05(水) 08:14:32
http://www.google.com/search?q=api

Google先生は把握してますが何か？
0096デフォルトの名無しさん2009/08/05(水) 15:58:10
質問です。

ウインドウメッセージを解決するProcの中で、SendMessageをすると、即座に処理される理由がいまいちわかりません。
MessageBoxでも似たような疑問を持った際は「勝手にメッセージ解決ループを作って裏でまわしてくれるんだよ」
といった説明を受けて納得したのですが、今回の件も同様なのでしょうか？
0097デフォルトの名無しさん2009/08/05(水) 16:02:50
＞1 つまたは複数のウィンドウへ、指定されたメッセージを送信します。
＞この関数は、指定されたウィンドウのウィンドウプロシージャを呼び出し、
＞そのウィンドウプロシージャがメッセージを処理し終わった後で、制御を返します。
0098デフォルトの名無しさん2009/08/05(水) 16:03:19
SendMessageが発行したメッセージはちゃんとOSのメッセージキューに入れられて、
該当するウインドウのメッセージループに通知され、
その後メッセージハンドラがコールバックされて
対応するコード上で処理されてるから、即座じゃなくない？

MessageBoxの方も同様で、メッセージボックスがクリエイトされた後、
OS経由でメッセージがMessageBoxのメッセージハンドラに通知されてるよ。
Spy++みるとメッセージの応酬が見られるし。
0099デフォルトの名無しさん2009/08/05(水) 16:16:14
96です。
>>97-98
お返事ありがとうございます。
MSDNの説明を妙に勘違いしていたようです。

::SendMessageはウィンドウプロシージャを直接呼び出すのですね。
実は困っていたのは
case WM_CLOSE:
の中で別のワーカースレッドに停止命令を出し、ワーカースレッドの停止を確認するまでSleepする。
という処理でした。

このとき、ワーカースレッド側でSendMessageされると、フリーズしてしまいます。

これは、メインスレッドがプロシージャで処理中（Sleep中）なのに、他スレッドがプロシージャを呼ぼうとしたので、排他制御された。
ということで合っているでしょうか？
0100デフォルトの名無しさん2009/08/05(水) 16:36:52
>>99
そんな感じ。
ttp://msdn.microsoft.com/en-us/library/ms644927.aspx
のMessage Deadlocksに詳しく書いてある。
0101デフォルトの名無しさん2009/08/05(水) 16:48:44
>>100
ありがとうございます。
・・・そのページ、日本語版のMSDNでは省かれてますね・・・
0102デフォルトの名無しさん2009/08/05(水) 16:50:16
メッセージプロシージャを待ちたくないのなら、PostMessageを使ってみては
0103デフォルトの名無しさん2009/08/05(水) 16:51:04
メッセージプロシージャってなんだ・・・ウィンドウプロシージャでした
0104デフォルトの名無しさん2009/08/05(水) 16:58:57
>>102
色々アドバイスありがとうございます。
タイトルバーの書き換えが目的のため、ポインタ渡しが必要となり、PosｔMessageでは行えませんでした。
（SetWindowTextは、内部でSendMesssageを呼んでるっぽいですね）

ついでに、報告。
>>100の文書のおかげで
SendMessageTimeout
なる関数を知りました。
タイムアウト値を10msくらいにしておけば、デッドロックが起こらずに済みますね。

こんな関数知りませんでしたわ
0105デフォルトの名無しさん2009/08/05(水) 18:17:49
>>91
winsxsはside by sideで使われてたのか、MSめ・・・
0106デフォルトの名無しさん2009/08/05(水) 20:27:52
>>104
UIの更新はUIスレッドにやらせるのが基本。
文字列は別の場所に置いておいて、
PostMessageでタイトルバーの更新を指示、といった感じで。
0107デフォルトの名無しさん2009/08/06(木) 09:28:29
>>106
いちいちクリティカルセクション使って、文字列渡し合うのか？
0108デフォルトの名無しさん2009/08/06(木) 09:42:38
ロストを許すことなく、きっちり伝えようとするべくクリティカルセクションの出し入れすると
結局 SendMessage のブロッキングと同じでデッドロックにならない？
0109デフォルトの名無しさん2009/08/06(木) 11:28:21
C言語にfopenという関数があるのに
windows APIにもCreateFileという関数があって

どちらを使えばいいのかわかりません。
CreateFileのほうが細かく設定できるという認識だけで
よろしいのでしょうか？
0110デフォルトの名無しさん2009/08/06(木) 11:40:39
ファイルハンドル取得のためには必須なんじゃないの？
勉強中の身だからなんとも言えんけど、
プロに任せれば正しい回答が来るはず
0111デフォルトの名無しさん2009/08/06(木) 11:48:33
fopenはC言語の関数。
C言語が仕様を決め、Windowsが従ってる。
そのため（C言語の仕様が古いため）2GBまでのファイルしか扱えない。

CreateFileはWindowsが提供している関数。
Windows以外で使えないけど、代わりに2GBを超えるファイルも扱えるし、Windows特有のファイル属性なども操作できる。
0112デフォルトの名無しさん2009/08/06(木) 12:33:14
つまりWindows環境ならfopenよりもCreateFileのほうがいいってことか
0113デフォルトの名無しさん2009/08/06(木) 13:07:04
まぁそう考えてもOK
ただし、色々できる＝複雑ってことだからそのあたりは臨機応変で。
0114デフォルトの名無しさん2009/08/06(木) 14:15:59
毎回引数7個も書いてるとうざいぜ
fopenで間に合うときはそっちのがシンプルでいいよ
0115デフォルトの名無しさん2009/08/06(木) 17:36:58
>>111
以下コードで 4 GB のファイルが生成できる件について

#include <stdio.h>
#define MEGA_BUF_SIZE (1024 * 1024)
#define OUT_FILE "test.dat"
int main(void)
{
static char buf[MEGA_BUF_SIZE] = { 0 };
int i;
FILE *oFP = fopen(OUT_FILE, "wb");
if(oFP == NULL)
{
perror(OUT_FILE);
return -1;
}
for(i = 0; i < 1024 * 4; i++)
fwrite(buf, 1, sizeof(buf), oFP);
fclose(oFP);
return 0;
}
0116デフォルトの名無しさん2009/08/06(木) 18:15:32
つーかfopenも最終的にはCreateFileを呼んでるんだから当然だろ

>>111こいつバカじゃねーの？
0117デフォルトの名無しさん2009/08/06(木) 19:23:44
fopen で開いたファイル（FILE*）にランダムアクセスする際にfseekでは
32bit幅しか考慮されていないので、2Gの範囲しかアクセスできないと言う
点について、>>111がちょびっとだけカスってる。

＃まあ、そもそも fopen の仕様を決めているのはC言語ではないけどね…。

fopen が CreateFile呼んでるから当然使えるってのは、標準関数の仕様と
比べてどうかと言う方向からみるべきなので、短絡的な意見だとは思うが。
0118デフォルトの名無しさん2009/08/06(木) 20:16:53
SEEK_CURを使って2GBずつ進んでいくってのは無理？
0119デフォルトの名無しさん2009/08/06(木) 20:21:26
規格上はその辺り何も規定されてないので処理系に依存する。
0120デフォルトの名無しさん2009/08/06(木) 20:39:15
>>118
VC2008だと、0x7FFFFFFFより後への移動はエラーになって返ってくる。
関数内で、SetFilePointerを上位32ビットを指定せずに呼んでいる為に、
オフセット位置の範囲に制限がかけられている所為だな。
0121デフォルトの名無しさん2009/08/06(木) 20:46:08
使えねー
0122デフォルトの名無しさん2009/08/06(木) 21:25:26
つーか、CreateFileをラップしたクラスを作っとけばいいだろ・・・

そもそもクロスプラットフォーム開発してる訳でもなけりゃわざわざfopenなんて使う理由が無い
0123デフォルトの名無しさん2009/08/06(木) 21:49:47
そもそもクロスプラットフォーム開発してる訳でもなけりゃわざわざfopenなんて使う理由が無い（ｷﾘｯ
0124デフォルトの名無しさん2009/08/06(木) 21:54:12
そもそもクロスプラットフォーム開発してる訳でもなけりゃわざわざfopenなんて使う理由が無い（ﾇﾙﾎﾟ
0125デフォルトの名無しさん2009/08/06(木) 21:57:04
>>124
がっ
0126デフォルトの名無しさん2009/08/06(木) 22:10:06
fopen （笑）
0127デフォルトの名無しさん2009/08/06(木) 22:12:36
C言語 （笑）
0128デフォルトの名無しさん2009/08/06(木) 22:16:42
今時マルチスレッドや巨大ファイルの扱いが規格外なプログラミング言語なんてゴミ
0129デフォルトの名無しさん2009/08/06(木) 22:16:44
ﾇﾙﾎﾟ （笑）
0130デフォルトの名無しさん2009/08/06(木) 23:04:30
今時ポインタがあるプログラミング言語なんてゴミ
0131デフォルトの名無しさん2009/08/06(木) 23:11:25
と思ってるお前がゴミ
0132デフォルトの名無しさん2009/08/06(木) 23:22:58
ふぉぺん
0133デフォルトの名無しさん2009/08/06(木) 23:26:21
その辺にしとけ
0134デフォルトの名無しさん2009/08/06(木) 23:39:51
何を？
0135デフォルトの名無しさん2009/08/07(金) 00:43:08
ネットワークディレクトリをsamba(smb)共有させる場合、
IEのURL打ち込み欄で

\\hostname.com

で、、このあとアカウントとパスワードを入力するダイアログが表示され
進めるとネットワークディレクトリがマウントできますが、
（Vistaの場合、レジストリを変更してセキュリティポリシーの書き換え必要）

この一連の流れをC++/MFCの環境で記述してマウントさせたいのです。
具体的にどういうAPIを使えばよいか、どういうサイトを参照すればよいか
など教えていただけますでしょうか。

よろしくお願いします。

0136デフォルトの名無しさん2009/08/07(金) 00:53:01
>>135
http://msdn.microsoft.com/ja-jp/library/default.aspx
0137デフォルトの名無しさん2009/08/07(金) 03:59:35
マウントといったら、WNetAddConnection2しか思いつかん
0138デフォルトの名無しさん2009/08/07(金) 06:05:30
それでいい。WebDAV のフォルダもマウントできるし。
0139デフォルトの名無しさん2009/08/07(金) 11:42:31
>>99
なんか微妙に誤解があるような気が……
ウィンドウプロシージャをメッセージ経由で実行する場合は、
必ずウィンドウを作成したスレッドで実行されるのがwindowsの仕様です。
その場合は、このスレッドがSleepさせられているため、SendMessageで
デッドロックするわけです。
0140デフォルトの名無しさん2009/08/07(金) 12:17:19
スレッド間でSendし合うからだろ
0141デフォルトの名無しさん2009/08/07(金) 14:29:26
sendし合うのは問題ない。
別スレッドにSendMessageして、send先から返ってくるのを待ってる間は
別スレッドからのSendMessageを受け付ける事ができる。
0142デフォルトの名無しさん2009/08/07(金) 14:58:05
色んなｽﾚｯﾄﾞからｷｭｰに積むだけなら可能

だが、sendされた側がﾒｯｾｰｼﾞﾙｰﾌﾟでｷｭｰを喰い実行してくれないと
呼び出し側はﾌﾞﾛｯｸされっぱなしで SendMessage から戻ってこれない
0143デフォルトの名無しさん2009/08/07(金) 15:14:37
141のがあってると思う。
SendMessageから戻って来ない間も、別スレッドからのSendMessageには
即呼び出される。殆ど相手のコンテキストで動いてる感じ。

SendMessageなら戻ってくるまでは他のメッセージが来ないので安心、
と言うことではない。
0144デフォルトの名無しさん2009/08/07(金) 15:19:14
ここのバカ共はReplyMessageも知らんのか
0145デフォルトの名無しさん2009/08/07(金) 15:45:30
ReplyMessage関係あんの？
0146デフォルトの名無しさん2009/08/07(金) 16:08:31
コモンコントロールのウィンドウデータ、端的に言うとGWLP_USERDATAの領域にSetWindowLongPtrで
アプリケーション側の値を設定しているコードがあったんですけど、これって有効なんでしょうか。
ずっとコントロール側が使ってるものと思い込んでいたのですが。。。
0147デフォルトの名無しさん2009/08/07(金) 16:58:33
MSDNくらい読めよ低脳
http://msdn.microsoft.com/ja-jp/library/cc411204.aspx
0148デフォルトの名無しさん2009/08/07(金) 17:05:07
低脳はお前の方だろ
0149デフォルトの名無しさん2009/08/07(金) 17:08:04
いやアナタです
0150デフォルトの名無しさん2009/08/07(金) 17:09:51
いや、俺だ!
0151デフォルトの名無しさん2009/08/07(金) 17:20:31
マジで！？
01521462009/08/07(金) 17:58:31
タブコントロールとかだと各タブ要素のデータがウィンドウごとに確保されますけど、
GWLP_USERDATAとは全く別の領域に確保されてるんでしょうか。
コモンコントロールをspy++で見ると、ウィンドウバイトが割り当てられていて
それがコントロールが使っているものなのか、アプリケーションに任せているのか僕では判断できません。

コモンコントロールのクラスが定義済みなので、MSの配慮としてアプリケーション用に確保されているのかと
考えてしまいますが、明記されてる記事を見つけることができませんでした。
0153デフォルトの名無しさん2009/08/07(金) 18:04:44
＞GWLP_USERDATA
＞ウィンドウに関連付けられた値を設定します。
＞この 32 ビット値は、＜＜＜＜ウィンドウを作成したアプリケーションで使用する目的で＞＞＞＞各ウィンドウが持っているものです。
＞この値の初期値は 0 です。

この程度の日本語の解釈もできないの？
あんた小学生？
馬鹿なの？
死ねよ
0154デフォルトの名無しさん2009/08/07(金) 18:06:03
おちつけちゃ〜ん
01551462009/08/07(金) 18:08:25
普通のウィンドウの拡張と同じように、コモンコントロールも後付で作られたクラスなので、
そのアプリケーション用というのが、本当に自作アプリケーションのためなのか、
コモンコントロールの拡張用なのかよくわかりません。
言葉どおり受け取るならそういうことなんですが。。。
0156デフォルトの名無しさん2009/08/07(金) 18:11:57
コモンコントールは拡張ウィンドウメモリを使っていてGWLP_USERDATAは使ってないはず。
でもサードパーティ製のコントロール等はGWLP_USERDATAを使ってる物もある。
Spy++で見れば分かる。

いずれにしろ自作コントロール以外ではプロパティリストを使う方が安全。
0157デフォルトの名無しさん2009/08/07(金) 18:19:05
ま、サブクラスする時はSetWindowSubclass()でいいから
GWLP_USERDATAの使い道なんてほとんど無いけどな
0158デフォルトの名無しさん2009/08/07(金) 18:38:07
スレッドの中で自分で作った関数を呼びまくってるんですが
その関数内でオート変数を使ってるんですが
メモリリークとか大丈夫なんですかね？
0159デフォルトの名無しさん2009/08/07(金) 18:42:10
Win32APIになんか関係あるん？
0160デフォルトの名無しさん2009/08/07(金) 18:47:19
いやごめんなさいくずまったくかんけいないですがごみきいてみたかったんですよ
0161デフォルトの名無しさん2009/08/07(金) 19:29:53
いつの間にかWindows 7 SDKがRMTに
0162デフォルトの名無しさん2009/08/07(金) 19:32:20
アドレス忘れた
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=71deb800-c591-4f97-a900-bea146e4fae1
0163デフォルトの名無しさん2009/08/07(金) 19:34:42
RMTじゃリアルマネートレードだろ
0164デフォルトの名無しさん2009/08/07(金) 19:56:01
いつの間にかWindows 7 SKDがRTMに

これでいい？
0165デフォルトの名無しさん2009/08/07(金) 19:58:14
>>163-164
RTM じゃリアルタイムマネーだろ!
0166デフォルトの名無しさん2009/08/07(金) 20:00:09
いつの間にかWindows 7 SDKがATMに
0167デフォルトの名無しさん2009/08/07(金) 20:11:40
それじゃオートメーテッドテラーマシーンだろ
0168デフォルトの名無しさん2009/08/07(金) 22:31:42
もうだめだこのスレ
0169デフォルトの名無しさん2009/08/07(金) 22:37:46
dumpbin /DEPENDENTS みたいに依存するDLL名って、Win32APIではどのように取得するんでしょうか
0170デフォルトの名無しさん2009/08/07(金) 22:58:48
API レベルで用意してるのかなぁ？
PEフォーマットの仕様ははっきりしてるし、
依存DLL名だけ調べるくらいならそんなに難しくないよ。
PEフォーマットについてかなりわかりやすく解説したページが以前はあったんだけど、
今は消滅しちゃってるな。 まぁ、マイクロソフトのページに行けばキッチリした仕様書が入手できる。
0171デフォルトの名無しさん2009/08/07(金) 23:25:37
解説も何も、PEフォーマットなんてせいぜいRVAがウザい程度でしょ
それもimagehlp.dllのAPIを使えば簡単だし
0172デフォルトの名無しさん2009/08/07(金) 23:34:12
>>157
それって、Xp以降専用になるんじゃ……
まあ、それも時代か。
0173デフォルトの名無しさん2009/08/07(金) 23:36:35
2000ってそろそろサポ切れるよな
0174デフォルトの名無しさん2009/08/08(土) 00:06:36
>>170-
ImageDirectoryEntryToDataEx使ってそれっぽいのとれたんですけど、RVAからVAの変換でミスｇ・・・
よくわかんねー
0175デフォルトの名無しさん2009/08/08(土) 00:52:59
>>172
MSDNにはXP以降と書かれてるけど実際には2000でも使える。
0176デフォルトの名無しさん2009/08/08(土) 08:04:08
Windows7 SDK のISOイメージは、まだx86版しか上がってないのか。
今までと違って、x64環境にはx64用のイメージが必要なのに気付かなかったぜ。
0177デフォルトの名無しさん2009/08/08(土) 09:41:58
>>176
試してないけど、ファイルはあるみたい。
http://download.microsoft.com/download/2/E/9/2E911956-F90F-4BFB-8231-E292A7B6F287/GRMSDKX_EN_DVD.iso
01781352009/08/08(土) 16:14:41
>>135のものですが、>>137さんありがとうございます。
その方法で試みていますが、うまくいきません。
具体的には、
LPNETRESOURCE netResource = new NETRESOURCE();
netResource->dwScope = 0;
netResource->dwType = RESOURCETYPE_DISK;
netResource->dwDisplayType = 0;
netResource->dwUsage = 0;
netResource->lpLocalName = ""; // ネットワークドライブにする場合は"z:"などドライブレター設定
netResource->lpRemoteName = "\\\\hostname.com";
netResource->lpProvider = "";
DWORD err = WNetAddConnection2(netResource, "password", "account", CONNECT_UPDATE_PROFILE);
で、戻り値のerrは０になったのですが、マウントがされません。
netResource->lpLocalName = "Z:";
のようにしても、Zドライブに割り当てられません。
何が原因でマウントされないのでしょうか？
マウントされたボリュームが表示されるようにしたいのですが、
どうすればよいか教えてください。
よろしくお願いします。
0179デフォルトの名無しさん2009/08/08(土) 17:59:47
>>177
サンクス。ハッシュも一致していたし、それでOKみたいだ。
0180デフォルトの名無しさん2009/08/08(土) 18:00:32
lpRemoteNameにホスト名だけを指定しているのがまずいような
多分\\\\hostname.com\\folderのようにするはず
で、folderは共有されていなければならなかったはず
0181デフォルトの名無しさん2009/08/08(土) 22:49:32
7で目覚まし動かん
0182デフォルトの名無しさん2009/08/08(土) 23:01:41
相変わらずSDKでけぇなー
.NETとかイラネーし別ファイルにしてくれよ・・・
■ このスレッドは過去ログ倉庫に格納されています