Win32API質問箱 Build127
_beginthreadexで作成して
GetExitCodeThreadは？ _beginthreadはCランタイムを使うために必要なメモリ処理を追加したCreateThreadのラッパーらしいのと、
WaitForSingleObjectでの監視はこれまでも問題なく動作していたので、_beginthreadのままタイマー監視で
WaitForSingleObjectのテストしてみました
スレッドの異常終了に対応できるのかはテストできません（異常終了の再現はどうすれば？）のでスレッド途中で
特定条件で_endthreadを実行しただけですが、これは当然でしょうが問題なくWAIT_TIMEOUTの判定でスレッド状態を検知できました
同じく、WaitForSingleObjectの代わりにGetExitCodeThreadに置き換えた場合、スレッド動作中は
STILL_ACTIVEの判定、スレッド停止中はGetExitCodeThread自体がエラーで返ってくることでスレッド状態の検知ができました
（スレッドは永久ループで戻り値を返しませんから、threadex系を使っていません）
_endthreadを使ってのスレッド途中終了ではなく、異常終了時も同じように動作するのかが不安材料ですが、
とりあえずこれでOKということにしておきます（スレッドが動いていないんだったら各APIも同じ動作では？という判断）
どうもありがとうございました _beginthreadexはCreateThreadと同じハンドル返すやつやぞ
スレッド内でCランタイム使う場合こっち呼ばないとダメとか教わったりしてないのか
技術の断絶が起きてるのか >親プロセスから見て
子プロセスのスレッドのハンドルって親プロセスから見えるの？ 文脈的にスレッドから見て起動元を親プロセスと呼んでるだけかと 1秒おきのタイマーでtmDraw()を呼んで右に伸びる四角を描くプログラムです。VSCでMFC未使用。
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_PAINT:
OnPaint(hWnd);
break;
case WM_CREATE:
SetTimer(hWnd,1,1000,(TIMERPROC)NULL); //タイマー定義
break;
case WM_TIMER: //タイマー
{
PAINTSTRUCT ps;
HDC hdc = BeginPaint(hWnd, &ps);
tmDraw(hdc); //これを呼んで描画
EndPaint(hWnd, &ps);
}
break;
return 0;
}
static VOID tmDraw(HDC hDC)
{
SetDCPenColor(hDC, RGB(0x99, 0x66, 0x00)); //ここが呼ばれてるのは確認
SetDCBrushColor(hDC, RGB(0xFF, 0xCC, 0x00));
Rectangle(hDC, SIZE16(0, 0, cx++, 6)); //伸びる描画
}
最初の1回の描画はされます。タイマーでtmDraw()が呼ばれてるのは確認しています。
呼ばれて描画されてるはずなのですが、実際の画面は更新されず四角は伸びません。
windowサイズを手動で変えていくと四角は右に伸びていき更新されます。
タイマーでtmDraw()が呼ばれた時に描画だけでなく画面の更新もされるようにするにはどうすればよいですか？ WM_TIMERでメモリDCに対してtmDrawの内容で描画、更新が必要な長方形に対してInvalidateRectを呼ぶ
WM_PAINTでBeginPaintの処理するが、ここではBitBltで更新が必要な長方形に対しメモリDCから画像転送だけするのがセオリー
WM_PAINTで直接描画してもよいが、WM_PAINTはイベント発生タイミングがOS依存のためタイマー以外でも必要時毎回tmDrawが呼び出されることになり時間が掛かる描画をここでやってると糞アプリ認定が俺からされる それと下みたいな描画処理内に状態を更新する処理を入れるのはタブー俺からど突かれる
>Rectangle(hDC, SIZE16(0, 0, cx++, 6)); //伸びる描画
tmDraw(); // 描画
tmUpdate(); // 状態の更新
に分けて、tmUpdate()内でcx++;を記述するべき WM_TIMER:でInvalidateRect(hWnd, NULL, NULL);で更新されるようになりました
ありがとうございます >>33
Shell_NotifyIconGetRect CreateFileで返ってきたファイルハンドルを使って、CreateFileでGENERIC_READ/GENERIC_WRITEの
どちら（もしくは両方）のアクセスモードが指定されていたかを調べる方法はないでしょうか？ 質問を撤回変更します
特定のファイルへの書き込みの際、同タイミングで別プロセスから同じファイルへの書き込みを防ぐため
ファイルのロックを行なおうとしましたが、下記のようなコードは間違っていますでしょうか？
実際にはWriteFileでエラーになります
HANDLE file;
BOOL ret;
DWORD wrote;
OVERLAPPED ov = {0};
file = CreateFile("test.dat", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
ret = LockFileEx(file, 0, 0, 0xffffffff, 0xffffffff, &ov);
ret = WriteFile(file, "aaa", 3, &wrote, 0);
ret = UnlockFileEx(file, 0, 0xffffffff, 0xffffffff, &ov);
CloseHandle(file);
よろしくお願いします 補足します
>>103は複数プロセスで実行しての結果ではなく、単一プロセスで実行した結果です
自プロセスでファイルに書き込むけど、その間は他プロセスで書き込んで欲しくない
ということをしたいですですが、競合しているわけでもないの人>>103ではエラーになってしまいます >>104
FILE_SHARE_*を見てみるといいよ。 やりたいことが伝わっていないようですが、要するにWEBサーバーでよくある
アクセスカウンターや掲示板でファイルの読み書きをするにあたって衝突を防ぎたいということです
ファイルオープン時にエラーにしてしまうのは本意ではなく、あくまでファイルのロックで制御したいのです
ということで、書き込み時はこのようにすれば解決できました。
ret = LockFileEx(file, LOCKFILE_EXCLUSIVE_LOCK, 0, 0xffffffff, 0xffffffff, &ov);
読み込み時は元の
ret = LockFileEx(file, 0, 0, 0xffffffff, 0xffffffff, &ov);
このようにすれば、複数プロセスで読み込みが競合しても同時アクセスが可能で、書き込みプロセスが発生したときは
意図した通りに排他処理され、後から実行されたプロセスはLockFileExで待機されるようになりました Webサーバの排他処理を、このような実装で提案してくるレベルの会社に仕事を頼むのは危険、とは思った CreateFileが先だとどのみちエラーになる可能性が残るから
ミューテックスやイベントオブジェクトで排他制御するなあ
Lockなんちゃらは使ったことないわ 俺なら迷わずDBMS使うわ
SQLite3 とかならサーバーもいらんし >>109
shareが付いてるからエラーにはならないのでは？ WritePrivateProfileString で ini ファイルに書き込むと、たまに「他のプロセスが使用中です。」という例外が発生します。
防止するにはどすればいいでしょうか？ 大体にして開いてるのエクスプローラー、アンチウイルス、常駐系だったりするしな
MS-DOSでも使うしか 他のプロセスでiniファイルを使っていたとしてもWritePrivateProfileStringで例外なんか出るか？ ぐぐった感じ APIそのものは例外を発行しないものの C#のプラットフォーム側がだしてるくさい リストビューを範囲選択しているときの四角形、7や10などでは青い半透明で描画されますが、
APIでこれと同じものを描画することはできるのでしょうか？ だから自前で同じものを描画できるかって質問だろ
俺か？俺は知らん！ >>119
自分で色などを調べて、直値で半透明の四角形を描いたということですか。
XP以降のエクスプローラーに載っている描画のようなので、
UxThemeのテーマ描画関数にでも含まれているのかと思ったのですが、
外からは呼べないものなのですかね。 >>120
自前じゃなくてAPIでって書いてるやん
>>121
正攻法は分からないので、それっぽい色で直接描画した
参考にならなくてスマン
ワイもいい方法知りたい
DrawThemeBackgroundでリストビュー関係のパーツで描画をすればかなり近そうなんだけど、
本当にそれでいいのか分からなくて面倒でスルーした
https://docs.microsoft.com/en-us/windows/win32/controls/parts-and-states
こちらのツールも参考にさせてもらってた
ttp://dev.onionsoft.net/seed/info.ax?id=1201
で、結局描画そのものは自前になるわなということでやめた >>122
詳しい情報ありがとうございます。
テーマに沿った範囲選択の描画は、提供されていないものなんですかね。
DrawDragRectのような名前のAPIが用意されてよかったのですが。 NamedPipeにおけるPIPE_TYPE_BYTEとPIPE_TYPE_MESSAGEの違いは何なのでしょうか？
PIPE_TYPE_BYTEでは書き込み側がWriteFileを何回行ったとしても読み手側はReadFile1度で済み、
PIPE_TYPE_MESSAGEでは書き込み側が行ったWriteFile回数分、読み手側もReadFileがヒットするという理解であってますか？ 参考書を一冊読み終わった程度のガチガチの初心者です。
初めて何か簡単なものを作ろうと思ったのですが、ウィンドウのサイズの指定の仕方が良くわかりませんでした。
VisualStudio2022でテンプレートはユニバーサルWindows-C++/Cxです。
どなたかwinndowの大きさの指定の仕方を教えていただければ幸いです。
そもそもどこからプログラムが始まるのかもよくわかっていません。
・・・質問する場所が間違ってたらすみません。 Win32APIなら MoveWindow あたりかな。
UWPのことは↓の方がいいかもね。
https://mevius.5ch.net/test/read.cgi/tech/1627556967/
なお蛇足だけど 「UWP 将来性」 でGoogle検索してみると、UWPに関しては微妙な評価も少なくなく。
初心者が、あえてUWPを選んで、これから勉強していく・・・というのはどうなんだろう？ という気はしないでもない CreateWindow(Ex)のwidth,height引数だろ ウィンドウのサイズの指定の仕方すら載ってない参考書って何なの ウィンドウのサイズはWindowsのプログラムじゃないんだよ
うまく言えないけど、それは違うんだよ 自分で制御できてこそプログラミングなのでは
ちなUWP ウィンドウサイズでぐぐったら出てくるでしょ UWPなんて儲からないのが決定づいたからMSの投資対象じゃないでしょ
将来性とかじゃないんだよ
終わったの >>126
ありがとうございます。
なんか記事めっちゃ少ないなって思ったんですよ。
c++始めたてで「よし、c++でサーバー作るぞ！！」って思って探したとき以上に
記事がないんですよ。
そもそも将来性が危ぶまれていたのですね。
本当にありがとうございます。
テンプレート何使うのかから考え直します。 Visual studio のテンプレート選びのことなら、最初だけね。
慣れてくると、テンプレートはかえって邪魔だったりするので、空のソリューションから始めるようになるよ。
C++でいくなら（初心者なら、最初はC++よりもCの方がいいかもしれないかな、覚えることが少ないので・・・とは思うけど）
（MFC等のクラスライブラリを使わずに）Win32APIだけでゴリゴリ動かすプログラム作成からトライするのがよろしいかと。
いずれにせよWindowsアプリの場合、Win32APIは避けて通れないので、勉強するなら順番的に最初で。
それで不満があったり、学校や仕事なら必要に応じて、趣味なら好みで、他の手法に手を出していくような順番で考えるといいと思われます。
困ったら Google 先生に聞いてみてね、いくらでもサンプルが入手できるから、理解も早まるはず 承知しました。
templateの作成から始めます。
ありがとうございます。 いやー、普通にc#から入っていいとおもうがねぇ。
まっさらな人がこれからcharとwcharとutf8とutf16を
ちゃんとデフォルトで言語の標準ライブラリで変換出来ない世界から入るのは遠回り過ぎて、
結局は目的にまったく近づけず挫折するかと。 何でrustの悪口言うの？
Microsoftがいつかライブラリを作って提供してくれるはずだよ？ >>140
もう使えますよ
tps://store.steampowered.com/app/252490/Rust/ >>138
どうも、134です。
インターネットとc++は相性悪いからやめとけって言う話は自分でも
どことなくわかっているはずなのになぜかc++に執着してしまっています。
はじめて3か月くらいでしょうか・・・。
boostのサーバーのサンプルコードの一つの中身を片っ端から読んでみようかと思いましたが、
なんかOSどれか調べてるなぁとか、c++のバージョンチェックしてるなぁとか、
このヘッダインクルードしてたらこっちはインクルードしないよーとか、
この関数ちゃんと動くの？とか
実際に知りたかったことにたどり着く前にboostには挫折してしまいましたが、
c++には”まだ”挫折してないです。
・・・”まだ”なんだよなぁ そんなわけで、DialogBoxの引数なんですが、LRESULTだったり、INT_PTRだったりします。
long以上の整数ポインタだったら何でもよいのでしょうか？ ごめんなさい、全然違いました。
DialogBoxの第四引数につかうウィンドウプロシージャの
DialogProcの型はlong以上の整数型ポインタなのでしょうか？
また、ウィンドウプロシージャって関数であってますよね？
実はクラスでしたとか言わないですよね？ DialogBox の第4引数はダイアログプロシージャー（関数）のアドレス値（ポインタ）だね。
Type: DLGPROC
A pointer to the dialog box procedure.
なお、ダイアログボックスの場合は「ダイアログボックスプロシージャー」といって。
ウィンドウプロシージャーとの共通点は多いけど、同じものではないから、区別して理解する必要があるよ。
DLGPROC と WNDPROC の違いについて調べてみてね >>145
補足含めて有難うございます。
WNDPROCも調べます。 20年以上前まではWin32APIに関する本は山ほどあったけどもうそういう時代じゃないから今すぐ辞めたほうがいいよ
一応20年以上前の知識が今でも通用はするけど知ってたらちょっと得する程度で今は他にもっといい手段があるからね
生まれてくる時代が遅すぎたね 日本語ではね
英語ならPavel Yosifovich氏のWindows 10 System Programming, Part 1 と 2 が有る
Pavel Yosifovich氏はインサイドWindowsやWindowsカーネルドライバプログラミングの原著の人だ
誰か翻訳してくれればいいけど、今更Win32本を翻訳したいと思う酔狂な人は居ないだろう… バカ言うなよ
Win32APIはずっとこの先生きのこる >>148
おまえは英語を読めないのか？読めたとしてもマイクロソフトは解釈が難しい表現ばかりだから、日本マイクロソフトでもわからないことばかり。 WIN32APIの本なんか読んだ覚えがない
Win32.hlpとグーグル検索だけでマスターした
もう２０年も使ってるが一番長生きでコスパ最強の言語だわ Advanced Windowsだけは読んでたな
15年くらい前から1に書いてあるよね
思えば遠くに来たな… >>150
英語を読めないなんて一言も書いてないだろ >>1 > ・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
これ古いよな
APIフックもネット上の情報を組み合わせるだけでできる Advancedと言いつつペゾルト本よりよほどプリミティブな部分を網羅してくれてる書籍よね
邦訳版はもはや入手性悪いけど c++やるんだったら英語は必須なのでしょうか。
マイクロソフトのサイトに載っている説明もほぼほぼ英語ですし・・・、
自分は英語読めないんですけど、なんかもう、最近少しなら読めるようになってきました。
頭痛くなりますけど・・・。 >>156
うん、必須
IEEE14882の規格票が英語だから
JIS X3014はバージョンがもはや化石レベルだし アホミスしちまったｗ
- IEEE
+ ISO/IEC >>155
そもそも原題はAdvancedじゃないしな >>157
やっぱ必須ですかぁ
すらすら読めないときついレベルですか？
辞書使ったり、グーグル翻訳使わないときついです。 >>160
俺もそんなもんだよ
決して英語が得意なわけではないので
自分が誤訳してないかのチェックにグーグル翻訳使ってる
グーグル翻訳のほうがおかしいこともあるので相互補完だ エディットボックスの中のテキストをGetDlgItemTextでもらってきたのですが(TCHAR*)、
PCSTRに変換する方法がわかりません、便利な関数は用意されていなくて、自分で作ったほうが良いのでしょうか？
char*をwchar_t*に変換するのは見つかったのですが、その逆が出来ません。 >>164
GetDlgItemTextA?
GetDlgItemTextW?
A ならそのまま使えるのでは？W なら https://mevius.5ch.net/test/read.cgi/tech/1434079972/53 ::WideCharToMultiByte DeepL の方が、Google 翻訳よりも高品質
でも最近、Googleも向上した。
DeepLを真似たのかも >>163
DEEPLは翻訳できる回数に制限があると思って使ってなかったです・・・。
使うだけなら制限なかったのですね。 >>165
ありがとうございます。
Aの方使ったら出きるっぽいです。
なんですけど・・・今それを確認しようとしてmbstowcs_sを使ってみたけれど
文字化けが・・・どっかがミスッてるはずなんですけど、しばらくかかりそう。
とりあえずローカルウィンドウで見たらchar変数の中にバッチしがいってたので
当初の目的を解決できました。
こんなことで3時間くらい使ってしまいました。
頭痛い・・・。 文字コードについてはMSがもっとも時間かけて多言語対応してるからMSのルールを守るのが吉。 DeepLをMSが買収して、ドキュメントを全部高品質な日本語で提供してくれ いらんことはせずに昔のMSDNライブラリのように人に翻訳させろ。 文字列を入出力するAPIは末尾Wを使うよう心掛けよ 情報通信研究機構(NICT)も翻訳バンクを運用して、
「みんなの自動翻訳」を、Linux に技術提供している
みんなの自動翻訳＠TexTra®
https://mt-auto-minhon-mlt.ucri.jgn-x.jp/
漏れは使った事ないけど 文字や文字列の記述は TCHAR（_TCHAR） 系統のマクロで統一するのが旧来からの作法だわね。
最近の Visual Studio の C/C++ はデフォルトで UNICODE,_UNICODE が定義されているので。
APIの末尾にWを付けるというルールは忘れていい気もする。
必要時のみA（やW）を付けて、あとは WideCharToMultiByte、MultiByteToWideChar を使う程度かな TCHARなんかもう10年近く見かけてない。
普通にLとだけ書く。
マルチバイトにする意味ないんだし。 マクロの結果で分岐させるコードだと
インテリセンスとかに負荷かかる印象しかないから
気づくとW系のコードで埋まっている UTF8になったら、またマルチバイトに戻るわけではいの？ サロゲートペア対応とかで、特定のWin32APIの仕様が混乱してたりして、メリットが無くなってきてるからね。
将来的に ANSI/UTF8 がデフォルトになる可能性も完全には否定できず >>181
1バイト配列だった場合どっちで処理されるかの部分がチーム環境や実行環境に左右されたのて
十数年前から wchar_t で持つようにした 忘れてはいないからこそ忘れてる(OR 分かっていない)人が混ざった時の問題が怖いのよ プラットフォームによってはワイド版のPOSIX関数がなかったりするから微妙だなあ >>172
その「人」が確保出来ないから、放置されてんだよな
MSは金は余ってるが、翻訳に関しては全く予算を割くことは無くなった
日本のMSが、無能だらけになったのと関連してるのは間違いない ダイヤルボックスで指定したIPアドレスとポートで作ったソケットからちょっとした文字列を
送ろうとしたんですけどLNK2019エラーが出てしまいます。
VisualStudio2022、c++14、サブシステムはWindows (/SUBSYSTEM:WINDOWS)です。
エラー2019は何となくサブシステムが違うようなイメージで間違っていないでしょうか。 >>188
すみません、前回別の事で同じエラーが出たときに読んだんですけどよくわからなくて
マイクロソフト見てもわからないと思ったのですけど、もう一度読み直してみると、
何か忘れてるのかなぁって思ったので、もう少し頑張ってみます。 
