Win32API質問箱 Build127
>2以降の各リンクDAT落ちチェックしてたら、どのスレも停滞してて生きてた
化石過ぎるやろ
というかこいつら要らんやろ
Win32API 永遠なり >>5
>Win32API 永遠なり
その通り
とどのつまりdllエクスポート関数の使い方が変わるだけ 結局C#とか使っててもWindowsである限りP/Invokeで使わざるをえない
.NETで全然置き換えできねえ まあC++のライブラリ呼ぶならC++/CLIの方がいいだろうけどWin32 API呼ぶだけならP/Invokeでいいな。 IsWindowVisibleは、上位のウィンドウのWS_VISIBLEも再帰的に調べてくれるのに対して、
IsWindowEnabledは、上位のウィンドウが無効でも自身が有効だとTRUEになってしまいます。
上位のウィンドウのどこかが無効なら自身も操作できないのだから、
一発で状態を返してくれる関数があってもよさそうなんですが、
自分で再帰的に調べないといけないものなんでしょうか。 親となるメインウィンドウからCreateWindowの8番目のパラメータで親（オーナー）ウィンドウハンドルを指定して作成した
別ウィンドウ（WS_CHILDWINDOWを付けず一般的なWS_OVERLAPED属性等を付けたもの）はGetParentで
親（オーナー）を取得できず、GetWindowでGW_OWNERを指定すればオーナーウィンドウが取得できます
このことから、これらのウィンドウは親子関係みたいですが親子とは言わないと思います
どう言えばいいのでしょう？
オーナーウィンドウと派生ウィンドウ？
今までは漠然と親子呼びしていたのですが、上記例ではGetParentで親ハンドルが取れないのに気付いたことと
EnumChildWindowでもWS_CHILDWINDOWが付いたものしか列挙されないことから疑問に思いました
CreateWindowの8番パラメータ説明でも parent window って書いてますし >>16
そこは見ていたのですが、「オーナー」と「所有」という直訳っぽいとうか特に「所有」
ウィンドウという言い方は聞かないので、そこは置いておいてみんなどう呼んでるのかと思った次第で
皆さん特に呼び分けてない感じなんですかね？
オーナーウィンドウはまだ呼ぶと思いますが 全く理解してないな
所有はそのままの意味。金魚のフンみたいなもの
親ってのはツリーデータ構造においての子に対しての親って意味だから全く別の概念 ふと疑問に思ったのですが、Win32GUIってWndProcを利用せずメッセージループ内で全て処理をするって可能なんでしょうか？
実験してみろって話かもしれませんが知ってる方いらしたら教えてください
そもそもなぜWndProcを一々呼び出す仕組みなんでしょう？
DispatchMessageとか呼ぶくらいならその場でメッセージSwitchしたり自前の関数呼ぶなりした方がよさそうなものですが 全メッセージをループで処理する必要が出てくる
ウィンドウAもBもCもダイアログAもBも
それでもやる？ 複数のウインドウを開いていると
メッセージループに複数のHWNDが入ってくる
そうなるとHWNDで鬼のようにelse ifしまくって
さらにそれぞれメッセージIDでswitchだ
想像を絶する巨大WinMainになるぞ >>20
その場合、すべてのメッセージに対応する動作を自前で把握し処理しないといけない
しかもウインドウごとに微妙に違う部分もすべて適切に自前で処理する必要が出てくる
デフォルト動作でいい部分はデフォルト処理に任せる、それがWndProc
開発者は変更部分のみ追加するだけで済む >>21-23
完全に納得しました、有難うございます
WinMainスタック上のオブジェクトをそのまま利用出来たら、思ってそう考えましたが明らかに割に合いませんね
素直にWndProcとDispatchMessageに任せる事にします >>13
うーん「手前ウィンドウ」？
最初のウィンドウズではPOPUPウィンドウがないからはみ出さないウィンドウを子供と呼んでいたが
後からオーバーラップが自由にできるようになって用語がごちゃごちゃになってしまったんじゃないかな
知らんけど >>25
公式が特に何かしらの呼称を設けてないみたいだし誰も分からん気はする
親子じゃねえよ分かってねえなあ〜って知識マウント？しか湧いてないのが証明してる
知らんけど Zオーダーにまつわる 親子関係と
キーボード入力やらの取り分の範囲にまるわるオーナー関係 >>17
>>16の英語原文で斜体になっている「parent」「child」「owner」「owned」の4つがマイクロソフトの公式用語
owner windowの日本語訳は普通に「オーナーウィンドウ」が定訳だと思うよ
一方、owned windowは定訳が存在しないね
マイクロソフトの日本語機械翻訳では
owner window = 所有者ウィンドウ/オーナーウィンドウ
owned window = 所有ウィンドウ
となってるけど、この後者はあまり良い訳ではないと思う >>20
なんかわかります
中で何やってるのか理解していないと気持ち悪い、みたいな
私は最初の頃、MFCとか触れなかったし(今も)、WinMain?mainじゃだめなの？とか
cランタイムのstrcpyがあるのに、Win32APIのlstrcpyがあったり、摩訶不思議でした 昔のwin16はfar版とかnear版とかあってめんどくさいからlstrcpyを用意したんじゃなかった ニヤは無視すればいいだけじゃん？
どっちかというとlstrcpyW()の必要性からだと思う タスクトレイのアイコンの上でマウスホイールを上下させて音量調整できるフリーソフト見つけたんだけど、
あれ、どうやっているんでしょうか？
タスクトレイの表示座標を取得して、フックすればいいんだけど、座標を取得する方法がわからない。
それともタスクトレイのアイコンでもホイールのイベント取得できる？ Shell_NotifyIconだよね？
WM_MOUSEWHEELはこないね SetWindowsHookEx(WH_MOUSE_LL) じゃないかな
dumpbin.exeとか使ってそのソフトが呼び出してるAPIを調べてみるといい Shell_NotifyIconのuCallbackMessageにメッセージID登録するとでLPARAMからMOVEとかのマウスイベントがやってくる
マウスがアイコン上をホバー中かどうかはこれで判定する
タスクトレイの長方形はFindWindow("Shell_TrayWnd",NULL)で取得したHWNDからGetWindowRectで取れる
その中の自分のアイコン長方形の取得の方法は昔調べた限りでは見つからなかった
従って、上のイベントが初めて起きた時にGetCursorPosで座標を取得しておき、
タイマーでマウスがその座標周辺にいるかどうかを大雑把に監視しつつ、
フック側のホイールイベントでトリガするという処理になると思う 富士通「年収3500万円」の衝撃 ソニー、NECも戦々恐々の「グローバル採用競争」
「富士通年収3500万！」日本のIT企業の年収も、高額化してきました
ゼロから起業するよりも事業承継（小さな会社の買収）が圧倒的に有利である3つの理由
「エース人材だって起業OK」、NECは挑戦者が集う場をつくる
NECなど「出向起業」 大企業人材、起業しやすく
パナソニックの社内ベンチャー「ゲームチェンジャー・カタパルト」で
事業化されるかもしれない注目の新規ビジネス
ゼネコン鹿島､DX化で狙う建設業界の地殻変動
NTTドコモ、建設業向けDXの新会社 コマツ、野村総合研究所などと共同で >>33
＞ タスクトレイの表示座標を取得
面白そうなネタなんで探してみたら、こんなのあった。
ttps://www.petitmonte.com/bbs/answers?question_id=25298 >>34,35,36,38
レス、ありがとうございます。
昔、自作の音量調整ソフトで実装断念した機能でした。
久しぶりにプログラミングやってみます。 10標準じゃもう使えないよ
分解するツールでばらした記憶がある ヘルプファイルの仕様をコロコロ変えるの迷惑
HLPだって制限付きならともかく全面廃止は横暴すぎ CHMの後継になるはずだった「Microsoft Help Viewer」だけど、Visual Studio 2015のヘルプファイルがリリースされてからまったく更新がない。
「Microsoft Help Viewer」はCHMよりも先にオワコン化しそうな気がするんだけど。 CHMはWindows用Python3.xのヘルプファイルに採用されているのでまだまだ現役だと思いたい 今時ヘルプは全てWEBで見ろオフラインなんか知らんスタイル感
WEBに飛ぶと404でトップページにリダイレクト感
ユーザーはヘルプ読む労力が辛い感と開発もヘルプ更新するのに疲れ切ってる感 >>42
HLPは全面廃止と言うよりある意味制限付きでは？
うちはWindows10だけどHLP現役よ *.hlpを分解できるツールとかないの？
hlpファイルの詳細な仕様書でもいいけど HTMLヘルプは、アプリのヘルプとしては使わないというか使えない
要求仕様を満たすための形式的な役割で使うだけ >>51
「HTMLヘルプ」は何を指すの？
CHMではなく汎用的なHTML文書という意味で言ってると仮定させてもらうけど、
天下の「Git for Windows」のヘルプがhtmlファイルをWebブラウザを開く形式で提供されていることについてどう思うの？ ヘルプとマニュアルの仕切りがどこにあるかわかりませんが
使用中にピンポイントにその使用方法を提示できるんであれば、それでいいんじゃね？ 一例を挙げると、git log --help とコマンドプロンプト上で入力したらWebブラウザが起動して以下のHTMLページが表示される変態仕様、それがGit for Windows
file:///C:/Program%20Files/Git/mingw64/share/doc/git-doc/git-log.html >>50
素人受けするものがいいでしょうね
┌────────┐
│何を調べますか？│
│|￣￣￣￣￣￣￣|│
│|お前を消す方法|│
│|＿＿＿＿＿＿＿|│
│[ｵﾌﾟｼｮﾝ][ 検索 ]│
└─────ｖ──┘
＿_／|_
＿／ ＼
〈―― ● ＼
￣＼_＿＿ ヽ
/＞―｜ヽ―-､|
＼|￣＼|_
(人_) >>54
それをGUI操作の提示方法としてどう実装するかですね
操作仕様を考える時点で考慮してたかどうかでだいぶ変わる chmは表示にIEのコンポーネント使ってると思うんだけどサポート期間終了したらどうなるんだろう
あとUnicode対応じゃないんだよね
本文UTF8で書くと検索できないしインデックスもUnicode系統は使えない コマンドプロンプトで、start a.html
とすれば、ブラウザが開く
相対パスで、start ./x/y.htm
とか 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);で更新されるようになりました
ありがとうございます 
