Win32API質問箱 Build125
■ このスレッドは過去ログ倉庫に格納されています
1.0.0.01
1.0.0.011
1.0.0.0111
1.0.0.01111 >>271
> 1.0.0.1とかはあかんの？
やっぱりこれが妥当なんですかね。
他のアプリのベータ版も見てみたいとは思うのですが。
秀丸エディタは、ベータ版は4桁目を増やし続けて、リリース版には99を入れてました。
1.1.0.99が1.1.0のリリース版という法則でした。
> 1.1.0.α
> 1.0.0.01
FILEVERSIONやPRODUCTVERSIONには、αや01は入力できないです。
必ず4つの数字を入れないと、勝手に0が入ってしまいますし。 昔、同僚にクラス設計やコメントの書式にやたら拘る奴がいたの思い出した
綺麗なソースコード書いてたけど、まったく動かないゴミですぐ職場から消えたわｗ そういう人って恋人も見た目重視にしてそう
ソースコード(見た目)って意味で >>276
所詮決め事なんで>>272の言うとおり好きにしてくださいって話だけど
良くありがちなのは
メジャーバージョン．マイナーバージョン．ビルドバージョン
みたいな
メジャーバージョンはアーキテクチャとかUIの大きな変更とかユーザから見ても
変更されたことが分かるような場合
マイナーバージョンは単機能追加とかバグ修正などユーザから一見分からない
ような軽微な変更の場合
ビルドバージョンは作業途中の状態を管理するための連番や単一作業の区切りを
管理するための連番とか
みたいな感じで自分で目的を決めて使うしかないよ
他には作業の効率管理のためにさらにビルド回数を最後に付けてコンパイルする
たびに番号加算していくとか
後はOSのバージョンごとにパッキングを変える場合はPRODUCTOVERSIONと
FILEVERSIONを関連性は持たせるけど個別に管理するとか
>>273
あれは企業的に仕事をしてますよアピールなので残念なのは経営層か
投資家かな
バグ修正はマイナーバージョン、それ以外はすべてメジャーバージョンの修正に
することですごくたくさん仕事してますよがアピールできるので >>273 さんはそんなこと言われなくても判ってて書いてるだろ INVALID_HANDLE_VALUEってマジで糞だよな
うっかりしてると失敗したときNULLが返ってくるって勘違いするというか
ボーッとしてるとそういうコード書いちまうことがある
大概のAPIでは失敗したときNULLが返ってくるってのもある
混在いやん あと、なんでINVALID_HANDLE_VALUEが必要になったのか技術的な背景が気になる
普通に0を返しとけばいいじゃん、って思うよね
他のAPIがそうなってるんだから
謎 >>281
どんなAPIでも最低限の仕様確認してから使えよ しかしそれらを超越した次元で総合的に判断してやっぱりINVALID_HANDLE_VALUEは糞
必要ないからな >>284
それは論点が違う
マジで糞かどうかだろうが
285はちゃんと自分なりの見解を言っているし
286は情報提供している
お前だけとかくだらんことしか言わんボーガスとは次元が違う
16bit時代は低コストに拘るあまり
色々とアホなことをしていた
その名残を糞って言えないやつも糞だ ComboBoxはCB_ERRがある
ListBoxはLB_ERRがある
ListViewはただの-1で定義無し
LV_ERRじゃないのはなんで？ >>286読んで思い出したが
そうそうHANDLEのスマポ作るときにウザいんだよな
既定の初期値を何にしておくかって問題があるからな！
ああ糞だ 後HANDLEのスマポのデストラクタでCloseHandleするとき
失敗したり何も入ってなかったり
無効なハンドルの場合はCloseHandleしないようにする場合も嫌らしい
無効なハンドルを表す値が二つ有るからな！！
if( handle && handle != INVALID_HANDLE_VALUE ){ ::CloseHandle( handle ); }
と書いてしまいたいところだが、本当にこれでよいのか？
それかCloseHandleに無効なハンドルを渡したときは何もしないことを期待して
if文なしで単に::CloseHandle( handle );とだけ書くか
しかしCloseHandleに無効なハンドルを渡したときの動作はMSDNには書かれてないんだよな
まぁ何もしないと思うが ああ今調べたら、CloseHandleに無効なハンドル渡したら
GetLastErrorが汚染されるらしいな 初期化と開放とかのインターフェース作って、そのインターフェース派生でAPIアクセスしてるな
その手のはAPI直接叩くソース書くと後からコーディングミスに気付いても修正困難になるしバグの元 >>288
前者2つはOS基本機能、後者はコモンコントロールというオプション
という違いから歴史と立ち位置が違う
ついでに言えば設計から全然違うんで、定義がないのは不思議ではない どれもコモンコントロールだよ
歴史的には昔はリストビューがコモンコントロールじゃなかったかもしれないが分からない 昔のWindowsAPIはHANDLEとポインタが別物だったのを知らん人がいるのか >>288
ポインタが奇数になるはずはない(キリっ
だから奇数の空間を全て別のオブジェクトに
おれ天才じゃね？って糞言語が日本にはある フリーのリソースエディタとAPIでGUIプログラムを作っているけど、
もう時代遅れなのかな。
みなさんは、GUIプログラムはどうやって作っていますか。 リソースエディタなんぞ使わず全部apiからテキストエディタ上で
数値指定で作ってるんでそんな自分よりかは進んでるぞ
まあ今の時代ならvisual studio使うのが普通だろうね >>297
cygwin/mingw64 でコンパイル・リンクできるよう、リソースは手書きですね… 俺は自作のリソーエディタ使ってるけど。MinGWでもVC++でもビルドできるよ。 >>294
コモンかどうか名前はさておき、リストビューは明確にcomctl32を使うような
宣言とリンクがないと使えないでしょ
リストもコンボはこいつの範疇ではない WinUser.h
ComboBox CB_ERR
ListBox LB_ERR
CommCtrl.h
ListView関係のメッセージやマクロ
この違いは歴史関係って事？
LVM_INSERTITEMが失敗した場合は-1が返るけど
LV_ERR(-1)とするのはおかしい？ Windowsで.NET使わずにC/C++とWin32APIでPerl互換の正規表現を使ったプログラムを作る場合、
従来はboost::regexやPCREなど別途ライブラリが必要だったけど、Windows10以降はICUの正規表現を使えるようになった。
ただし、可変長文字列を扱うUnicodeStringクラスがヘッダーファイルicu.hから削除されているので、std::wstringなどで代替する必要がある。 ListViewはWindows95で追加されたコントロール 昔の事は多少は多目に見てやれよ。今みたいにSNSが活発じゃないし、githubで他人のソースも簡単に見れるわけしゎゃない。知見を共有しづらい時代なんだから ハンガリアン記法自体はBug捕り等に有効だったのに Standard Control
Common Control >>309
システムハンガリアンは違うし、なんで過去形なんだ？ unix の execlp だと pid は変化しませんが、
Win32API の execlp とか _execlp とかだと processID は変化してしまうようです。
CreateProcess が呼ばれているからだと思いますが、
Win32API の execlp とか _execlp とかで変わったあとの processID を知る方法はありますか？
(起動された側で getpid() で判るのですが、そっちではなくて元の processID を握ってる方からのリンクが切れて困ってます。) >>297
俺はリソーススクリプト直叩き
MSDNに詳しい情報乗ってるし、英語だけど
プログラマなら大体わかるよ、翻訳サイトを使ってもいいしね
そして、ライブラリ化しといて次から簡単に使えるようにしとく
バージョン情報とかも関数やクラスにして簡単に使えるようまとめとけば便利
GUIは.NETがクラス化の良いお手本になるよ >>314
> Win32API の execlp とか _execlp
そもそもexeclpとかはwin32apiじゃなくて単なるライブラリだよ
とりあえずざっとソース見る限りではpidを返す方法はないみたい（インターフェースもないしね）
自分で実装するしかないと思う >>316
VSは使ってるよ、昔は無料のエディションには
MFCもリソースエディタも付いてなかったからな
趣味でやってるから問題なし
フリーのリソースエディタを入れるか迷ったこともあったけど
直叩きで行けるしまあいいかと それぐらい普通、何でもないよ
俺なんかメニューバーとかスクロールバーとかツールバーとかリストビューとか
こまごましたUIパーツ、全部DirectXで一からフルスクラッチで書いたし
4K画面だとリストビューとか動作がカクカクになるから使い物にならんよ
フォントの描画が重いみたい 結構前からリソースエディタは無料版VSでも入ってたろ 後世のために書いておくが、Visual StudioのリソースコンパイラーはUTF-8の扱いに致命的なバグがあって、最悪の場合、文字化けする。あれはANSIコードページかUTF-16で使うものだ。 >>321
コンパイラーの問題だからエディターは何でもいいんじゃね
って話ではないの？ そもそもリソースファイルにUTF8が使えるなんて知らなかったわ MinGWのwindresというコンパイラーなら、pragmaでコードページ指定すればUTF-8が使える。
Visual Studioのrcは前述の通りUTF-8読み込みにバグがある。 RisohEditorはUTF-8とUTF-16のソースが扱える。UTF-16の入力は、独自のプリプロセッサでUTF-8に変換している。 リソースファイルはBOMつきUTF-16LEでいけるでしょ。 重箱。UTF-16LE/BEと呼ぶ場合はBOMを付けてはならないらしい。 >>331
理解が間違っている。
「BOMつきUTF-16LE」と「UTF-16LE」は別のものであり、どちらも存在する。
「UTF-16LE」にBOMがついていないからこそ「BOMつきUTF-16LE」という表現が成り立つ。
小倉トーストとトーストが別のものであることと同じであり、トーストに小倉餡がついていないからこそ小倉トーストが成り立つ。 粒餡と餡子が別のものであることと同じであり、
餡子に粒が入ってないからこそ粒餡が成り立つ
ってことですね 名古屋のモーニングにゆで卵がついたからといって、モーニングでなくなるわけではないのだ。
無論、ゆで卵がつかないモーニングもある。ゆで卵がつこうがつくまいがモーニングなのだ。 名古屋とか言う異世界の話はやめようぜ
意味が分からん 段ボール入り肉まんが人によってはバレないが、やはり人間的にはエラーが出やすい
そういうことだな Caretの点滅間隔について質問です
自アプリがアクティブの時のみ点灯(点滅間隔にUINT_MAXを指定して擬似的に)
自アプリが起動中はWM_SETFOCUSでON(点灯)に、WM_KILLFOCUSでOFF(元の間隔)にする事はできましたし他のアプリにも影響はありません
ですが自アプリが終了したら他のアプリでもONの状態になってしまいます
メッセージを追ってみると
WM_CLOSEでDestroyWindow
→WM_KILLFOCUSでOFFへ
→プロセスが終了
になっていたので自アプリ内で再度ONになっている事はないです
これはどういう事ですか？ WM_CLOSE
→DestroyWindow (hWnd 失効)
→WM_KILLFOCUSでOFFへ (hWnd 違いで無視)
→プロセスが終了
かな
知らんけど ありがとうございます
引数は間隔のみですが一応DestroyWindow直前でOFFにしてみても同じ結果でした Getで値を見てみるとONの状態になってしまうのではなく
アプリが終了したら間隔が0xfeeefeeeになってしまう
でした
言い直しますと
System設定の500(ミリ秒)からUINT_MAXではなく200へ変更するようにしても
アプリを終了したら間隔が0xfeeefeeeになってしまう
です 方法は何でもいいけど、例えばクリックしたらキャレット処理を終了→その後アプリ終了でどうなるかやってみ
問題が絞り込めるでしょ
WM_CLOSEで終了処理が思ったように動いてないってのはありがち >>347
それも既に試しましたが同じ結果です
>>341でも書きましたがメッセージを追ってWM_CLOSEが正常な事も確認済みです >>347
途中送信すみません
設定してもいない値0xfeeefeeeになるので
間隔はSystemと同じ値(500)にSetするだけにしてみても同じ結果でした 0xfeeeってデバッグの時の初期化されてない奴の値じゃないっけ
終了時に数値の参照先おかしくなってるとかかな 「あなたのアプリがWM_CLOSEで0xfeeefeeeにしてる」のは明白でしょ
0xfeeefeeeって特別な値よ、ググってみそ DEBUGビルドのランタイムで
newからのdelete や malloc からの free の後に 確保領域の内容を0xfeee で埋める
ポインタを開放した後に指し先の内容値を取得し、セットしちゃってるんでないの？ 速度設定するとこにトレース出力でもおいて、まずはほんとに意図しないタイミングで呼ばれてないのかチェックだな >>353
キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました
>>354
してもしなくても同じ結果になります
>>355
値の指定をハードコードにしても同じでした
>>356-357
重複した呼び出しなども無かったです 別のとこでメモリ壊してるんかな
その部分だけの最小コード書いてみては
それでもなるなら手に負えない感じが >>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)
の４パターンしか知らんかったわ
https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-6.0/aa260966(v=vs.60)#what-exactly-do-you-mean-by-failure >>358
> キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
> WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました
マウスクリックで終了してる「はず」なのに終了してないなら、そもそもキャレット処理を
全く走らせてなくても問題が再現する「はず」
でもその場合は問題ないってなら、やはり終了処理に何かある >>361
new -> delete -> 値が0xfeeefeeeに
もしnewしたクラスのメンバ変数が値を保持して間隔設定してるなら
delete後に0xfeeefeeeなるよ
クラスポインタをdeleteしてからNULLにしたらエラーになるはず
こんな感じじゃないかな
WM_CLOSEで(deleteしてから)DestroyWindow (クラスポインタとメンバ変数の値が0xfeeefeeeに)
→WM_KILLFOCUSでOFFへ (OFFにする時に参照してるメンバ変数が0xfeeefeee)
→プロセスが終了
でもハードコードでもなるみたいだから違うかも？ unix の pipe は双方向だと思うのですが
win32api の pipe (namedpipe ではない方) は一方通行なんでしょうか？
先生なんとかなりませんか？ >>366
間隔設定がよくわからんが
class C { int a; };
auto x = new C();
delete x;
ってやるとxのポイント先が0xddddddddになるんだが…
Visual Studio Express 2017, 15.9.16 >>366
書き忘れたけど当然デバッグビルドな
ついでにライブラリのソース追っかけたけどパターンはバイト単位に設定されてるので0xfeeeなんてパターンは無いと思うよ >>365
どこのgoogle使ってんの？
＞0xfeeefeee を検索するとHeapFree で処分された後のヒープ領域がこの値で埋められている、とわかる。 ということは「処分済みヒープへのポインタを誰かが使っている」ということだ。
なお、正解かどうかは論じてないので悪しからず ■ このスレッドは過去ログ倉庫に格納されています
