Win32API質問箱 Build126

**デフォルトの名無しさん** · 2020/05/01(金) 22:16:51.96

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

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

■過去スレ
Win32API質問箱 Build125
https://mevius.5ch.net/test/read.cgi/tech/1551247748/
Win32API質問箱 Build124
https://mevius.5ch.net/test/read.cgi/tech/1510395780/

■関連スレ
Visual Studio 2019 Part4 https://mevius.5ch.net/test/read.cgi/tech/1585715794/
Visual Studio 2017 Part7 https://mevius.5ch.net/test/read.cgi/tech/1558179898/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】 https://mevius.5ch.net/test/read.cgi/tech/1521786252/

**デフォルトの名無しさん** · 2021/07/11(日) 10:50:14.49

これは話をループさせる手段なのか？ｗ

**デフォルトの名無しさん** · 2021/07/11(日) 11:20:11.96

「Hacking: 美しき策謀」ぐらいは読んでこいよ

**デフォルトの名無しさん** · 2021/07/11(日) 11:49:37.25

本当に管理されていると言うのなら、別のlibで定義されている
HMODULE get_this_dll_module();
という関数によって、あらゆるDLLのHMODULEを取得できるようになるはずで
あるが、この関数は、スタックフレームを前提にしない限りは基本的に
作ることが出来ない。なぜなら
void get_this_dll_module() {
　// ここの EIP の値は、呼び出しもとの DLL のものとは違っている。
}
からである。

**デフォルトの名無しさん** · 2021/07/11(日) 11:51:10.61

>>665
誤: void get_this_dll_module()
正: HMODULE get_this_dll_module()

EIPのアドレスは、簡単に変わりうるものなのだ。

**デフォルトの名無しさん** · 2021/07/13(火) 12:38:32.06

だらだらしてるので
3行でまとめてくれ

**デフォルトの名無しさん** · 2021/07/13(火) 12:47:15.46

>>667
現在の関数からその関数が格納されているDLLのパスまで取得できる情報があることを
OSが管理していると呼ぶかどうかで
外野がうんこの投げ合いをしている

**デフォルトの名無しさん** · 2021/07/13(火) 13:19:09.51

そういうのは動物園でやれよ

**デフォルトの名無しさん** · 2021/07/13(火) 13:50:43.04

無駄な議論ではなく、質問者が、現在実行中の関数の所属する
DLLを正確に取得する方法があると思い込んでいた可能性があるので
大事な指摘だった可能性がある。
結論から言えば、安定してそれを取得する方法は無い。

**デフォルトの名無しさん** · 2021/07/13(火) 14:46:12.78

質問者は普通に安定した方法で自己解決していったな

**デフォルトの名無しさん** · 2021/07/13(火) 16:28:34.84

get_this_dll_moduleてなんなんってぐぐったら
このスレが引っかかってわろた
脳内の関数だったか

**デフォルトの名無しさん** · 2021/07/13(火) 17:47:39.31

未解決のせいで盛り上がってたのかと思ったら>>622で解決してたのか

**デフォルトの名無しさん** · 2021/07/14(水) 20:59:18.35

>>620
他のこと調べてたら見つけたけど__ImageBaseって変数のアドレスがまさに目的そのものっぽいわね

https://devblogs.microsoft.com/oldnewthing/20041025-00/?p=37483

**デフォルトの名無しさん** · 2021/07/14(水) 21:06:59.94

「D:\aaaa\bbbb」などの、ファイルやフォルダのパス名から、
そこがCDやDVDなどの光学ドライブかを判定する仕組みはありますか？

**デフォルトの名無しさん** · 2021/07/14(水) 21:11:04.17

GetLogicalDriveStringsかな

**デフォルトの名無しさん** · 2021/07/14(水) 21:13:56.34

途中送信ごめん

全ドライブ文字と種類がわかるから
後は比較するオレオレ関数作る感じ

**デフォルトの名無しさん** · 2021/07/14(水) 21:15:40.83

何度もごめん

種類はGetDriveTypeね

**デフォルトの名無しさん** · 2021/07/14(水) 21:36:03.70

>>678
ありがとうございます。
GetDriveTypeは、"D:\"の3文字の部分しか渡せないようですが、
PathGetDriveNumberでも使えば、"D:\"の部分だけを作れそうですね。

**デフォルトの名無しさん** · 2021/07/15(木) 01:52:58.00

リッチエディットに複数行の文字列をプログラムから定期的に送って全内容を更新するプログラムを作成しています。
更新中は垂直スクロールバーで任意の行に移動できるようにしています。
コードは下記です。

LRESULT Line = SendMessage( hEdit, EM_GETFIRSTVISIBLELINE, 0, 0 ); // 現在の表示行を控えておく

SendMessage( hEdit, WM_SETREDRAW, FALSE, 0 ); // 文字列更新中の状態が露呈しないよう再描画を抑制する

SetWindowText( hEdit, str ); // 全文字列更新

SendMessage( hEdit, EM_LINESCROLL, 0, -INT_MAX ); // 表示行を一番上に移動する
SendMessage( hEdit, EM_LINESCROLL, 0, Line ); // 表示行を、控えておいた位置に移動する

SendMessage( hEdit, WM_SETREDRAW, TRUE, 0 ); // 再描画再開

InvalidateRect( hEdit, NULL, FALSE ); // 表示を促す

これで、ある程度までの行数の文字列であれば、意図通りの挙動となるのですが、
行数が多くなってくると、動かしていたスクロールバーが一瞬一番下まで下がってから
元の位置に戻るという現象が文字列更新の度に起こります。
ただ、リッチエディット内の表示位置は、動かしていたスクロールバー位置に対応する位置のままで、
スクロールバーが一瞬一番下がる動きとは連動しません。

一体何が起こっており、どのようにすれば回避できそうでしょうか？

**デフォルトの名無しさん** · 2021/07/15(木) 09:58:52.50

もしかしてそれって32767行くらい超えてから？

**680** · 2021/07/15(木) 12:02:49.75

>>681
改行文字(\n)だけの80行くらいでも発生しました。
そして>>680の内容に訂正があります。
>動かしていたスクロールバーが一瞬一番下まで下がってから
は、一番下までは下がっていませんでした。
また、下がったときはバーが長くなっており、
あたかも行数が少なくなったかのよう(エディット内の表示は意図通り)な挙動です。
さらに、以下のような性質も分かりました。

・スクロールバー位置が一番上のときは一瞬下がる症状が発生しない
・スクロールバー位置が一定より下になると一瞬下がる症状が発生しない
　・この位置は全体行数とリッチエディットの縦幅との関係によって変わり、
　　スクロールバーの長さが全体の大半を占める場合はどの位置でも発症しなくなる

**デフォルトの名無しさん** · 2021/07/15(木) 13:08:28.58

>>682
キャレットが画面外にあるか画面内にあるかで挙動は変わったりする？

**デフォルトの名無しさん** · 2021/07/15(木) 13:18:19.61

一口にリッチエディットっていってもバージョンが4種類くらいあって
それぞれ微妙に動作が違ったような気がする

**680** · 2021/07/15(木) 14:06:57.14

>>683
文字列更新前にキャレットが画面内にあるか画面外にあるかで挙動に変化ありませんでした。

>>684
リッチエディットのバージョンはv2.0(UNICODE)です。

**デフォルトの名無しさん** · 2021/07/15(木) 15:02:56.70

特定プロセス（PID）のアドレス空間の情報を取得するAPIはありますか？

**デフォルトの名無しさん** · 2021/07/15(木) 15:17:12.92

スクロールバーの描画も同時に禁止するとか
スクロール範囲の最大値も強制的に変更してから描画再開するとか

**デフォルトの名無しさん** · 2021/07/15(木) 15:39:38.74

>>685
キャレットが画面内でも外でも
おかしな症状が発生するかどうかは>>682の条件って事？

**680** · 2021/07/15(木) 16:21:18.89

>>687
スクロールバーのハンドルを取得する方法が分からなかったので、
テキスト＆スクロールバー位置更新時、ダイアログ全体の再描画を抑制してみましたが、
再描画がかかるタイミングでやはりスクロールバーが一瞬動きます。

スクロール範囲の最大値もテキスト更新前に控えておいた数値を、テキスト更新後に設定しましたが変わらずでした。

>>685
はい、>>682の条件です。

進展がありました。
SetWindowText()でテキスト更新をしていた部分を

SendMessage( hEdit, EM_SETSEL, 0, -1 );
SendMessage( hEdit, EM_REPLACESEL, FALSE, ( LPARAM )str );

と置き換えたところ、
スクロールバーを動かしても、その後、一瞬下に動くといったことがなくなり、
期待通りその場に留まり続けてくれました！
しかし、ダイアログのフォーカスを外した後、再度フォーカスを得ると、一番下に飛んでしまいます･･･。
惜しい･･･。

フォーカス取得の際、スクロールバー位置が更新されるものと思われますので、
そのときのウインドウメッセージを捕えて、テキスト更新時と同様にスクロールバー位置を制御すればいけるかもです。

**デフォルトの名無しさん** · 2021/07/15(木) 16:33:06.78

＞SendMessage( hEdit, EM_LINESCROLL, 0, -INT_MAX ); // 表示行を一番上に移動する
＞SendMessage( hEdit, EM_LINESCROLL, 0, Line ); // 表示行を、控えておいた位置に移動する
これで振動してるような気もする

フォント高さ x 行数とクライアント領域の高さが不一致な状態で
SetWindowText() で更新したとき、クライアント領域内の先頭行側が欠けて　最終行側がきっちり見えてるんだけど

上の2行の変わりに
　SendMessage( hEdit, EM_LINESCROLL, 0, 0);
を投げると先頭行がきっちり収まる位置にきて、スクロールバーがピコピコすることもない雰囲気

**デフォルトの名無しさん** · 2021/07/15(木) 17:34:53.12

>>689
ダイアログカヨ

WM_ACTIVATEが悪さしてるとかない？

**蟻人間** ◆T6xkBnTXz7B0 · 2021/07/15(木) 18:00:01.33

WM_VSCROLL.SB_TOP使った方がいいんじゃね？

**デフォルトの名無しさん** · 2021/07/15(木) 18:23:17.10

>>680
>SendMessage( hEdit, WM_SETREDRAW, FALSE, 0 );　// 文字列更新中の状態が露呈しないよう再描画を抑制する
↑は、RichEditControl のメッセージではなく、Win32のWindow一般のものらしい。
但し、MSDNには、ListBoxで複数のアイテムを追加するときに便利だと書いてある。
質問者の実験を聞く限り、RichEditControlにのみこのメッセージを送っただけでは、
そこにくっついているスクロールバーに対しては効果が無いようだ。

**デフォルトの名無しさん** · 2021/07/15(木) 18:45:09.69

Rich Edit Control を作成する時のスタイルに
WS_VSCROLL
を付け、
ES_DISABLENOSCROLL
を付け、
ES_AUTOVSCROLL
を外すと縦スクロールバーが出るが、勝手に制御されにくくなるかも。

**デフォルトの名無しさん** · 2021/07/15(木) 18:49:18.52

WM_SETREDRAWは、ListBoxに関しては色々語られている：
https://devblogs.microsoft.com/oldnewthing/20110124-00/?p=11683

**デフォルトの名無しさん** · 2021/07/15(木) 18:55:04.61

SendMessage( hEdit, WM_SETREDRAW, FALSE, 0 );
は効果は有るにはあるが、アプリ側が自らスクロールバーを制御するようなメッセージを
Rich Edit Control に送った場合、↑の設定が無視されて、スクロールバーの描画が
起きてしまっている可能性がある。なので、
>SendMessage( hEdit, EM_LINESCROLL, 0, -INT_MAX ); // 表示行を一番上に移動する
>SendMessage( hEdit, EM_LINESCROLL, 0, Line ); // 表示行を、控えておいた位置に移動する
の部分、上の行を省いて、下の行だけにするとちらつかなくなる可能性が高い。
また、上の行の役割の代わりとして、カーソルの位置はスクロールの位置とは別に制御すると良いはず。

**680** · 2021/07/16(金) 01:36:18.95

>>690
EM_LINESCROLLは現在位置からの移動を指示するので、
SendMessage( hEdit, EM_LINESCROLL, 0, 0);
だと何も作用がありませんね。

>>691
>>689の処理ですが、WM_ACTIVATE後、次のテキスト更新までの間に、スクロールバーが一番下に移動する動きが確認できました。

>>692
SB_TOPで一番上に戻しても症状は同じでした。

>>693
再描画抑制をしないと、テキスト更新の際の過渡的な状態が露呈し、スクロールバーも一瞬動くのが見えたりするのですが、
再描画抑制により、これらが露呈しなくなるので、スクロールバーにも効果があるようです。

>>694
試してみましたが症状変わらずでした。

>>695
英語が苦手で完全には理解できないのですが、
再描画抑制解除後のWM_PAINTあたりでスクロールバー位置が更新され動いてしまうということがあり得そうですね。

>>696
上記の通り、
EM_LINESCROLLは現在位置からの移動を指示するので、
SendMessage( hEdit, EM_LINESCROLL, 0, Line );
だと下に動き続けてしまいます。

試しにリッチじゃないエディットボックス(MultiLine有効)に置き換えたところ、すんなりいきました。
前にも試したことがあったんですが、リッチエディットが\nだけで改行されるのに対し、
エディットボックスでは改行されなかったのでダメだと思っていました。
本日、エディットボックスの場合は\r\nで改行されることを知り、これでうまくいきました。
\rが増える分、更新(転送)する文字量が増えてしまいますし、その他、リッチエディットとは異なり、
・ReadOnlyだと背景がグレーになる(審美的にはリッチエディットのような白が好ましい)
・表示矩形内に文字が収まっていてもスクロールバーの枠が表示される
・表示がたまにチラツく
といった気になる点があるのですが、不安定なスクロールバーに比べたら許容範囲です。

多数のご助言をいただき、ありがとうございました。

**デフォルトの名無しさん** · 2021/07/16(金) 01:48:03.35

どうでもいいけどWin32とかの文字列の型名わかりずらすぎて嫌がらせとしか思えない
なんだよLPCTSTRってconst wchar_t*でいいだろ

**デフォルトの名無しさん** · 2021/07/16(金) 11:06:31.00

それだとLPCWSTRでは

**デフォルトの名無しさん** · 2021/07/16(金) 11:36:36.57

スカラ値へのポインタではなく配列先頭アドレスですよという意図は一応あるのかもしれない

**デフォルトの名無しさん** · 2021/07/16(金) 11:42:16.54

>>699
はにゃ？
https://imgur.com/a/1pn6Inx

**デフォルトの名無しさん** · 2021/07/16(金) 11:57:18.77

UNICODE マクロが定義されていればそれはそう

**デフォルトの名無しさん** · 2021/07/16(金) 11:58:40.86

Tがつく奴はUNICODEの定義の有無でwchar_tかcharに変わるから

**デフォルトの名無しさん** · 2021/07/16(金) 13:31:01.23

>>701
そもそも全部wchar_tでいいって事なら
TじゃなくてWでいい

**デフォルトの名無しさん** · 2021/07/16(金) 14:39:23.11

UNICODE対応とはいわばUTF8に対応していると思っている僕がかつて居ました

**デフォルトの名無しさん** · 2021/07/16(金) 16:32:41.77

いまどき -D_UNICODE せんやつはおらんよな？よな？

**デフォルトの名無しさん** · 2021/07/16(金) 17:34:41.64

>>706
＞いまどき -D_UNICODE せんやつはおらんよな？よな？

自分はここしばらくWindowsのプログラムから離れてるんで、思い違いしてるかもしれんが・・・
いまどきはWindows10のワールドワイド言語サポートを使ってアプリ内部・外部入出力ともUTF-8にするんじゃないか？

**デフォルトの名無しさん** · 2021/07/16(金) 17:54:02.54

_UNICODEはWin32APIがUTF-16版かどうかの話なんでアプリは好きにやりゃええねん

**デフォルトの名無しさん** · 2021/07/16(金) 17:58:18.04

>>707
VC付属のCライブラリがUTF-8に完全対応してない
ファイルオープンで積む
VCの対話デバッガも変数のUTF-8テキストビューに対応してない

**デフォルトの名無しさん** · 2021/07/16(金) 18:27:58.18

失礼、積むではなく詰むだった

**デフォルトの名無しさん** · 2021/07/16(金) 19:08:27.97

ビジネスが破綻する大半の原因は、 ”ビジネスを始める人の大半が、真の意味での
「起業家」ではなく、起業したい、という熱に浮かれた「職人」として働いているに過ぎない。”
という事実にあります。
「職人」によって運営されているビジネスは、ビジネスが働くのではなく、彼ら自身が毎日働くこと
によって、成り立っています。
彼らは毎日、自分がやり方を知っている仕事を一生懸命にこなしていますが、「起業家」としての
視点が無いために、成長に限界が生まれます。
そして、生計を立てるために、彼ら自身がずっと働き続けないとならないのです。

誰もが必ず陥る罠
私が見ている限り、起業熱にうなされる人たちは、必ずと言ってもよいほど誤った
「仮定」を置いてしまうようだ。実は、のちに彼らが苦難の道を歩むことになるのは、
この、「仮定」が致命的に間違っているからなのである
致命的な仮定とは・・・「事業の中心となる専門的な能力があれば、事業を経営する能力は
十分に備わっている」ということである
私がこの仮定を致命的だと書いたのは、この仮定が間違っているからにほかならない
事業の中で専門的な仕事をこなすことと、その能力を生かして事業を経営することは
全く別の問題である。高い専門能力を持つ人にとって、独立は他人の為に働くという苦痛から
解放されるということを意味していた。それにもかかわらず、前提となる「仮定」が致命的とも
いえるほど間違えているために、彼らは自由になるどころか、自分が始めた事業に苦しめ
られるようになってしまうのである
マイケルEガーバー「はじめの一歩を踏み出そう」P28~29

**デフォルトの名無しさん** · 2021/07/27(火) 13:44:15.34

Windows用のMFC製のアプリをシェアウェアとして公開するのに、
Vector以外に良いものは無い？
Vectorは作者登録の手順がとてもメンドクサイ。
写真を送ったりとか、作者にばかりプライバシーや個人情報を負担させる仕組み。

**デフォルトの名無しさん** · 2021/07/27(火) 14:41:02.45

色々書こうかと思ったけどスレ違い

**デフォルトの名無しさん** · 2021/07/27(火) 16:09:06.09

窓の杜

**デフォルトの名無しさん** · 2021/07/27(火) 16:48:35.67

>>712

＞作者にばかりプライバシーや個人情報を負担させる仕組み。
ソフトウェア等のダウンロード販売は、
特定商取引法に基づいて住所や氏名(法人名)等の公開が必要

＞Vector以外に良いものは無い？
自分のＨＰにアップしてReadMeに振込先等書いとけば？

**デフォルトの名無しさん** · 2021/07/27(火) 18:12:55.62

>>715
Vectorのシェアレジって、作者の住所が公開されるんだっけ？
それは困るな。

**デフォルトの名無しさん** · 2021/07/27(火) 18:24:12.75

こういうのとかは？
ttps://blog.okazuki.jp/entry/2018/10/04/160349

**デフォルトの名無しさん** · 2021/07/27(火) 18:40:47.67

>>717
マイクロソフトストアに登録するためにMFCを変換しなくてはいけないらしくて
そのやり方がめんどうくさそう。
どうすればいいのかよく分からない。

**デフォルトの名無しさん** · 2021/07/27(火) 18:44:25.23

インストーラー作りに2ヶ月くらいかかりそう。
なんのためにそんな必要が。

**デフォルトの名無しさん** · 2021/07/27(火) 18:45:21.80

MFCメインアプリを起動するためだけのUWPランチャアプリでも登録すればワンチャン？

**デフォルトの名無しさん** · 2021/07/27(火) 18:55:07.32

金のためちゃうの

**デフォルトの名無しさん** · 2021/07/27(火) 19:06:58.56

ヤフオクでデータやパスワードを売ることも出来るらしいけど、
一回登録したら100人でも1,000人でも売れるようにすることは出来ないのかな？
そもそも、1000人分を「商品」として一度に登録できるのだろうか？

**デフォルトの名無しさん** · 2021/07/28(水) 15:46:01.54

Windows 11のストアで配布する
あれって何でも配布できるようになるんだっけ??

**デフォルトの名無しさん** · 2021/08/18(水) 23:54:37.99

以下のようにテキストログファイル名を変更してそれを読み出す処理があるのですが
fopenでNULLが返ってくる事があり、GetLastErrorで得られるエラーコードは0x00000020で
「プロセスはファイルにアクセスできません。別のプロセスが使用中です。」
となります

自アプリだけが吐き出して使うログファイルでプロセスの多重起動もしておらずシングルスレッドで、
そもそもMoveFileで成功が返ってきているのに直後のfopenでエラーになる原因が見当付きません

unlink(dst_path);
if (MoveFile(path, dst_path)) {
　　fp = fopen(dst_path, "rt");

苦し紛れにMoveFileの部分を
if (rename(path, dst_path) == 0 && PathFileExists(dst_path)) {
とやってみたこともありますが、やはりfopenでエラーになることがあります

毎日10時間以上稼働していて今年累計で13回ほどのエラーで低確率すぎるのと対策が思い付かなくて困っています
原因と可能性について助言頂けませんでしょうか

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/19(木) 01:01:43.70

>>724
ウィンドウズは、裏でシェルの変更通知やウィルススキャンやフックなどが動いてたりするんだよね。

それでファイルの確実な処理をしたいと言うことなら、処理を見直す必要がある。MoveFileを一つの処理と思ってるなら間違いだ。実際にはコピーした後で削除している。

【現在の処理】
Dを削除。
SをDに移動(実際はSをDにコピーしてSを削除)。
Dを読み込み。

【提案】
SをDに上書きコピー(CopyFile/CopyFileEx)。
Sを読み込む。
Sを削除。

**デフォルトの名無しさん** · 2021/08/19(木) 01:26:06.58

>>725
＞実際にはコピーした後で削除している。
それは異なるドライブの場合だろ？
同じドライブの場合はファイルシステムの書き換えだけのはずだろ

**デフォルトの名無しさん** · 2021/08/19(木) 03:06:16.65

>>725-726
レスありがとうございます
質問が長くなったので要点を絞り込んだつもりでしたが、もう少し追記させていただきます

dst_pathはpathの拡張子のみを変更したものですので、同じドライブ・フォルダになります
また、MoveFileの仕組みは仰るような仕組みで理解しているつもりですが、renameでも解決しないのが理解に苦しむところです
（といってもrenameの実装がどうなっているのか知らないのですが）

この処理で行っていることは、テキストログ中の不要な行を削除したいということで、

【現在の処理】
Dを削除。
SをDに移動(実際はSをDにコピーしてSを削除)。
Dを読み込みながら、Sに新規書き込み（削除したい行を読み捨てながら）。

という単純なことを行っていますのでご提案そのままではだめですが

【修正案】
Sを読み込みながら、Dに新規書き込み（削除したい行を読み捨てながら）。
Sを削除。
DをSにリネーム(MoveFile/rename)。

が思い付くのですが、そうするとSを書き込んでいるところ（全く別の場所ですが）で
もしかしてエラーが出るようになるのではという不安があります

いっそのことMoveFileの代わりになるものを自分で作ることも思い浮かびますが、
そもそも論として今回のような処理でここまでするものなのか？
という疑問と疑心暗鬼に陥っています

**デフォルトの名無しさん** · 2021/08/19(木) 09:56:10.36

原因についてはわかりませんが。。。
MoveFile()代替として、ハンドル開いた状態でファイル名を変更する場合にはSetFileInformationByHandle()を使用する。

HANDLE h =CreateFileW(srcfilename, GENERIC_READ| GENERIC_WRITE| DELETE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
size_t fri_size =sizeof(FILE_RENAME_INFO)+(wcslen(dstfilename)+1)*sizeof(wchar_t);
FILE_RENAME_INFO *fri =(FILE_RENAME_INFO *)malloc(fri_size); memset(fri, 0, fri_size);
wcscpy(fri->FileName, dstfilename);
fri->ReplaceIfExists =TRUE;
fri->FileNameLength =(DWORD)wcslen(dstfilename);
fri->RootDirectory =NULL;
BOOL res =SetFileInformationByHandle(h, FileRenameInfo, fri, (DWORD)fri_size);
free(fri);
CloseHandle(h);

**デフォルトの名無しさん** · 2021/08/19(木) 18:37:22.67

>>724
fopenでのエラーを調べるならGetLastErrorじゃなくてerrnoじゃないかな？

**デフォルトの名無しさん** · 2021/08/19(木) 21:29:03.55

>>724
カーネル内でのリソース開放は即座に行われるとは限らない。
お触りしたプロセスがいなくなった後でもカーネルの中で残ることがある。
この場合は成功するまでfopen()するしかないね。

**デフォルトの名無しさん** · 2021/08/20(金) 01:37:15.55

皆さんありがとうございます

>>728
対象ファイルがテキストファイルで一行ずつの処理のため、CreateFile系では
fgets系のAPIがないのでそこまで自作する必要がある点で最終手段として取っておきたいと思います

>>729
内部でWin32APIを叩いているイメージがありましたが、確かに言われてみればerrnoを使うべきですね
そのようにしてみます

**デフォルトの名無しさん** · 2021/08/20(金) 01:39:08.93

>>730
本件とは別件で新たな質問になってしまいますが、

プロセスAでファイルAをunlinkで削除
WM_APPを別プロセスBにPostMessageで通知
プロセスBでファイルAを再作成（プロセスBが起動していなくても、起動時にファイルAが無ければ再作成）

という箇所があるのですが、要するにキャッシュファイル的なものを削除して別プロセスで再作成を指示するようなことをしています
ここも稀に（？）再作成で失敗することがあるので気になっていました

Windowsプログラミングにおいて、ファイルの削除や移動についてはその後ウェイトを挟むか、
ファイルの作成でエラーが出たらリトライを入れるというのは常識的なものなのでしょうか？

**デフォルトの名無しさん** · 2021/08/20(金) 07:19:25.62

確実に作りたければ、中間ファイル作るやろ

**デフォルトの名無しさん** · 2021/08/20(金) 07:42:41.01

まーた覚え立ての言葉使いたがる子供が

**デフォルトの名無しさん** · 2021/08/20(金) 09:25:06.01

>>732
常識って人それぞれだからなあ...
エラー終了して使用者に丸投げするか、どこまでリトライするか、
ウエイトするのかリトライするのかはプログラムの次第だし...

今回の件のように、直前に誰かがお触りしてるのが
確実なのであれば、リトライするかウエイト入れるのが
確実だと思うよ。

**デフォルトの名無しさん** · 2021/08/21(土) 10:35:42.11

>>724
closeしてないやん？

**デフォルトの名無しさん** · 2021/08/21(土) 10:38:21.22

>>731
CreateFile したハンドルを FILE * に変換したら fgets 使えるが

**デフォルトの名無しさん** · 2021/08/21(土) 10:40:30.17

>>732
>Windowsプログラミングにおいて、ファイルの削除や移動についてはその後ウェイトを挟むか、
>ファイルの作成でエラーが出たらリトライを入れるというのは常識的なものなのでしょうか？

根本的な思い違いをしているに一票

**デフォルトの名無しさん** · 2021/08/21(土) 11:38:33.02

>>736
>>724がfcloseしていないというならそもそもfopenしただけとも言えるわけで説明のために以降は省いているってわかると思うんだが
そもそもが閉じ忘れならMoveFileも失敗するだろう

**デフォルトの名無しさん** · 2021/08/21(土) 12:28:01.97

>>737
せやな

_osfhandleとかfdopenをキーワードにggr

**デフォルトの名無しさん** · 2021/08/21(土) 12:54:10.92

そこまでせんでもcreatefileしたハンドルで移動してから一旦閉じてfopenでよくね？

**ハノン** ◆QZaw55cn4c · 2021/08/21(土) 14:27:27.29

再現できる簡単なソースは公開可能ですか？

**デフォルトの名無しさん** · 2021/08/21(土) 21:53:40.08

>>741
今回の問題は、いったん閉じてもカーネルが握ってるのでfopen()できないって話で

**デフォルトの名無しさん** · 2021/08/22(日) 12:32:08.06

>>743
だからMoveFileを代替しても同じやんって話で

**デフォルトの名無しさん** · 2021/08/22(日) 14:46:53.71

MoveFileEx「あのっ」

**デフォルトの名無しさん** · 2021/08/22(日) 16:25:47.23

論理的に考えれば「カーネル」が
握るわけ無いだろう。
ゴルフか麻雀でもしているののか

**デフォルトの名無しさん** · 2021/08/22(日) 16:40:10.74

ロクに質問読まずにというか理解せずにレスしてる馬鹿は何なの

**デフォルトの名無しさん** · 2021/08/22(日) 17:05:53.52

747の同類かと

**デフォルトの名無しさん** · 2021/08/22(日) 18:03:47.50

>>732
環境依存なことを考えて戻り値確認するのは別にWindowsに限らないし、戻り値が正常でも外部デバイス相手だとドライバ次第なこともある
別件で、組み込みWindowsでユーザがアプリが正常終了してすぐに電源コード引っこ抜くから
キャッシュがHDDに書き込まれずに消えるって事例はあったな

**デフォルトの名無しさん** · 2021/08/23(月) 07:47:18.19

>>749
NAS関係でOK出ているのに書き込まれて
いないってのはあったな

**デフォルトの名無しさん** · 2021/08/25(水) 19:50:31.67

LoadLibraryとかGetProcAddressしたものは
必ずFreeLibraryしないといけませんか？
自分のプロセスが必ず終了するときにFreeLibraryせずに放置しても勝手に解放される？

**デフォルトの名無しさん** · 2021/08/25(水) 20:26:18.34

>>75
されるわけないだろ
OSがナイナイしてくれるだけ

**デフォルトの名無しさん** · 2021/08/25(水) 21:58:54.28

>>751
プロセスごと始末してくれるから放置で構わん

**デフォルトの名無しさん** · 2021/08/26(木) 05:00:21.78

変な日本語・・・

**デフォルトの名無しさん** · 2021/08/26(木) 16:28:52.50

こっちくんな

**デフォルトの名無しさん** · 2021/08/26(木) 17:50:13.63

やって来ました
メッセージボックスで「計算結果はXX」って表示したくて

1 LPCWSTR func() {LPCWSTR a = L"//計算結果の値"; return a;} //計算結果を文字列にして返す関数
2 //以下WinMain()内
3 LPCWSTR a = L"計算結果は";
4 LPCWSTR b = func();
5 LPCWSTR c = 文字列を連結する関数(a, b); //StringCchCatW(), lstrcatW()などを試したがだめだった
6 MessageBoxW(hWnd, c, L"タイトルバー", MB_OK);

と書いたが動かなかった・・・
まず、1行目の「L"//計算結果の値"」に計算結果の変数を入れる方法がわからない
そして、5行目のLPCWSTR型の文字列を連結する方法がわからなからない
一日の大半がエラーとのにらめっこに費やされて辛い・・・
頼む、手伝ってくれさい

**デフォルトの名無しさん** · 2021/08/26(木) 17:58:52.10

宿題スレ案件ですか？

**デフォルトの名無しさん** · 2021/08/26(木) 18:24:36.40

>>757
いや普通にニート

**デフォルトの名無しさん** · 2021/08/26(木) 18:27:20.48

>>756
Win32APIではなくC言語の文字列とポインタの違いを勉強するところからやり直し

**デフォルトの名無しさん** · 2021/08/26(木) 18:29:12.42

wsprintf

**デフォルトの名無しさん** · 2021/08/26(木) 19:08:13.70

ニートならできないことは諦めればいいんじゃね？

**デフォルトの名無しさん** · 2021/08/26(木) 19:18:34.62

>>756

1 void func(CString &str) { str = "計算結果の値" } //計算結果を参照型引数の str に返す関数
2 //以下WinMain()内
3 CString str1 = "計算結果は";
4 CString strKekka;
5 func( strKekka );　// strKekka に計算結果の文字列が入って返って来る。
6 CString str2 = str1 + strKekka;
7 str2 を wide 文字列に直して、wpszText に入れる。 // ここはやり方を調べる。
8 MessageBoxW(hWnd, wpszText, L"タイトルバー", MB_OK);

**デフォルトの名無しさん** · 2021/08/26(木) 19:19:53.55

>>756
自分がどう書いたのかソースそのまま出して