[過去ﾛｸﾞ] Win32API質問箱 Build125 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
301: 蟻人間 ◆T6xkBnTXz7B0 2019/09/14(土)16:58 ID:0f+SL6BM(1) AAS
俺は自作のリソーエディタ使ってるけど。MinGWでもVC++でもビルドできるよ。
302: 2019/09/14(土)17:18 ID:i3tDL1ol(2/2) AAS
>>294
コモンかどうか名前はさておき、リストビューは明確にcomctl32を使うような
宣言とリンクがないと使えないでしょ
リストもコンボはこいつの範疇ではない
303: 2019/09/14(土)19:04 ID:TUFMAlcF(2/2) AAS
WinUser.h
ComboBox CB_ERR
ListBox LB_ERR
CommCtrl.h
ListView関係のメッセージやマクロ
この違いは歴史関係って事？
LVM_INSERTITEMが失敗した場合は-1が返るけど
LV_ERR(-1)とするのはおかしい？
304: 2019/09/14(土)19:37 ID:5CB9SZmv(1) AAS
作者の気持ちを想像して答えなさいスレッド
305: 2019/09/14(土)21:33 ID:FV8dJ/wR(1) AAS
Windowsで.NET使わずにC/C++とWin32APIでPerl互換の正規表現を使ったプログラムを作る場合、
従来はboost::regexやPCREなど別途ライブラリが必要だったけど、Windows10以降はICUの正規表現を使えるようになった。
ただし、可変長文字列を扱うUnicodeStringクラスがヘッダーファイルicu.hから削除されているので、std::wstringなどで代替する必要がある。
306(1): 2019/09/14(土)21:43 ID:EnCOcX5P(1/2) AAS
ListViewはWindows95で追加されたコントロール
307: 2019/09/14(土)22:37 ID:bBqfD384(1) AAS
昔の事は多少は多目に見てやれよ。今みたいにSNSが活発じゃないし、githubで他人のソースも簡単に見れるわけしゎゃない。知見を共有しづらい時代なんだから
308: 2019/09/14(土)22:44 ID:BTqGkHHG(5/5) AAS
システムハンガリアンという糞も生みだしたしな
309(1): 2019/09/14(土)23:54 ID:EnCOcX5P(2/2) AAS
ハンガリアン記法自体はBug捕り等に有効だったのに
310: 2019/09/15(日)01:22 ID:84ndTw+e(1) AAS
dwは長さが一番揺らいでると思う
311: 2019/09/15(日)04:13 ID:oAEy9Na1(1) AAS
Standard Control
Common Control
312: 2019/09/15(日)07:17 ID:o13gcpb2(1) AAS
>>309
システムハンガリアンは違うし、なんで過去形なんだ？
313: 2019/09/15(日)10:17 ID:WyNEQ0+k(1) AAS
>>306
そうなのか
他の人もありがとう
314(1): 2019/09/15(日)12:35 ID:tu3q64lr(1) AAS
unix の execlp だと pid は変化しませんが、
Win32API の execlp とか _execlp とかだと processID は変化してしまうようです。
CreateProcess が呼ばれているからだと思いますが、
Win32API の execlp とか _execlp とかで変わったあとの processID を知る方法はありますか？
(起動された側で getpid() で判るのですが、そっちではなくて元の processID を握ってる方からのリンクが切れて困ってます。)
315: 2019/09/15(日)18:08 ID:jdtp5u68(1/2) AAS
>>297
俺はリソーススクリプト直叩き
MSDNに詳しい情報乗ってるし、英語だけど
プログラマなら大体わかるよ、翻訳サイトを使ってもいいしね
そして、ライブラリ化しといて次から簡単に使えるようにしとく
バージョン情報とかも関数やクラスにして簡単に使えるようまとめとけば便利
GUIは.NETがクラス化の良いお手本になるよ
316(1): 2019/09/15(日)19:39 ID:WzV8SEFI(1) AAS
VS使わない縛りなの？
317: 2019/09/15(日)19:55 ID:G+rzyOKL(1) AAS
>>314
> Win32API の execlp とか _execlp
そもそもexeclpとかはwin32apiじゃなくて単なるライブラリだよ
とりあえずざっとソース見る限りではpidを返す方法はないみたい（インターフェースもないしね）
自分で実装するしかないと思う
318: 2019/09/15(日)23:50 ID:jdtp5u68(2/2) AAS
>>316
VSは使ってるよ、昔は無料のエディションには
MFCもリソースエディタも付いてなかったからな
趣味でやってるから問題なし
フリーのリソースエディタを入れるか迷ったこともあったけど
直叩きで行けるしまあいいかと
319: 2019/09/16(月)00:47 ID:iDbWACrZ(1) AAS
それぐらい普通、何でもないよ
俺なんかメニューバーとかスクロールバーとかツールバーとかリストビューとか
こまごましたUIパーツ、全部DirectXで一からフルスクラッチで書いたし
4K画面だとリストビューとか動作がカクカクになるから使い物にならんよ
フォントの描画が重いみたい
320: 2019/09/16(月)00:49 ID:B+hfHu5+(1) AAS
結構前からリソースエディタは無料版VSでも入ってたろ
321(1): 蟻人間 ◆T6xkBnTXz7B0 2019/09/16(月)01:47 ID:cPhlmIua(1/4) AAS
後世のために書いておくが、Visual StudioのリソースコンパイラーはUTF-8の扱いに致命的なバグがあって、最悪の場合、文字化けする。あれはANSIコードページかUTF-16で使うものだ。
322: 2019/09/16(月)10:51 ID:7yboD6Fj(1) AAS
不定期
外部ﾘﾝｸ:stefansundin.github.io
323: 2019/09/16(月)12:37 ID:IB1jvVpV(1) AAS
>>321
コンパイラーの問題だからエディターは何でもいいんじゃね
って話ではないの？
324: 2019/09/16(月)17:55 ID:+LXKkUCe(1) AAS
そもそもリソースファイルにUTF8が使えるなんて知らなかったわ
325: 2019/09/16(月)17:57 ID:Y7LS5TKS(1) AAS
いや使えないでしょUTF-8
326: 蟻人間 ◆T6xkBnTXz7B0 2019/09/16(月)18:32 ID:cPhlmIua(2/4) AAS
MinGWのwindresというコンパイラーなら、pragmaでコードページ指定すればUTF-8が使える。
Visual Studioのrcは前述の通りUTF-8読み込みにバグがある。
327: 2019/09/16(月)18:40 ID:OCMqZYFH(1/2) AAS
RisohEditorってどうなん
328: 蟻人間 ◆T6xkBnTXz7B0 2019/09/16(月)18:43 ID:cPhlmIua(3/4) AAS
RisohEditorはUTF-8とUTF-16のソースが扱える。UTF-16の入力は、独自のプリプロセッサでUTF-8に変換している。
329: 蟻人間 ◆T6xkBnTXz7B0 2019/09/16(月)18:46 ID:cPhlmIua(4/4) AAS
VSのRCの文字化けバグについては
外部ﾘﾝｸ[html]:developercommunity.visualstudio.com
こちらで。まだ直っていない。
330: 2019/09/16(月)18:52 ID:OHfOAVfs(1) AAS
リソースファイルはBOMつきUTF-16LEでいけるでしょ。
331(1): 2019/09/16(月)19:26 ID:dTSbudTn(1/2) AAS
重箱。UTF-16LE/BEと呼ぶ場合はBOMを付けてはならないらしい。
332: 2019/09/16(月)19:56 ID:OCMqZYFH(2/2) AAS
UTF-8 も BOM 付けちゃいけないんだろ
333: 2019/09/16(月)20:21 ID:dTSbudTn(2/2) AAS
UTF-8なら禁止はされていない。
334: 2019/09/17(火)00:30 ID:J+q8D2Xe(1/2) AAS
>>331
理解が間違っている。
「BOMつきUTF-16LE」と「UTF-16LE」は別のものであり、どちらも存在する。
「UTF-16LE」にBOMがついていないからこそ「BOMつきUTF-16LE」という表現が成り立つ。
小倉トーストとトーストが別のものであることと同じであり、トーストに小倉餡がついていないからこそ小倉トーストが成り立つ。
335: 2019/09/17(火)02:12 ID:GJd5TLi7(1) AAS
粒餡と餡子が別のものであることと同じであり、
餡子に粒が入ってないからこそ粒餡が成り立つ
ってことですね
336: 2019/09/17(火)02:53 ID:J+q8D2Xe(2/2) AAS
名古屋のモーニングにゆで卵がついたからといって、モーニングでなくなるわけではないのだ。
無論、ゆで卵がつかないモーニングもある。ゆで卵がつこうがつくまいがモーニングなのだ。
337: 2019/09/17(火)03:09 ID:F6p74H2h(1) AAS
名古屋とか言う異世界の話はやめようぜ
意味が分からん
338: 2019/09/17(火)18:03 ID:IoM9hprN(1) AAS
名古屋が4次元？
339: 2019/09/17(火)18:08 ID:+bGUkqkJ(1) AAS
みそかつ
みそ煮込みうどん
高血圧
340: 2019/09/17(火)18:36 ID:TzGpBMAj(1) AAS
段ボール入り肉まんが人によってはバレないが、やはり人間的にはエラーが出やすい
そういうことだな
341(1): 2019/09/18(水)14:01 ID:+0ud2Fjw(1/6) AAS
Caretの点滅間隔について質問です
自アプリがアクティブの時のみ点灯(点滅間隔にUINT_MAXを指定して擬似的に)
自アプリが起動中はWM_SETFOCUSでON(点灯)に、WM_KILLFOCUSでOFF(元の間隔)にする事はできましたし他のアプリにも影響はありません
ですが自アプリが終了したら他のアプリでもONの状態になってしまいます
メッセージを追ってみると
WM_CLOSEでDestroyWindow
→WM_KILLFOCUSでOFFへ
→プロセスが終了
になっていたので自アプリ内で再度ONになっている事はないです
これはどういう事ですか？
342: 2019/09/18(水)19:04 ID:L8SHYgAR(1) AAS
WM_CLOSE
→DestroyWindow (hWnd 失効)
→WM_KILLFOCUSでOFFへ (hWnd 違いで無視)
→プロセスが終了
かな
知らんけど
343: 2019/09/18(水)19:30 ID:+0ud2Fjw(2/6) AAS
ありがとうございます
引数は間隔のみですが一応DestroyWindow直前でOFFにしてみても同じ結果でした
344: 2019/09/18(水)19:31 ID:Dukdxvvo(1/4) AAS
完成品には道のり遠くｗ
345: 2019/09/18(水)19:37 ID:+0ud2Fjw(3/6) AAS
Getで値を見てみるとONの状態になってしまうのではなく
アプリが終了したら間隔が0xfeeefeeeになってしまう
でした
言い直しますと
System設定の500(ミリ秒)からUINT_MAXではなく200へ変更するようにしても
アプリを終了したら間隔が0xfeeefeeeになってしまう
です
346: 2019/09/18(水)19:39 ID:Dukdxvvo(2/4) AAS
たまねぎスレｗ
347(2): 2019/09/18(水)19:57 ID:u5s3196f(1/3) AAS
方法は何でもいいけど、例えばクリックしたらキャレット処理を終了→その後アプリ終了でどうなるかやってみ
問題が絞り込めるでしょ
WM_CLOSEで終了処理が思ったように動いてないってのはありがち
348: 2019/09/18(水)20:00 ID:Dukdxvvo(3/4) AAS
はい完成品なしｗ
349: 2019/09/18(水)20:07 ID:+0ud2Fjw(4/6) AAS
>>347
それも既に試しましたが同じ結果です
>>341でも書きましたがメッセージを追ってWM_CLOSEが正常な事も確認済みです
350: 2019/09/18(水)20:10 ID:Dukdxvvo(4/4) AAS
はいBASICからやり直しｗ
351: 2019/09/18(水)20:10 ID:+0ud2Fjw(5/6) AAS
>>347
途中送信すみません
設定してもいない値0xfeeefeeeになるので
間隔はSystemと同じ値(500)にSetするだけにしてみても同じ結果でした
352(1): 2019/09/18(水)20:12 ID:rjYHNvyN(1/3) AAS
0xfeeeってデバッグの時の初期化されてない奴の値じゃないっけ
終了時に数値の参照先おかしくなってるとかかな
353(2): 2019/09/18(水)20:31 ID:VIgnmm9s(1) AAS
「あなたのアプリがWM_CLOSEで0xfeeefeeeにしてる」のは明白でしょ
0xfeeefeeeって特別な値よ、ググってみそ
354(1): 蟻人間 ◆T6xkBnTXz7B0 2019/09/18(水)20:50 ID:d3y9L0GY(1) AAS
DestroyCaretしてないとか？
355(2): 2019/09/18(水)20:51 ID:doMp/Sm3(1) AAS
DEBUGビルドのランタイムで
newからのdelete や malloc からの free の後に 確保領域の内容を0xfeee で埋める
ポインタを開放した後に指し先の内容値を取得し、セットしちゃってるんでないの？
356(1): 2019/09/18(水)20:51 ID:nSTUFOvJ(1) AAS
速度設定するとこにトレース出力でもおいて、まずはほんとに意図しないタイミングで呼ばれてないのかチェックだな
357(1): 2019/09/18(水)20:54 ID:GIOjMe2C(1) AAS
イベントを2回通っていて、認識できてないとか。
358(1): 2019/09/18(水)21:32 ID:+0ud2Fjw(6/6) AAS
>>353
キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました
>>354
してもしなくても同じ結果になります
>>355
値の指定をハードコードにしても同じでした
>>356-357
重複した呼び出しなども無かったです
359: 2019/09/18(水)21:52 ID:8Lx1p1Xb(1) AAS
Releaseモードで検証したら
360: 2019/09/18(水)21:58 ID:rjYHNvyN(2/3) AAS
別のとこでメモリ壊してるんかな
その部分だけの最小コード書いてみては
それでもなるなら手に負えない感じが
361(1): 2019/09/18(水)22:24 ID:Ei+Tp6td(1) AAS
>>352-353 >>355
0xfeee なんてパターンあったっけ？
0xFDFDFDFD No man's land (normally outside of a process)
0xDDDDDDDD Freed memory
0xCDCDCDCD Uninitialized (global)
0xCCCCCCCC Uninitialized locals (on the stack)
の４パターンしか知らんかったわ
外部ﾘﾝｸ:docs.microsoft.com
362: 2019/09/18(水)22:31 ID:rjYHNvyN(3/3) AAS
なかったっけ
うろ覚えで書いたから間違ってたかな
363(1): 2019/09/18(水)22:48 ID:u5s3196f(2/3) AAS
0xfeeefeeeでググれ
364: 2019/09/18(水)22:51 ID:u5s3196f(3/3) AAS
>>358
> キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
> WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました
マウスクリックで終了してる「はず」なのに終了してないなら、そもそもキャレット処理を
全く走らせてなくても問題が再現する「はず」
でもその場合は問題ないってなら、やはり終了処理に何かある
365(1): 2019/09/19(木)04:56 ID:WgtBHfjG(1/3) AAS
>>363
お前がググれよw
366(2): 2019/09/19(木)08:37 ID:55mEbAq6(1/2) AAS
>>361
new -> delete -> 値が0xfeeefeeeに
もしnewしたクラスのメンバ変数が値を保持して間隔設定してるなら
delete後に0xfeeefeeeなるよ
クラスポインタをdeleteしてからNULLにしたらエラーになるはず
こんな感じじゃないかな
WM_CLOSEで(deleteしてから)DestroyWindow (クラスポインタとメンバ変数の値が0xfeeefeeeに)
→WM_KILLFOCUSでOFFへ (OFFにする時に参照してるメンバ変数が0xfeeefeee)
→プロセスが終了
でもハードコードでもなるみたいだから違うかも？
367(1): 2019/09/19(木)09:42 ID:BhEGNWlU(1/2) AAS
unix の pipe は双方向だと思うのですが
win32api の pipe (namedpipe ではない方) は一方通行なんでしょうか？
先生なんとかなりませんか？
368: 2019/09/19(木)09:45 ID:VunEY3BQ(1/3) AAS
WM_CLOSE
↓
WM_DESTROY
369: 2019/09/19(木)09:51 ID:VunEY3BQ(2/3) AAS
ああ
WM_QUIT
かな
370: 2019/09/19(木)10:17 ID:nEj2AKuG(1) AAS
>>367
UNIXも一方通行では
371(1): 2019/09/19(木)10:35 ID:WgtBHfjG(2/3) AAS
>>366
間隔設定がよくわからんが
class C { int a; };
auto x = new C();
delete x;
ってやるとxのポイント先が0xddddddddになるんだが…
Visual Studio Express 2017, 15.9.16
372: 2019/09/19(木)12:34 ID:WgtBHfjG(3/3) AAS
>>366
書き忘れたけど当然デバッグビルドな
ついでにライブラリのソース追っかけたけどパターンはバイト単位に設定されてるので0xfeeeなんてパターンは無いと思うよ
373(1): 2019/09/19(木)16:05 ID:NIaCYNJC(1/3) AAS
>>365
どこのgoogle使ってんの？
＞0xfeeefeee を検索するとHeapFree で処分された後のヒープ領域がこの値で埋められている、とわかる。 ということは「処分済みヒープへのポインタを誰かが使っている」ということだ。
なお、正解かどうかは論じてないので悪しからず
374: 2019/09/19(木)16:41 ID:cbyVF/Zh(1) AAS
解放バッファの埋めパターンは、ライブラリが自力でセットするものなの？
375: 2019/09/19(木)17:15 ID:BhEGNWlU(2/2) AAS
-D_DEBUGで自動化やろ
376(2): 2019/09/19(木)18:06 ID:NIaCYNJC(2/3) AAS
とりあえず>>373の検証
100バイトHeapAllocして適当にa~zの文字書き込んでHeapFreeの前後でダンプ取ったけど、
0xfeeefeeeが入ることはなかったな
debug版
前
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
後
F0 C6 42 05 88 41 47 05 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
release版
前
省5
377: 2019/09/19(木)18:13 ID:VunEY3BQ(3/3) AAS
コンパイラによっても違うのか
外部ﾘﾝｸ[html]:www.nobugs.org
378: 2019/09/19(木)18:42 ID:NIaCYNJC(3/3) AAS
APIだからコンパイラ関係ないと思うけどね
OSは8.1だけど
コンパイラというかライブラリが関係するはずのmallocでやってみた
vs2017 - ツールセットvs2013（詳細略）
以下並びは>376と同じだけどダンプの長さはa~zの26+1バイトじゃなく30バイト
allocも100ではなく30バイト
debug
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00 CD CD CD
DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD
release
省2
379(1): 2019/09/19(木)19:23 ID:55mEbAq6(2/2) AAS
>>371
間隔設定はキャレットのね
こっちでは0xfeeefeeeになるね
画像ﾘﾝｸ[jpg]:i.imgur.com
380(1): 2019/09/19(木)22:12 ID:1bu8PAPD(1) AAS
>>379
環境は？
十数バイトをdeleteしただけでHeapFreeを呼ぶのも考えづらいし、そもそもこっちでも>>376と同じくHeapFreeで0xfeeefeeeが入ることもなかった
381: 2019/09/19(木)22:36 ID:2Kmv27QM(1) AAS
vs2003とかそのあたりかなこれ
382: 2019/09/20(金)00:25 ID:n3bycm/n(1) AAS
Win10 Pro(32bit)でHeapFreeやってみた
VS2017(Community Edition)は0xfeeefeeeにならなかったが、
VC2010(Express Edition)でやってみたら0xfeeefeeeになったわ(確保していた領域の先頭8バイトほどに0xfeeefeeeじゃない値が入っていたが)
面倒だからオプションとか生成されたバイナリとか詳しく比較してない
383: 2019/09/20(金)09:31 ID:DNSz8VRz(1) AAS
>>380
VC++2010Expressだよ
画像こっちの方がよかったね
画像ﾘﾝｸ[jpg]:i.imgur.com
384(1): 2019/09/28(土)11:23 ID:2Q8qxITa(1) AAS
メッセージ処理の
case（msg）
ってなんで
case（msg.message）
じゃないの？
構造体直接評価できるの？
385: 2019/09/28(土)11:29 ID:2Q7OqYnQ(1) AAS
どこかのサイト？
386: 2019/09/28(土)11:46 ID:QstsG7m2(1/2) AAS
メッセージは構造体じゃなくて UINT やろ
387(1): 2019/09/28(土)14:28 ID:hWveUl7z(1) AAS
>>384
多分サンプルの読み方を勘違いしている
GetMessage関数なんかで使われるlpMsgとかはMSG構造体なので中でメッセージIDを
確認したいならば「msg.message」を見ることになる
メッセージIDのハンドリング行うサンプルなんかで普通に使われてるWndProc関数の
uMsgはUNIT型の「msg.message」が実体なのでcaseでそのままハンドリングできる
でないか？
388: 2019/09/28(土)16:13 ID:91yg28/R(1) AAS
caseにカッコつけんな
389(1): 2019/09/28(土)17:54 ID:zcWtf1aP(1) AAS
本来ライブラリに任せるべきところをかなりネイティブなwinsockプログラミングをしています。
TCP通信にて最大セグメントを超えてwinsock2.sendを行った場合はどうなってしまうのでしょうか？
エラーとなるためそこも自前で実装する必要があるのか、それともwinsockが勝手に分割を行ってくれるのか、はたまたネットワークアダプタやルーターなどのデバイスが勝手にやってくれるのか、どういう挙動となるのかご伝授お願いします
390: 2019/09/28(土)20:46 ID:QstsG7m2(2/2) AAS
ソケット通信てそんなところ気にしなきゃいけなかったっけ？
アップロード・ダウンロードルーチン組んだけど記憶にない
391: 2019/09/28(土)21:19 ID:qwUCk4Gy(1) AAS
winsock2に限ればエラーが返るんじゃないか？
質問するよりもmasdn見たほうが確実だろ
392(2): 2019/09/28(土)21:42 ID:zNn3MVf2(1) AAS
sizeof演算子に括弧つける派です？
393(1): 2019/09/28(土)22:22 ID:ZZfYVsnP(1/2) AAS
UDPだと知らん間に分割された挙句
場合によっては断片が届く順番まで変わるからな
394: 2019/09/28(土)22:24 ID:ZZfYVsnP(2/2) AAS
sizeofに括弧付ける
マクロの引数は使用時に必ず括弧付ける
395: 2019/09/29(日)08:10 ID:qdFsd7WD(1/2) AAS
>>393
> 場合によっては断片が届く順番まで変わるからな
むしろTCPが頑張って順序を元通りに入れ替えてるんだが…
396: 2019/09/29(日)08:12 ID:qdFsd7WD(2/2) AAS
>>392
不要なカッコは付けない派
例外は演算子の優先順位がわかりにくい時に付けるぐらい
理由は間違っててもコンパイルエラーにならないから
397: 2019/09/29(日)08:26 ID:MP9GBJ11(1/8) AAS
>>392
俺も無駄な括弧はつけないな
わざわざつける理由がない
単項演算子の優先順位を知らんアホが仲間にいない
398: 2019/09/29(日)09:39 ID:xMtED3Cu(1) AAS
どこから「単項」演算子の話が…
399: 2019/09/29(日)10:26 ID:MP9GBJ11(2/8) AAS
そのアホがいた・・・驚愕
今 sizeof の話をしているんだが
脈絡が読めないとはな
400(1): 2019/09/29(日)10:29 ID:JKK19nEu(1) AAS
こういう奴が書くソースは総じて読みにくいｗ
上下前次1-新書関写板覧索設栞歴
あと 602 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.044s