Win32API質問箱 Build125

**デフォルトの名無しさん** · 2019/02/27(水) 15:09:08.64

Win32APIについての質問はこちらへどうぞ。

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

■過去スレ
Win32API質問箱 Build124
http://mevius.5ch.net/test/read.cgi/tech/1510395780/
Win32API質問箱 Build123
http://mevius.2ch.net/test/read.cgi/tech/1475897582/
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/
Win32API質問箱 Build121
http://echo.2ch.net/test/read.cgi/tech/1438695290/
Win32API質問箱 Build120
http://echo.2ch.net/test/read.cgi/tech/1428570962/

■関連スレ
Visual Studio 2019
http://mevius.5ch.net/test/read.cgi/tech/1548765663/
Visual Studio 2017 Part6
http://mevius.5ch.net/test/read.cgi/tech/1528645068/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】
http://mevius.5ch.net/test/read.cgi/tech/1521786252/

**デフォルトの名無しさん** · 2019/09/05(木) 11:23:33.11

それは対応表作るにしても結構苦労するよ
例えば俺のWin10のユーザフォルダの中を見ると
同じフォルダ内にドキュメント、と、ピクチャ、が二つずつあったりする
ディスプレイネームが同じでITEMIDLISTが違うアイテムが
同一フォルダに複数存在してたりする環境もあるって事
俺の場合は片方はOneDriveでもう一つはローカル用
同じ名前で同じフォルダ
だから単にドキュメントといってもどっちの事か分からんwwwという事態に
苦労するよ、それ

**デフォルトの名無しさん** · 2019/09/05(木) 11:28:46.02

てか、同じ名前のアイテムを同一フォルダに突っ込むWindowsが糞仕様なんだけど
普通に使う分にもどっちがどっちか分からんでムカつく
OneDriveの方は「ドキュメント(OneDrive)」とか区別付く名前にしとけよ
それかOneDriveっていうフォルダ掘ってその下に配置しろよ
同じ名前のアイテムが同じフォルダにあると混乱することぐらい分かるだろ糞

**デフォルトの名無しさん** · 2019/09/05(木) 12:28:53.83

独り言はチラ裏へ

**デフォルトの名無しさん** · 2019/09/05(木) 12:29:13.60

アクセス履歴見ながら対応表を順次変更すりゃいい
そういうのはアイデア次第でどうとでもなる

**デフォルトの名無しさん** · 2019/09/05(木) 12:30:06.05

>>249
レスどうもありがとうございます。
他の方のレスを拝見してみても、やっぱりなかなか難しそうですね。

>>250
大変有用な情報どうもありがとうございます。この方針が一番現実的そうですね。
SHGetSpecialFolderLocation/SHGetSpecialFolderPath は
CSIDL しか受け付けなくて、「3D オブジェクト」のように CSIDL がないフォルダもあるので、
CSIDL の代わりに GUID が使える SHGetKnownFolderIDList を使おうと思います。
ただいずれにしても、どのフォルダの CSIDL/GUID を指定するかは
プログラムの段階で決めないという認識で正しいでしょうか？
その部分を自動で決められれば最高なのですが難しそうですね。
あと、日本語名を取得するのに SHGetLocalizedName を紹介していただきましたが、
SHGetFileInfo を使うのとどちらがいいでしょうか？
SHGetFileInfo なら直接日本語名が得られるのに対して、SHGetLocalizedName だと
'the ID of the localized file name in the resource file' が返ってきますが、
こちらのほうがパフォーマンス的に有利だったりするのでしょうか？

>>251
貴重なご意見どうもありがとうございます。確かになかなか問題の根は深そうです。
エクスプローラーのアドレスバーはそのあたりをいい感じに解決しているようなので
その仕組みをそのまま拝借できたら楽なのですが、そう簡単には行かなさそうですね。

**デフォルトの名無しさん** · 2019/09/05(木) 12:39:12.77

>>252 >>254
レスどうもありがとうございます。
確かに Windows のフォルダ階層の仕組みは少し分かりにくいところがありますが、
今回の件についてはその問題はあまり関係なくて、
ちょっと誤解を与えてしまっている気がするので改めてやりたいことを説明させていただきます。

エクスプローラでは、今どのフォルダを開いているかにかかわらず、
アドレスバーに単に「デスクトップ」とだけ入力してエンターキーを押せばデスクトップに移動できます。
つまり、エクスプローラーの中では「デスクトップ」という単一の単語とデスクトップのフルパスとが
対応付けられているということになります。そして私は、この対応表を取得したいと考えております。

**デフォルトの名無しさん** · 2019/09/05(木) 13:04:18.60

質問です。

ファイルに関連付けされている実行ファイルパスを取得するのに
FindExecutable()やAssocQueryString()を使っているのですが、
一部関連付けが取得できません。

どうやら関連付け先の実行ファイルの種類がWindowsパッケージ（デスクトップ）版と
ストアアプリ版とでは動作が異なるらしく、パッケージ版は上記APIで取得できる
ようですがストアアプリ版は取得できないようです。

仕方がないのでレジストリを直接たどる方法を模索しているのですが、
パッケージ版は分かるのですがストアアプリ版がよく分りません。

自分で調べた限りでは、HKCR\{拡張子}\OpenWithProgidsのREG_NONE型の{名前}
を元に、HKCR\{名前}\ApplicationのApplicationNameまでたどればいいと
いう情報を見つけて実践してみました。が、

**デフォルトの名無しさん** · 2019/09/05(木) 13:05:00.53

（つづき）
実際に.pdfがedgeに関連付けられていて上記APIでは取得できない環境
においてレジストリをたどると
　\HKCR\.pdf\OpenWithProgids
のREG_NONE型の名前「AppXd4nrz8ff68srnhf9t5a8sbjyar1cr723」を元に
　\HKCR\AppXd4nrz8ff68srnhf9t5a8sbjyar1cr723\Application
のApplicationNameまではたどり着きました。

しかしこれに設定されている文字列が
　@{Microsoft.MicrosoftEdge_44.18362.329.0_neutral__8wekyb3d8bbwe?ms-resource://Microsoft.MicrosoftEdge/Resources/AppName}
となっています。
どう見ても実行パスではないというか、これをさらにどうにかするのか
たどる方法が間違っているのか分からなくなりました。

正しい方法をよろしくお願いします。

**デフォルトの名無しさん** · 2019/09/05(木) 13:11:24.93

>>256
試しにmspaintと入力してエンター押したらペイントが起動しない？
と言う事は入力が日本語ならC:\Users\<ユーザー名>\この中の対応するフォルダを開く
とか内部でやってるんじゃないかな

英語の場合はLoadLibraryと同じように
Explorer.exeと同じディレクトリ
Explorer.exeのカレントディレクトリ
システムディレクトリ
Windowsディレクトリ
環境変数のPATHに指定されてるディレクトリ
の順で検索されてmspaintが起動とか

**デフォルトの名無しさん** · 2019/09/05(木) 13:14:07.55

英語とか日本語とか関係なかったねｗ

**デフォルトの名無しさん** · 2019/09/05(木) 22:24:50.64

>>259
レスありがとうございます。お返事が遅くなってしまい申し訳ないです。

> 試しにmspaintと入力してエンター押したらペイントが起動しない？
本当ですね！
しかし一方で、C:\Users\＜ユーザ名＞\AppData というフォルダはあるのに
アドレスバーに AppData と入力してエンターを押しても期待通りの動作はせず、
なかなかルールは複雑みたいです。

また、日本語環境ではアドレスバーに「Desktop」と入力してエンターを押しても
期待される動作にはならず、「デスクトップ」でなければならないようなので、
やはりシステムの言語設定は関係あるように思われます。

SHGetFileInfo で取得できる displayName を調べれば
日本語環境ならデスクトップフォルダから「デスクトップ」という文字列が得られるので
その逆ができればいいかと思ったのですが、実際はそれほど簡単な問題ではないようです。

例えば私の環境では C:\Users\＜ユーザ名＞の displayName は
ウィンドウズの GUI から設定できる「ユーザ名（アカウント名）」になっていますが、
エクスプローラーのアドレスバーで期待通りの動作になる文字列は
「ユーザ名（アカウント名）」ではなく「フルネーム」でした。

エクスプローラーのアドレスバーの動作を完全に模倣するのは難しそうですが、
ここでいただいたアドバイスを元に、現実的な方法を考えていきたいと思います。

**蟻人間** ◆T6xkBnTXz7B0 · 2019/09/05(木) 22:38:16.11

レジストリにAppPathという設定もあるぞ。

**デフォルトの名無しさん** · 2019/09/06(金) 19:55:29.68

>>261
いくつか気付いた事を報告その1/2

・ユーザーフォルダ内のフォルダで移動できたもの
　アドレス帳
　お気に入り
　デスクトップ
　ドキュメント
　ピクチャ
　ビデオ
　ミュージック
仮説1 ～\<ユーザー名>\(日本語名で表示される一部のフォルダ)って条件なのかもしれない
仮説2 仮説1の一部のフォルダで法則があるとしたらレジストリで保存場所を変更できるフォルダではないか？
　　　　　試しに「プログラム」「スタートアップ」と入力しても移動できた
　　　　　レジストリの「HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders」
　　　　　ここに列挙されてるやつがヒントになるかもしれない
・レジストリをヒントに入力して移動できたもの
　プログラム
　recent
　sendto
　スタートメニュー
　スタートアップ
・その他で移動できたもの (ツリービューで日本語表記をヒントにした)
　パブリック
　コンピュータ
　ネットワーク
　コントロールパネル
　ごみ箱

**デフォルトの名無しさん** · 2019/09/06(金) 20:02:10.05

いくつか気付いた事を報告その2/2

・ここまでの間に気付いた事
アドレスバーに「コ」と入力すると
　コントロールパネル
　コンピュータ
　コンピュータの簡単操作センター
この3つの入力候補が現れたけど
入力候補が表示されるのとされないのもあった

あと日本語・英語混在(sendto recent)でさらに混乱させる事になってしまったかもしれないｗ

**デフォルトの名無しさん** · 2019/09/06(金) 20:40:37.12

ドキュメントがDocumentsの表示になった時の直し方で
LocalizedResourceNameが出てくるからそれをヒントにするのもいいかもしれない

**デフォルトの名無しさん** · 2019/09/06(金) 23:22:21.54

>>262
コメントどうもありがとうございます。
色々とレジストリにもヒントが隠れてそうなので調べてみたいと思います。

>>263-265
大変有用な情報どうもありがとうございます。
書いていただいた内容を見ながら実験してみて分かったこととして、
問題のアドレスバーの挙動は環境によって相当にブレがあるようです。

私の環境（Windows 10 Pro）では、
>>263 に書いていただいた文字列のうち
「recent」「コンピュータ（ちなみにコンピュータ『ー』もダメ）」は
期待通りの動作にならず、代わりにブラウザ（私の環境では Firefox）で
入力した文字列が検索されてしまいました。

私の環境ではアドレスバーに「Creative Cloud Files」と入力すると
対応する Adobe のソフトが作ったフォルダが開かれるので
ある程度外部ソフト等の影響があるだろうとは思っていたのですが、
「コンピュータ」ですら環境によって結果が異なるとは予想外でした。

ちなみに外部ソフトの影響に関しては、レジストリの
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace
に登録されているものが該当しているような気がするのですが、
確かなことは分かっていません。

ともあれ、非常に興味深い実験結果と考察を読ませていただき
大変勉強になりました。どうもありがとうございます。
また何かお気づきのことがあれば教えていただけると嬉しく思います。

**デフォルトの名無しさん** · 2019/09/07(土) 09:05:50.93

>>266
10の場合はコンピュータがPCに変わったんだと思う

**デフォルトの名無しさん** · 2019/09/07(土) 09:58:32.00

これはひどい

**デフォルトの名無しさん** · 2019/09/07(土) 13:40:15.53

デフォルトで用意されている日本語のフォルダ名を英語に戻す
https://laboradian.com/use-en-folder-name/

11個の日本語名になっているフォルダ

日本語名のフォルダには、desktop.ini という隠しファイルがある

**デフォルトの名無しさん** · 2019/09/12(木) 18:25:54.76

Win32アプリのバージョンリソースについての質問です。
自作アプリの1.0.0をリリースした後、1.1.0を作成中にベータ版を出す場合、
リソースのFILEVERSIONやPRODUCTVERSIONはどのように記述するのがよいのでしょうか。

1,1,0,0は、1.1.0の正式版に使いたいのですが、これより大きい値を付けるのも変だし、
数字以外の文字は入力できないようなので。

**デフォルトの名無しさん** · 2019/09/12(木) 19:23:34.97

1.0.0.1とかはあかんの？

**デフォルトの名無しさん** · 2019/09/12(木) 19:48:34.37

好きにしろよｗｗ
自作アプリなんて俺は1.0も1.1も2.0もみんなβだから1.00から0.01刻みで増やしてる
昔はカスタムビルドステップでビルド番号もつけてたけど今はやってない

**デフォルトの名無しさん** · 2019/09/12(木) 20:46:30.04

ちょろめとかふぃれふぉxはメジャーの数字上げ過ぎてひどいことになってるな
ばかなんですかね

**デフォルトの名無しさん** · 2019/09/13(金) 10:15:47.66

1.1.0.α
1.1.0.β
1.1.0.γ

**デフォルトの名無しさん** · 2019/09/13(金) 10:18:26.30

1.0.0.01
1.0.0.011
1.0.0.0111
1.0.0.01111

**デフォルトの名無しさん** · 2019/09/13(金) 11:29:05.95

>>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が入ってしまいますし。

**デフォルトの名無しさん** · 2019/09/13(金) 12:49:50.53

昔、同僚にクラス設計やコメントの書式にやたら拘る奴がいたの思い出した
綺麗なソースコード書いてたけど、まったく動かないゴミですぐ職場から消えたわｗ

**デフォルトの名無しさん** · 2019/09/13(金) 12:54:34.90

そういう人って恋人も見た目重視にしてそう
ソースコード(見た目)って意味で

**デフォルトの名無しさん** · 2019/09/13(金) 17:47:19.57

>>276
所詮決め事なんで>>272の言うとおり好きにしてくださいって話だけど
良くありがちなのは

メジャーバージョン．マイナーバージョン．ビルドバージョン

みたいな
メジャーバージョンはアーキテクチャとかUIの大きな変更とかユーザから見ても
変更されたことが分かるような場合
マイナーバージョンは単機能追加とかバグ修正などユーザから一見分からない
ような軽微な変更の場合
ビルドバージョンは作業途中の状態を管理するための連番や単一作業の区切りを
管理するための連番とか
みたいな感じで自分で目的を決めて使うしかないよ
他には作業の効率管理のためにさらにビルド回数を最後に付けてコンパイルする
たびに番号加算していくとか
後はOSのバージョンごとにパッキングを変える場合はPRODUCTOVERSIONと
FILEVERSIONを関連性は持たせるけど個別に管理するとか

>>273
あれは企業的に仕事をしてますよアピールなので残念なのは経営層か
投資家かな
バグ修正はマイナーバージョン、それ以外はすべてメジャーバージョンの修正に
することですごくたくさん仕事してますよがアピールできるので

**デフォルトの名無しさん** · 2019/09/13(金) 17:52:57.53

>>273 さんはそんなこと言われなくても判ってて書いてるだろ

**デフォルトの名無しさん** · 2019/09/13(金) 23:06:09.82

INVALID_HANDLE_VALUEってマジで糞だよな
うっかりしてると失敗したときNULLが返ってくるって勘違いするというか
ボーッとしてるとそういうコード書いちまうことがある
大概のAPIでは失敗したときNULLが返ってくるってのもある
混在いやん

**デフォルトの名無しさん** · 2019/09/13(金) 23:10:11.55

あと、なんでINVALID_HANDLE_VALUEが必要になったのか技術的な背景が気になる
普通に0を返しとけばいいじゃん、って思うよね
他のAPIがそうなってるんだから
謎

**デフォルトの名無しさん** · 2019/09/13(金) 23:49:45.81

お前だけじゃボケ

**デフォルトの名無しさん** · 2019/09/14(土) 00:13:31.65

>>281
どんなAPIでも最低限の仕様確認してから使えよ

**デフォルトの名無しさん** · 2019/09/14(土) 03:06:20.87

しかしそれらを超越した次元で総合的に判断してやっぱりINVALID_HANDLE_VALUEは糞
必要ないからな

**デフォルトの名無しさん** · 2019/09/14(土) 03:09:13.59

The Old New Thingにあったな
https://devblogs.microsoft.com/oldnewthing/20040302-00/?p=40443

**デフォルトの名無しさん** · 2019/09/14(土) 05:42:23.89

>>284
それは論点が違う
マジで糞かどうかだろうが
285はちゃんと自分なりの見解を言っているし
286は情報提供している
お前だけとかくだらんことしか言わんボーガスとは次元が違う

16bit時代は低コストに拘るあまり
色々とアホなことをしていた
その名残を糞って言えないやつも糞だ

**デフォルトの名無しさん** · 2019/09/14(土) 10:06:00.92

ComboBoxはCB_ERRがある
ListBoxはLB_ERRがある

ListViewはただの-1で定義無し
LV_ERRじゃないのはなんで？

**デフォルトの名無しさん** · 2019/09/14(土) 11:02:16.25

>>286読んで思い出したが
そうそうHANDLEのスマポ作るときにウザいんだよな
既定の初期値を何にしておくかって問題があるからな！
ああ糞だ

**デフォルトの名無しさん** · 2019/09/14(土) 11:26:55.16

後HANDLEのスマポのデストラクタでCloseHandleするとき
失敗したり何も入ってなかったり
無効なハンドルの場合はCloseHandleしないようにする場合も嫌らしい
無効なハンドルを表す値が二つ有るからな！！
if( handle && handle != INVALID_HANDLE_VALUE ){ ::CloseHandle( handle ); }
と書いてしまいたいところだが、本当にこれでよいのか？
それかCloseHandleに無効なハンドルを渡したときは何もしないことを期待して
if文なしで単に::CloseHandle( handle );とだけ書くか
しかしCloseHandleに無効なハンドルを渡したときの動作はMSDNには書かれてないんだよな
まぁ何もしないと思うが

**デフォルトの名無しさん** · 2019/09/14(土) 11:39:00.01

ああ今調べたら、CloseHandleに無効なハンドル渡したら
GetLastErrorが汚染されるらしいな

**デフォルトの名無しさん** · 2019/09/14(土) 11:51:46.43

初期化と開放とかのインターフェース作って、そのインターフェース派生でAPIアクセスしてるな
その手のはAPI直接叩くソース書くと後からコーディングミスに気付いても修正困難になるしバグの元

**デフォルトの名無しさん** · 2019/09/14(土) 13:23:12.69

>>288
前者2つはOS基本機能、後者はコモンコントロールというオプション
という違いから歴史と立ち位置が違う
ついでに言えば設計から全然違うんで、定義がないのは不思議ではない

**デフォルトの名無しさん** · 2019/09/14(土) 13:47:20.57

どれもコモンコントロールだよ
歴史的には昔はリストビューがコモンコントロールじゃなかったかもしれないが分からない

**デフォルトの名無しさん** · 2019/09/14(土) 14:05:12.55

昔のWindowsAPIはHANDLEとポインタが別物だったのを知らん人がいるのか

**デフォルトの名無しさん** · 2019/09/14(土) 14:06:49.93

>>288
ポインタが奇数になるはずはない(キリっ
だから奇数の空間を全て別のオブジェクトに
おれ天才じゃね？って糞言語が日本にはある

**デフォルトの名無しさん** · 2019/09/14(土) 15:56:30.20

フリーのリソースエディタとAPIでGUIプログラムを作っているけど、
もう時代遅れなのかな。

みなさんは、GUIプログラムはどうやって作っていますか。

**デフォルトの名無しさん** · 2019/09/14(土) 16:05:19.86

リソースエディタなんぞ使わず全部apiからテキストエディタ上で
数値指定で作ってるんでそんな自分よりかは進んでるぞ
まあ今の時代ならvisual studio使うのが普通だろうね

**デフォルトの名無しさん** · 2019/09/14(土) 16:05:25.06

20年前から来たのかな？

◆QZaw55cn4c · 2019/09/14(土) 16:49:47.51

>>297
cygwin/mingw64 でコンパイル・リンクできるよう、リソースは手書きですね…

**蟻人間** ◆T6xkBnTXz7B0 · 2019/09/14(土) 16:58:44.72

俺は自作のリソーエディタ使ってるけど。MinGWでもVC++でもビルドできるよ。

**デフォルトの名無しさん** · 2019/09/14(土) 17:18:22.21

>>294
コモンかどうか名前はさておき、リストビューは明確にcomctl32を使うような
宣言とリンクがないと使えないでしょ
リストもコンボはこいつの範疇ではない

**デフォルトの名無しさん** · 2019/09/14(土) 19:04:46.82

WinUser.h
　ComboBox CB_ERR
　ListBox LB_ERR
CommCtrl.h
　ListView関係のメッセージやマクロ

この違いは歴史関係って事？
LVM_INSERTITEMが失敗した場合は-1が返るけど
LV_ERR(-1)とするのはおかしい？

**デフォルトの名無しさん** · 2019/09/14(土) 19:37:03.95

作者の気持ちを想像して答えなさいスレッド

**デフォルトの名無しさん** · 2019/09/14(土) 21:33:59.27

Windowsで.NET使わずにC/C++とWin32APIでPerl互換の正規表現を使ったプログラムを作る場合、
従来はboost::regexやPCREなど別途ライブラリが必要だったけど、Windows10以降はICUの正規表現を使えるようになった。
ただし、可変長文字列を扱うUnicodeStringクラスがヘッダーファイルicu.hから削除されているので、std::wstringなどで代替する必要がある。

**デフォルトの名無しさん** · 2019/09/14(土) 21:43:24.62

ListViewはWindows95で追加されたコントロール

**デフォルトの名無しさん** · 2019/09/14(土) 22:37:17.04

昔の事は多少は多目に見てやれよ。今みたいにSNSが活発じゃないし、githubで他人のソースも簡単に見れるわけしゎゃない。知見を共有しづらい時代なんだから

**デフォルトの名無しさん** · 2019/09/14(土) 22:44:48.45

システムハンガリアンという糞も生みだしたしな

**デフォルトの名無しさん** · 2019/09/14(土) 23:54:23.09

ハンガリアン記法自体はBug捕り等に有効だったのに

**デフォルトの名無しさん** · 2019/09/15(日) 01:22:53.14

dwは長さが一番揺らいでると思う

**デフォルトの名無しさん** · 2019/09/15(日) 04:13:59.48

Standard Control
Common Control

**デフォルトの名無しさん** · 2019/09/15(日) 07:17:29.58

>>309
システムハンガリアンは違うし、なんで過去形なんだ？

**デフォルトの名無しさん** · 2019/09/15(日) 10:17:05.74

>>306
そうなのか

他の人もありがとう

**デフォルトの名無しさん** · 2019/09/15(日) 12:35:24.64

unix の execlp だと pid は変化しませんが、
Win32API の execlp とか _execlp とかだと processID は変化してしまうようです。

CreateProcess が呼ばれているからだと思いますが、
Win32API の execlp とか _execlp とかで変わったあとの processID を知る方法はありますか？
(起動された側で getpid() で判るのですが、そっちではなくて元の processID を握ってる方からのリンクが切れて困ってます。)

**デフォルトの名無しさん** · 2019/09/15(日) 18:08:42.80

>>297
俺はリソーススクリプト直叩き
MSDNに詳しい情報乗ってるし、英語だけど
プログラマなら大体わかるよ、翻訳サイトを使ってもいいしね

そして、ライブラリ化しといて次から簡単に使えるようにしとく
バージョン情報とかも関数やクラスにして簡単に使えるようまとめとけば便利
GUIは.NETがクラス化の良いお手本になるよ

**デフォルトの名無しさん** · 2019/09/15(日) 19:39:40.56

VS使わない縛りなの？

**デフォルトの名無しさん** · 2019/09/15(日) 19:55:06.55

>>314
> Win32API の execlp とか _execlp
そもそもexeclpとかはwin32apiじゃなくて単なるライブラリだよ
とりあえずざっとソース見る限りではpidを返す方法はないみたい（インターフェースもないしね）
自分で実装するしかないと思う

**デフォルトの名無しさん** · 2019/09/15(日) 23:50:00.36

>>316
VSは使ってるよ、昔は無料のエディションには
MFCもリソースエディタも付いてなかったからな

趣味でやってるから問題なし
フリーのリソースエディタを入れるか迷ったこともあったけど
直叩きで行けるしまあいいかと

**デフォルトの名無しさん** · 2019/09/16(月) 00:47:21.27

それぐらい普通、何でもないよ
俺なんかメニューバーとかスクロールバーとかツールバーとかリストビューとか
こまごましたUIパーツ、全部DirectXで一からフルスクラッチで書いたし
4K画面だとリストビューとか動作がカクカクになるから使い物にならんよ
フォントの描画が重いみたい

**デフォルトの名無しさん** · 2019/09/16(月) 00:49:05.96

結構前からリソースエディタは無料版VSでも入ってたろ

**蟻人間** ◆T6xkBnTXz7B0 · 2019/09/16(月) 01:47:28.54

後世のために書いておくが、Visual StudioのリソースコンパイラーはUTF-8の扱いに致命的なバグがあって、最悪の場合、文字化けする。あれはANSIコードページかUTF-16で使うものだ。

**デフォルトの名無しさん** · 2019/09/16(月) 10:51:40.64

不定期
https://stefansundin.github.io/xn_resource_editor/

**デフォルトの名無しさん** · 2019/09/16(月) 12:37:37.02

>>321
コンパイラーの問題だからエディターは何でもいいんじゃね
って話ではないの？

**デフォルトの名無しさん** · 2019/09/16(月) 17:55:40.47

そもそもリソースファイルにUTF8が使えるなんて知らなかったわ

**デフォルトの名無しさん** · 2019/09/16(月) 17:57:32.41

いや使えないでしょUTF-8

**蟻人間** ◆T6xkBnTXz7B0 · 2019/09/16(月) 18:32:35.66

MinGWのwindresというコンパイラーなら、pragmaでコードページ指定すればUTF-8が使える。
Visual Studioのrcは前述の通りUTF-8読み込みにバグがある。

**デフォルトの名無しさん** · 2019/09/16(月) 18:40:12.76

RisohEditorってどうなん

**蟻人間** ◆T6xkBnTXz7B0 · 2019/09/16(月) 18:43:49.21

RisohEditorはUTF-8とUTF-16のソースが扱える。UTF-16の入力は、独自のプリプロセッサでUTF-8に変換している。

**蟻人間** ◆T6xkBnTXz7B0 · 2019/09/16(月) 18:46:27.85

VSのRCの文字化けバグについては
https://developercommunity.visualstudio.com/content/problem/384705/visualstudio-v1590-resource-editor-using-utf-8-bom.html
こちらで。まだ直っていない。

**デフォルトの名無しさん** · 2019/09/16(月) 18:52:28.03

リソースファイルはBOMつきUTF-16LEでいけるでしょ。

**デフォルトの名無しさん** · 2019/09/16(月) 19:26:31.76

重箱。UTF-16LE/BEと呼ぶ場合はBOMを付けてはならないらしい。

**デフォルトの名無しさん** · 2019/09/16(月) 19:56:19.89

UTF-8 も BOM 付けちゃいけないんだろ

**デフォルトの名無しさん** · 2019/09/16(月) 20:21:16.53

UTF-8なら禁止はされていない。

**デフォルトの名無しさん** · 2019/09/17(火) 00:30:59.73

>>331
理解が間違っている。

「BOMつきUTF-16LE」と「UTF-16LE」は別のものであり、どちらも存在する。
「UTF-16LE」にBOMがついていないからこそ「BOMつきUTF-16LE」という表現が成り立つ。
小倉トーストとトーストが別のものであることと同じであり、トーストに小倉餡がついていないからこそ小倉トーストが成り立つ。

**デフォルトの名無しさん** · 2019/09/17(火) 02:12:33.57

粒餡と餡子が別のものであることと同じであり、
餡子に粒が入ってないからこそ粒餡が成り立つ
ってことですね

**デフォルトの名無しさん** · 2019/09/17(火) 02:53:38.24

名古屋のモーニングにゆで卵がついたからといって、モーニングでなくなるわけではないのだ。
無論、ゆで卵がつかないモーニングもある。ゆで卵がつこうがつくまいがモーニングなのだ。

**デフォルトの名無しさん** · 2019/09/17(火) 03:09:38.39

名古屋とか言う異世界の話はやめようぜ
意味が分からん

**デフォルトの名無しさん** · 2019/09/17(火) 18:03:14.36

名古屋が4次元？

**デフォルトの名無しさん** · 2019/09/17(火) 18:08:21.64

みそかつ
みそ煮込みうどん
高血圧

**デフォルトの名無しさん** · 2019/09/17(火) 18:36:53.76

段ボール入り肉まんが人によってはバレないが、やはり人間的にはエラーが出やすい
そういうことだな

**デフォルトの名無しさん** · 2019/09/18(水) 14:01:12.80

Caretの点滅間隔について質問です

自アプリがアクティブの時のみ点灯(点滅間隔にUINT_MAXを指定して擬似的に)
自アプリが起動中はWM_SETFOCUSでON(点灯)に、WM_KILLFOCUSでOFF(元の間隔)にする事はできましたし他のアプリにも影響はありません
ですが自アプリが終了したら他のアプリでもONの状態になってしまいます
メッセージを追ってみると
WM_CLOSEでDestroyWindow
→WM_KILLFOCUSでOFFへ
→プロセスが終了
になっていたので自アプリ内で再度ONになっている事はないです

これはどういう事ですか？

**デフォルトの名無しさん** · 2019/09/18(水) 19:04:24.43

WM_CLOSE
→DestroyWindow (hWnd 失効)
→WM_KILLFOCUSでOFFへ (hWnd 違いで無視)
→プロセスが終了

かな
知らんけど

**デフォルトの名無しさん** · 2019/09/18(水) 19:30:38.13

ありがとうございます

引数は間隔のみですが一応DestroyWindow直前でOFFにしてみても同じ結果でした

**デフォルトの名無しさん** · 2019/09/18(水) 19:31:59.76

完成品には道のり遠くｗ

**デフォルトの名無しさん** · 2019/09/18(水) 19:37:10.52

Getで値を見てみるとONの状態になってしまうのではなく
アプリが終了したら間隔が0xfeeefeeeになってしまう
でした

言い直しますと
System設定の500(ミリ秒)からUINT_MAXではなく200へ変更するようにしても
アプリを終了したら間隔が0xfeeefeeeになってしまう
です

**デフォルトの名無しさん** · 2019/09/18(水) 19:39:32.20

たまねぎスレｗ

**デフォルトの名無しさん** · 2019/09/18(水) 19:57:32.75

方法は何でもいいけど、例えばクリックしたらキャレット処理を終了→その後アプリ終了でどうなるかやってみ
問題が絞り込めるでしょ

WM_CLOSEで終了処理が思ったように動いてないってのはありがち

**デフォルトの名無しさん** · 2019/09/18(水) 20:00:53.08

はい完成品なしｗ

**デフォルトの名無しさん** · 2019/09/18(水) 20:07:36.38

>>347
それも既に試しましたが同じ結果です
>>341でも書きましたがメッセージを追ってWM_CLOSEが正常な事も確認済みです

**デフォルトの名無しさん** · 2019/09/18(水) 20:10:21.94

はいBASICからやり直しｗ

**デフォルトの名無しさん** · 2019/09/18(水) 20:10:41.11

>>347
途中送信すみません
設定してもいない値0xfeeefeeeになるので
間隔はSystemと同じ値(500)にSetするだけにしてみても同じ結果でした