Win32API質問箱 Build127
CHMって検索が不便だった気がする
分解してHTMLをGREP掛けた方がいいとかそんな感じ WM_NOTIFYメッセージで以下のように lParam を LPNMHDR と LPNMTBCUSTOMDRAW の2つにキャスト可能です。継承などもしていないのになぜキャストできるのか理解できません。どいう仕組みでキャストできているのでしょうか？
LPNMHDR pnmh = (LPNMHDR)lParam;
switch (pnmh->code) {
case NM_CUSTOMDRAW:
{
LPNMTBCUSTOMDRAW lpNMCustomDraw = (LPNMTBCUSTOMDRAW)lParam; そもそもC言語のポインターキャスト自体は通常どんな構造体や型でもエラーなしでできる
ただし正しく動く保証はない(プログラマの責任)
でその2つの構造体は包括関係になっててNMHDRのメンバーの部分が共通ってこと
NMHDRの後ろにNMTBCUSTOMDRAW固有のメンバーが並んでる構造のはず ShellExecuteを使うと、拡張子に関連付けられたアプリで開けるけど、
「このファイルを開く方法を選んでください」の画面を出す方法はありますか？
メールアプリなどは、添付ファイルを右クリックすると、
「開く」の他に「アプリケーションから開く」のようなメニューもあって、
それを選ぶと上記の画面が出てくるので、なにか方法はあると思うのですが >>65
動詞"openas"かな？
試したことないけど >>67
ShellExecuteの第2引数に_T("openas")を入れてみましたが、
戻り値が0x0000001F(SE_ERR_NOASSOC)になってしまいました >>65
コマンドプロンプトからこれで表示は確認できた
%SystemRoot%\system32\rundll32.exe %SystemRoot%\system32\shell32.dll,OpenAs_RunDLL ファイルのフルパス名
これをプログラムから実行するのは適当な方法でいけると思う コマンド呼び出し文字列を変更する手段を用意しとかないと、使えなくなった時に積むでしょ >>70
俺に言ってるのかな？
何言ってんのか判らんけどpowershell上からpinvoke経由でも普通に呼べるけど >>69
このヒントを元に探してみたところ、WinMergeのソースが見つかりました。
GetSystemDirectoryやShellExecuteを使って、全く同じことをやっていました。
ありがとうございます。 どうも話が通じない人みたいだから俺は去るね
>>65に伝わればそれでいいので >>74
Win32APIスレなのにUndocumentedな話してるからだが 原理的にこれ相当でできるって話だからスレチではない
意味が伝わってないどころか会話も通じていないコイツのスレチを超える常軌を逸した脳味噌に驚愕する 公式な仕様として公開されてない機能を使う時は要注意だし、
サポート打ち切りを想定してコマンド呼び出し文字列を変更する手段を用意しておくのは当然だろ。 公式サイトに乗ってないからここで質問してるんでしょうが
多少のリスクは自己責任だ 行きはよいよい 帰りはこわい
こわいながらも
通りゃんせ 通りゃんせ
関東で生まれた童謡ってのが意外だよな サポート打ち切りや仕様変更によって開発したソフトやユーザーがどのような影響受けようが、
このスレ的には大きなお世話としか言いようがない
エラー処理は自己責任でやるだけだ
問題の糾弾は元凶であるMSに言え 代替案を示すでもなく大昔から変わってない方法にケチつける時点でノイズ _beginthreadで作成したスレッドが、後で親プロセスから見て生きているかどうかを調べる方法はありますか？
基本的にずっとループして生きていることを期待しているスレッドですが、何らかの不具合でスレッドが異常終了した
ことを親プロセスで検知したいのです
スレッド側でシグナルオンオフしたりグローバル変数で動作してることを常に書き込むなどの工夫は思い付きましたが、
そもそもスレッドハンドルを使って有効か無効かを知る方法があれば簡単なのですが、そのような方法はありますか？ >>85
_beginthread でなく CreateThread でスレッド作成し、スレッドハンドルを受け取る
スレッドハンドルはスレッド停止でシグナル状態になる
スレッドハンドルの状態を WaitForSingleObject で監視する >>86-87
頂いた情報を元に色々テストしてみます
どうもありがとうございました _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
やっぱ必須ですかぁ
すらすら読めないときついレベルですか？
辞書使ったり、グーグル翻訳使わないときついです。 
