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 素人受けするものがいいでしょうね ┌────────┐ │何を調べますか?│ │| ̄ ̄ ̄ ̄ ̄ ̄ ̄|│ │|お前を消す方法|│ │|_______|│ │[オプション][ 検索 ]│ └─────v──┘ __/|_ _/ \ 〈―― ● \  ̄\___ ヽ />―|ヽ―-、| \| ̄\|_ (人_) >>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);で更新されるようになりました ありがとうございます >>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とグーグル検索だけでマスターした もう20年も使ってるが一番長生きでコスパ最強の言語だわ Advanced Windowsだけは読んでたな 15年くらい前から1に書いてあるよね 思えば遠くに来たな… >>150 英語を読めないなんて一言も書いてないだろ >>1 > ・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。 これ古いよな APIフックもネット上の情報を組み合わせるだけでできる Advancedと言いつつペゾルト本よりよほどプリミティブな部分を網羅してくれてる書籍よね 邦訳版はもはや入手性悪いけど c++やるんだったら英語は必須なのでしょうか。 マイクロソフトのサイトに載っている説明もほぼほぼ英語ですし・・・、 自分は英語読めないんですけど、なんかもう、最近少しなら読めるようになってきました。 頭痛くなりますけど・・・。 >>156 うん、必須 IEEE14882の規格票が英語だから JIS X3014はバージョンがもはや化石レベルだし アホミスしちまったw - 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 すみません、前回別の事で同じエラーが出たときに読んだんですけどよくわからなくて マイクロソフト見てもわからないと思ったのですけど、もう一度読み直してみると、 何か忘れてるのかなぁって思ったので、もう少し頑張ってみます。 クリティカルセクションで質問です EnterCriticalSectionでスレッドの排他制御を行うとき、 作成したスレッド間では排他制御できています これを、作成したスレッドではなく呼び出し元のプロセス側で EnterCriticalSectionを実行しても、その間はスレッドの動作は 排他制御されて停止する(待つ)という認識で間違いないでしょうか? 質問の意図が正しく理解できてない可能性がありますが。 A critical section object provides synchronization similar to that provided by a mutex object, except that a critical section can be used only by the threads of a single process. Critical section objects cannot be shared across processes. 要約: 「クリティカル セクション」 オブジェクトはミューテックス オブジェクトと同様な同期を実現しますが、 クリティカル セクション オブジェクトは1つのプロセス内のスレッド間でだけ使えます。 クリティカルセクションオブジェクトは、プロセス間で共有できません。 >>189 "何故" LNK2019が起きているかをぐぐったり他人に投げる前に確認しないと遠回りになりそう >>177 自分で勝手に W つけちゃだめだと思うよ… ちゃんと「windows.h をインクルードする前に」 #define UNICODE しているか確認してね C++11 or later になってからずいぶんと楽になりました… https://mevius.5ch.net/test/read.cgi/tech/1434079972/53 >>191 ありがとうございます > クリティカル セクション オブジェクトは1つのプロセス内のスレッド間でだけ使えます。 > クリティカルセクションオブジェクトは、プロセス間で共有できません。 これは認識しているのですが、この文面を借りれば 「クリティカル セクション オブジェクトは1つのプロセス(メインプロセス・スレッド呼び出し側)と スレッド(メインプロセスから呼び出されたスレッド)間で使えるのかどうか」 ということです よろしくお願いします >>195 複数のスレッドで使えると思いますよ、というか、そのためのクリティカルセクションでしょう? ただ、私もクリティカルセクションの使い方がまずいのか、スタベーションに悩まされたまま放置しているので、断言はできないけど なおちゃんとハンドルを static かヒープに置いていますか?スタック上にハンドルを置いていたら無意味ですよ… >>195 使えます(正しくコーディングされていれば 念のため補足すると、プロセスというのはスレッドの集合であり。 プロセス生成と同時にスタートするスレッドのことを「メインスレッド」と言います。 なので、より正しい言い方としては以下のようになると思われます。 ・メインスレッド ・(メインスレッドと同じプロセスに属する、メインスレッド等で生成された)メインスレッド以外のスレッド これらのスレッド間でクリティカルセクションオブジェクトを共有することができます(排他制御可能です) >>196 ありがとうございます 何か不具合が起きていると言うことではなくて、クリティカルセクションの 仕様について確認しようと思って質問しました 結局、そういうコードを書いて確認しましたが、メインプロセスではEnterCriticalSection が効きませんでした メインプロセスでEnterCriticalSectionを実行すれば、その間スレッドが止まる(その逆もある) ということがもしかして可能なのかなと思った訳です どうも失礼しました >>197 入れ違いになってすみません 使えるとレス頂いたのでプログラムを確認しましたが、これは書き方が 悪かったようで確認になってませんでした レス頂いた内容でとても分かりやすく理解できました どうもありがとうございました >>197 >念のため補足すると、プロセスというのはスレッドの集合であり。 全然説明になってませんよ… 次の質問にちゃんと答えられますか? 「プロレスごとに固有に持つ値はなにでしょうか、最重要な二つ答えなさい」 >>198 >そういうコードを書いて確認しましたが、メインプロセスではEnterCriticalSection >が効きませんでした コードを張ってください https://ideone.com >>201 >>199 で書き方が悪かったと言ってるから解決済みだぞ >>200 スタン・ハンセンとハルク・ホーガンかなあ。 プロレスについては詳しくないので、プロレススレで 1プロセス内に、複数のスレッドを起動できる。 1対多の関係 それら同一プロセス内の複数のスレッドを調停するのが、critical section じゃないの? >>204 まちがってはいないがアバウトすぎる… スレッド固有のデータは何? スレッドで共有するデータは何? 実は「ウィー!」と言ってなかった スタン・ハンセン雄たけびの真相: J-CAST ニュース https://www.j-cast.com/2015/10/08247400.html?p=all 2015年10月08日18時42分 🤘ウィー! ちと出遅れたが WinMainの第3引数は LPSTR UNICODE版はスレチ LPWSTR GetCommandLineW(); wWinMain(int, wchar_t**) はい論破 キーワード同士でカードゲームみたいに対戦している気分になってくるな… wWinMainは長いことmingwでサポートされてこなかったので WinMain function (winbase.h) https://docs.microsoft.com/ja-jp/windows/win32/api/winbase/nf-winbase-winmain Some programming frameworks might provide an alternative entry point that provides a Unicode command line. For example, the Microsoft Visual Studio C++ complier uses the name wWinMain for the Unicode entry point. 現在プリンタ選択ダイアログを自作していて、質問があります。 印刷コモンダイアログに表示されているプリンタ名はEnumPrintersで取得できたのですが、アイコンを取得する方法がわかりません。 どうすればアイコンを取得できますか? それ俺も知りたいわ どっかのプリンタ関連のdllにあるだろうけど あーCOMオブジェクトか C#でもサクっと書けないやつだな ウィンドウのリサイズイベント(WM_SIZE、WM_SIZING等)が来た時、ユーザーが直接そのウィンドウに対してリサイズを行ったのか、 ディスプレイ解像度等が変わり、システムの都合で結果的に変わったのかを判定したいと考えています。 ディスプレイ設定が変わった場合はWM_DISPLAYCHANGE等で判るので、 ユーザーが能動的にウィンドウをリサイズしたかどうかの判定ができればよいと思うのですが、 何か良い判定方法はあるでしょうか。 >>219 WM_ENTERSIZEMOVE WM_EXITSIZEMOVE >>220 よさげなメッセージがあったんですね! ありがとうございます! https://stackoverflow.com/questions/1826165/wm-entersizemove-wm-exitsizemove-when-using-menu-not-always-paired ここによると、WM_ENTERSIZEMOVEが来てもリサイズや移動がキャンセルされるとWM_EXITSIZEMOVEが来ない場合があるようで、 その場合でもWM_ENTERSIZEMOVE中のWM_CAPTURECHANGEDで終了が判定できるとのことです。 たしかにタイトルバーからサイズや移動をキャンセルするとそのような動きでした。 これで解決しそうです。ありがとうございました。 全ウィンドウを「並べて表示」したりした場合には対応してるのかい スケーリング変更で実質解像度が変わった場合もWM_ENTERなんちゃらが来るね WM_DISPLAYCHANGEも来るから区別は付くかな 画面端の四隅に独自スナップはやったなあ 吸い付くと気持ちいいのよね osの画面の位置設定が、吸いつくくせにぴったり揃わず微妙にずれる ふざけた動作だったな windows10になってから 座標を0,0にしても少し隙間が空くようになったのもふざけてる 10は枠が透明になったふざけた仕様 何の意味あんのあれ 最低限必要な処理性能を引き上げることで グラフィックボードやPCの買い替えを促進することができました。 実際AVX2未満だと256bit命令でまともな事ほとんどできないからHaswell未満切り捨てたくなる気持ちは分かる MSゴシックなどのフォントで、DrawTextで右寄せ(DT_RIGHT)の文字列を描くと、 イタリック体のときに右が欠けてしまうのですが、こんな仕様なのでしょうか? >>232 日本語のことなど真剣に考えてませんから そもそもMSゴシックを斜体にするのがダサいので、DrawTextとしても想定外という説 自力で右端を広げないといけないんですかね。 ただ、DT_WORDBREAKやDT_EDITCONTROLを付けて自動折り返しを設定していると、 どこで折り返されるかは事前に想定できないので、行末にスペースというのも難しそうです。 テンポラリのビットマップに描画して実測する関数作っとけば以後は気にせずに済む 使ったことないから知らないけどGDI+,DrawStringならどうなんだろうね アスペクト比を固定したいため、ウィンドウの最大化を完全に無効にしたいのですが、フレームをダブルクリックしたり、Windowsキー + ↑での最大化を塞ぐにはどのように処理すればいいでしょうか? >>248 ありがとうございます! 一度やってみたのですが、うまくいかなかったので、やり方がよくなかったのかもしれません Unityという特殊な環境が影響してるのかもしれないですが、、、 >>249 後出しですみません ドラッグでのサイズ変更は許可したいので、ウィンドウスタイルでは無理なのかなーと思ってます 今のところWM_SIZINGはうまく機能してるようです ムリだと思いますゥ~じゃねえよいいからWS_MAXIMIZEBOX抜けや ちゃんと抜いてんならそれだけで自動的にシステムメニューも含めて タイトルバーダブクリやWin+↑も無効化されるはずだがな メッセージループの入り口で WM_NCLBUTTONDBLCLK 等のメッセージを捨てればOK >>255 ありがとうございます ダブルクリックの方はこれで回避できるんですけど、Windowsキーの方がどうやっても防げなくて、、、 WM_WINDOWPOSCHANGING を拾えばいけるかなー >>254 Windowsキーの方は正確には、Windowsキー + SHIFT + ↑ ですね 正確には、ってかそれじゃ最初からスナップによるリサイズを防ぎたいって全然違う質問じゃん SYSCOMMAND監視して無理矢理引っぺがしたりはできるけど行儀悪すぎだから 任意のウィンドウサイズになってもボックスでレンダリングのアスペクト比維持した方がマシだな >>256 SPYでその時にどのメッセージ(多分複数)が来てるか調べて どれを捨てる or 改変すれば望みの動作になるかを考えろ 最大化はダイアログのスタイルにして抑止するのが定石だけど誰も書かないので一応 C#のFormBorderStyle = FixedDialog の時のウィンドウスタイル=0x16c80000 拡張ウィンドウスタイル=0x00050101 これでスナップの影響も受けないし、その上でサイズ変更もやりたければできる。 許容しつつアス比を維持するのもいい。ゲームのフルスクリーンモードとかそんな感じだろうし HINSTANCEかHWNDから、そのプロセスが貰っているコマンドラインオプションを知る方法ってある? GetWindowThreadProcessId使えばHWNDからプロセスID (pid)が得られるはずだ。 >>262 thx もう晩酌始めちまったんで 素面に戻ってからやってみるわ お、飯が炊けた 酢飯と酢の物作んなきゃ SetWindowPlacement, GetWindowPlacement を使ってウィンドウ位置の保存と復元をしています マルチモニター環境でも当該モニターで表示されていたウィンドウ情報の保存と復元が Windows10 以前では行えていましたが、 Windows11 になってからは、マウス操作しているモニターで全てウィンドウが表示されてしまいます これはプログラム側で何か修正が必要なのか、Windows11 上の設定(アプリのプロパティ?)が必要なのでしょうか? Windows11 でマルチモニターの仕様が変わったというのは分かりますが、具体的にどのように対応すればいいのか分かりません よろしくお願いします >>265 lengthメンバーはセットしているかな? 標準の仮想デスクトップとかも追加されてるのでちゃんと動くのかよくわからんよな >>266 構造体のゼロクリア、length メンバへの sizeof 設定は行っています 使用しているメンバは rcNormalPosition と showCmd のみです >>267 Windows11 では、モニターのオンオフで狂ってしまったウィンドウ位置の復元を するようになったという程度の知識しかありません(正しいかどうかも分かりません)が、 実機で色々テストするしかないかもですね(Windows11 にしたくない) ベータ以前の11のことだからバグかもしれないのがな 11.1で完成するOSなんだろうな 手元の開発環境を Windows11 & マルチモニターで揃えてテストしてみると問題は再現しませんでした これは問題が発生した環境依存によるものの可能性が非常に高くなりました お騒がせしましてすみませんでした 名前付きパイプで質問です。 Windows10(x64)で64ビットアプリ(サーバー)と32/64ビットアプリ(クライアント)でパイプ通信するのですが、クライアントが64ビットの場合は問題なし、32ビットの場合は動作したりしなかったっりで、サーバーのCreateNamedPipe関数のnMaxInstancesを1から255にしたら解消しました。 クライアントは1つだけなので1で良いと思ったのですが、何なんだろう? >>271 再現性なかったわ。 すまん、忘れてくれ。 プログラ厶の最低限の文法わかってる人間が、WindowsAPIを使用したGUIプログラムを作りたい場合に、おすすめの本ってありませんか? 正直WindowsAPIのハンドルとかハンガリー記法とかで面食らってぶつかってます。 > WindowsAPIを使用したGUIプログラムを作りたい そもそも止めとけ楽な道を進めと思うんだけど、なんで? > おすすめの本 今時そんな本あるのか分からないけど、猫でもわかるシリーズのWEBサイトでいいんじゃないの NT4.0や95の頃の書籍はメッセージやハンドル等丁寧な解説がされていたと思う >>273 その程度でなんで面食らうのか面食らってるが その都度ググっていけば充分じゃないかな Win32でGUIつくるならMsgCrackとRisohEditorを使うといいよ。 >>274 今まで他の言語で楽をさせてもらってたのは、他の方のおかげだと気付いて、実際に自分も勉強したいという思いです。 >>275 まさにおっしゃる通りで、先日なんとか相馬 俊治さんという方の本を見つけました、古い本のほうがわかりやすいです。 C#でもWndProcとかに手を付けると結局Win32APIレベルのメッセージループの仕組みの知識が必要だし C/C++でWin32APIだけ使ったメッセージループ検証用GUIアプリを用意しとくと捗るよ C++でクラス化ラップ化する前のピュアなメッセージループをなら猫かな そこから先は ラップしてるライブラリの方言が出てくるだろうし >>277 ありがとうございます!ツールももちろんですがこの作者のHP自体が非常に貴重ですね! >>279 ありがとうございます!ラップしてしまうとWin32APIの挙動が見えなくなるので、生で見える環境を用意しておいたほうが良いようなイメージでしょうか? >>277 RisohEditor良さそうやね 見た目レトロで良いからネイティブWin32で超軽量GUI作りたいってシーン結構あるから重宝しそうやわ MsgCrackにWM_DESTROYを入力すると void OnDestroy(void) って出てくる。 これを#include <windowsx.h>のHANDLE_MSGマクロと一緒に使うと吉。 統合環境の力技でマクロ埋め込んだりするしねぇ 癖や方言が強い いまさら MFC を使いたいんですけど、まずどうすればいいですか? >>284 windowsx.hで定義されてるHANDLE_MSG()マクロを使えば いちいちcase文を書く必要がない switch (uMsg) { HANDLE_MSG(hwnd, WM_CREATE, OnCreate); HANDLE_MSG(hwnd, WM_COMMAND, OnCommand); ... default: return DefWindowProc(hwnd, uMsg, wParam, lParam); } 使わないメッセージはスルーしていい OnCreate()やOnCommand()のプロトタイプもwindowsx.hで定義されてるので引数を間違ったらエラーで教えてくれる #define BEGIN { #define END } に近い感じなので マクロにお任せってあまり好きではない(個人的感想) こういうシステム的な部分を作るとき厄介なのが細かい引数間違えたりすることなのですべて定義されてるのは助かるよ windowsx.hに入ってるってことはMS推奨なんだろうし そのヘッダか忘れたけどコモンコントロール系はマクロが無いとやってられん それ前提でMSDNにリファレンスがあるし そういえばバイナリエディター「Binary Editor BZ」はWTL使ってたはず 大きな文字や小さな文字をコマンドプロンプトに同じ行で表示したいのですが可能でしょうか? 設定で変えるのではなくプログラムで結果によって変えたいのですが よろしくお願いします。 8pt ■ ■ ■ ■ ■■■■■ ■■■■ ■ ■ ■ ■ ■ ■■■■■■ ■■■■■■ ■ ■ ■■■■ ■ ■ ■ ■ ■■ ■ ■■ ■■■■ ■ ■■ ■■ ■■ ■ ■■■ ■■■■ ■■ ■ ■■■■ 16pt ■ ■ ■ ■ ■■ ■ ■■■ ■■■■■■■■ ■■ ■■■■■■■ ■■■■■■■■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■■■■ ■■■■■■■■■ ■ ■■■■■■■■■■ ■■■ ■■ ■■■ ■ ■■ ■■■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■ ■■ ■■ ■■■■ ■■ ■■■ ■■■■■■ ■■ ■■■ ■■ ■■■ ■■ ■■■■ ■■ ■■ ■■ ■■ ■ ■■ ■■■ ■■ ■■■ ■■■ ■■ ■■ ■■ ■■ ■■■ ■ ■■■■ ■■ ■■■■■ ■■ NFT市場が2年で300億円→2兆円に急拡大したワケ 「保有する」だけではない、アート作品につけられた「価値」 市場規模ですね。これは少し古いデータになりますが、直近では、だいたい 2兆円ぐらいの市場規模になります。去年の3月ぐらいから盛り上がってきて、 2019年は300億円ぐらいと言われていたものが急拡大して、今や2兆円と なっています。 一番大きいのが「コレクティブル」というものです。実際のNFTでいうと、 「CryptoPunks(クリフトパンクス)」とか「Meebits(ミービッツ)」など、 デジタルアートで、これが76パーセントを占めています。 他にはゲーム、スポーツの会員権のようなもの、メタバース上での利用、 アートなどに使われています。 >>297 いえ、フォントのサイズです。 >>299 色も変えたいので見てみます。ありがとうございます。 >>300 そうですか。ありがとうございました。 >>291 >windowsx.hに入ってるってことはMS推奨なんだろうし 20年くらい前なら同意するが 今はもう非推奨 知識としては必要だが、最初から最後までフレームワーク使わずにWin32だけでやるのは時間の無駄だろう。 >>309 フレームワークの学習コストはどのように評価しますか? この先そのコストを回収できるくらいプログラミングする見込みがあるかどうか次第だな。 そのWin32APIのラッパーとなるべきフレームワークがことごとくゴミなんだもんよ MS金余ってんだからQtでも買っときゃよかったのに >>312 学習した結果フレームワークがうんこだったと自覚したときの絶望感を、学習前にどのように織り込めばいいですか? 素のwin32と既存のフレームワークと自前のオレオレフレームワークのどれが一番うんこか次第だな。 win95時代にCで作ったハンドルメモリリーク検知付きのフレームワーク()があるけどいまだに世話になってる 新規でならC#で適当に作るがアプリの寿命を考えるといまだに上記フレームワーク()になるだろう 男なら誰しも自分だけの車輪再発明・・・じゃなかったフレームワークを心に持つよな wxWidgets、DelphiのVLC、それの模倣のLazarus Component Library (LCL)位が今でも活発に開発されてるWin32フレームワークか。 wxWidgetsとC++Builder(VCL)には散々世話になった。 >>317 メモリーリークは https://mevius.5ch.net/test/read.cgi/tech/1652160275/365 に一晩でちょいちょい、て書いたやつを貼ったら沈黙されてしまった… 普通誰でもそうすると思うのに、rust! rust! と連呼されてもねえ でもハンドルリークは考えたことなかったなあ… >>321 > 沈黙されてしまった… 相手されてないだけかと... オレオレライブラリ作って悦に入るのは初心者レベル2のやること 経験しておくとライブラリの手抜きがわかってシステムのバグを予想しやすくなるけどな >>318 「車輪の再発明だから駄目」という理念は、先に進んでいるアメリカに有利な言葉。 後発者が上に上がって来ささないため、メンタルからくじく。 アメリカはそういう国。 Googleは車輪の再発明しかしてないけどな 検索だって最初じゃない その代わり頭の良い奴らが本気でやるから良いものになる 日本が得意としてた事だったがな 頭の悪い人が足引っ張る法律作って海外に先を越されるパティーン >>331 彼らは、自分達が造ったものを遣わせてやりたいから「これ以上の再発明はするな」 と言ってくるが、自分達も実は再発明した結果であることは棚に上げている。 ここで車輪の再発明の指摘は的外れ 発明なんて一切してない 他人の成果物をソース読んでないからといって横取りする傲慢野郎 いまさらソフトウェア開発競争を国家間の諍いの次元でしか捉えてないやつは 一行もプログラム組んでないのがアリアリだねw 国家間というより、先に作ってしまった人が他人に別のものを作ってもらいたくない 心理が働くと、「車輪の再発明禁止」という如何にもまっとうなことらしき標語 となる。 車輪の再発明禁止は高機能なソフトウェアをオープンソースにするということで囲い込み、再発明させる気を起こさせなくしてる オープンソース文化が強いものを更に強くしてしまってる 作って楽しそうなものなもものの内、芸術性を伴わず技術だけで 作れるようなものはほぼ全てオープンソースで無料になってしまっている (フォトショップみたいな高機能なものは除く)。 再発明をしないまでもその部品と構成や仕組みを知っていると高機能なアプリ開発などへの機転や応用が利きやすいと思う 以下のコードが動かなくて困ってます。 pgfFrame = AVIStreamGetFrameOpen(paviStream, (LPBITMAPINFOHEADER)AVIGETFRAMEF_BESTDISPLAYFMT); AVIStreamGetFrameClose(pgfFrame); ←これを実行したら落ちる AVIStreamGetFrameCloseを実行しなくても動くのですが、再度Openした時に少しずつメモリを食いつぶして行くので困ってます。 止まった時にVC++の実行ボタンを再度押すと、内部で使ってるDLLがアンロードされてその後は動くようになります。 そうなると何回でもOpen→Close出来る様になり、メモリも食いつぶしません。 どうしたらいいんでしょうか? >>339 AVIStreamRelease (こっちは自動 Close してくれるとのこと) >>341 詳しく書くとこうなってるんです。 AVIStreamGetFrameCloseだけ落ちるんで困ってます。 これを実行しなくても動くのですが、複数回Openするとどんどんメモリを食いつぶすので困ってます… AVIFileOpen(&paviFile, FileName, OF_READ | OF_SHARE_DENY_NONE, NULL); AVIFileGetStream(paviFile, &paviStream, streamtypeVIDEO, 0); pgfFrame = AVIStreamGetFrameOpen(paviStream, (LPBITMAPINFOHEADER)AVIGETFRAMEF_BESTDISPLAYFMT); if(pgfFrame != NULL){ AVIStreamGetFrameClose(pgfFrame); } ←これだけ落ちる if(paviStream != NULL){ AVIStreamRelease(paviStream); } if(paviFile != NULL){ AVIFileRelease(paviFile); } そういう不具合が出るけど是正が困難な処理は別プロセスとして動かして終わったらそのプロセスを終わらすといいよ 解決したら統合すればいい プロセス別けて落とすのも同じ効果だと思うけど DLLを自前でアンロードするコードを入れても良いんじゃないかな そもそも pgfFrame = AVIStreamGetFrameOpen(paviStream, (LPBITMAPINFOHEADER)AVIGETFRAMEF_BESTDISPLAYFMT); ↑ この間の処理に問題があるんじゃないかな ↓ if(pgfFrame != NULL){ AVIStreamGetFrameClose(pgfFrame); } ←これだけ落ちる >>343-344 ありがとうございます。 >この間の処理に問題があるんじゃないかな この間は何にもしてなくても落ちちゃうんですよね… なんでだろう? DLLを自前でアンロードする事も視野に入れてもう少し試行錯誤してみます AVIFileExit(); してないというオチ? >>346 AVIFileInit()とAVIFileExit() 前に両方入れてみたんですが、入れても入れなくても何も変わらなかったんですよね… あとでまた試してみます。 本気で解決したいなら再現する全ソースコードを晒すのと 実際に読もうとしてるファイルのURLを晒して逝け >>348 あとでその部分だけまとめて再現できるか確かめてみます >>350 原因がわかりました。 普通にやると問題なくて、ここにあるコーデックの.dllをリンクすると AVIStreamGetFrameCloseが上手くいかないようでした。 https://sourceforge.net/projects/x264vfw/files/ このコーデックを使う必要があるのでどうにかならないでしょうかね。 正確にはコーデックの.dllをリンクして そのコーデックを使っているファイルを読み込むと AVIStreamGetFrameCloseが失敗するということです。 .dllをリンクしててもそのコーデックを使ってないファイルであれば AVIStreamGetFrameCloseが失敗する事はなかったです。 古いバージョンにしてみたら直りました! これで普通に動いてるのでこのまま動かしてみます。 みなさんありがとうございました。 バカの三大特徴 情報を小出しにする&後出しする 自分は間違ってないと思い込む&言い張る 正しい解決策に進まずすぐに別の山に登ろうとする ああ それを言うなら ffdshow の方だったかな しかしまだ使えるんかなこれ 日本語キーボード日本語Windowsで英数キー(CapsLockキー)のアップを捕捉する事って不可能? レジストリでキーマップを変えて英数キーを違うキーに割り当てた後なら一般的なキー同様に捕捉出来ることは確認できたけどそういう迂回方法無しで出来る方法があれば教えてもらいたい GetKeyState( vk_code ) VK_CAPITAL CapsLockのトグル状態 のほうじゃなく VK_OEM_ATTN 仮想キーコード 240 (0xF0) で今の押下状態は取得できそうではあるな IMEはちゃんと shift 無し Caps lock キーを受け取って反応できてるんだし ノートパソコンなどの省スペースキーボードについてるFnキーも拾えないんだよなあ、GetKeyState&GetAsyncKeyState fnはosの預かり知らないキーなので同列にすんなハゲハゲハゲハゲハゲ!!!!!!!!!!! キーボードのコントローラーが勝手に処理してるでしょう CPUまで線がつながってない感じ >>359 SetTimerとかで定期監視するしか無さそうか 今はarduinoとかで自分好みのキーボード作れる時代なんだぜ 知らんけど 虫歯が痛いなら総入れ歯にしましょう!レベルの解決策w >>355 ライセンスはどうしてるの? GPLやLGPLだから、リンクすれば最低でも自作プログラムのオブジェクト ファイルの公開が必要になるだろう。 別コマンドで実行する場合は、*.exe が自作アプリと合わせて二つ必要になるし、 データの受け渡しの効率も落ちる。 質問です。 GetCharABCWidths()を用いて、TextOut()で描いた文字のABC構造体を取得しています。 Arialフォントのような欧文フォントを用いてTextOut()で"あ"を描いた場合、そのフォント内には"あ"という日本語文字は入っていないため、適当な代替フォントに置き換えられて"あ"が描かれるようです(たぶん「フォントリンク」という機能だと思います)。 この時にGetCharABCWidths()で得られるABC構造体には、描かれた"あ"の寸法が入っておらず、ダミーの寸法が入ってきてしまいます。 msdnのGetCharABCWidths()APIの項には、 The ABC widths of the default character are used for characters outside the range of the currently selected font. とあるので、APIとしては仕様どおりの動作なのですが、では、描かれた"あ"のABC寸法を得るにはどうすればよいのでしょうか? 以上、よろしくお願いします。 GetTextExtentPoint32() SetTextJustification() DrawText() >>371 ありがとうございます。 GetTextExtentPoint32()だと、文字の左余白(A), 文字自体の幅(B), 文字の右余白(C)の 和の値(A+B+C)しか得ることができません。 そうではなくて、各文字について、A,B,Cそれぞれの値が知りたいのです。 それを返してくれるのがGetCharABCWidths()なのですが、>>370 に書いたように 正しい値が返ってこない場合があります。 一応、自分で考えた対処方法として、 1. GetTextExtentPoint32()で、文字のA+B+Cの値を取得 2. その幅を持つ白色の描画領域を確保し、その原点位置から黒色でその文字を描画 3. 領域に描画された結果(白・黒)を左端から走査して、左余白(A)を得る 4. 同様に右端から走査して、右余白(C)を得る 5. 手順1で取得したA+B+Cの値からAとCを減じてBを得る という風にすれば、(どんくさいですが)知りたい値を得ることはできると思います。 ちなみに、実際には、上のやり方そのままではうまくいかないことがありそうです。 というのも、イタリック体にしたりすると、AやCの値がマイナスになることがあるからです。 その場合、上のやり方だと、文字の左右が領域からはみ出て描画されてしまいます。 なので、左右にある程度の余裕を持った領域、例えば幅「100+A+B+C+100」の領域を確保し、 (x,y)=(100,0)の位置に文字を描画する。 そうするとはみ出さずに描画できるので、100の余分な余白があることを考慮に入れて計算すれば、 A,B,Cを得られるだろうと考えています。 でも、こんなやり方は面倒くさい。もっとマシなやり方はないのだろうか・・・。 例えば、フォントリンク?で描画されたときに、どのフォントが使われたのかがわかれば、 そのフォントを明示的にデバイスコンテキストに指定してGetCharABCWidths()呼べば A,B,Cの幅を得られるはずですが、フォントを知る方法はわかりませんでした。 ありがとうございます。 作っているアプリの仕様は、 ・アプリのユーザは、フォントと文字列を自由に指定できる ・画面上には、指定したフォントで、指定した文字列が描画される やりたいことは、 ・ユーザが上記の操作で描画させた文字列中の各文字について、A,B,Cの幅を知りたい ということなのです。 本来NGな組み合わせ(例:欧文フォントと、全角まじり文字列との組み合わせ)をユーザーが指定した時、 存在しない文字がいわゆる豆腐(□)にでも化けてくれれば、そこでユーザは別のフォントを 選びなおすはずです。 しかし、文字化けせずに一見正しく表示されてしまうため、困っています。 >>374 ABCなんて何に使うんだろうと思ったら、フォント情報を表示するツールなのか。 GetCharacterPlacement + ExtTextOut / ETO_GLYPH_INDEX あたりで、グリフを直接描画すれば フォントリンクは効かないはずなので無い文字は豆腐になるはず... ありがとうございます。 参考にさせていただきます。 可能ならば、無理やり豆腐にするんじゃなくて、フォントリンクで表示されたとおりの文字の情報を取得できるのが理想ですが、難しそうですね・・・ >>376 GetCharABCWidthsで取得しても1文字単位でしか取得できないので、筆記体やアラビア文字のように前後の文字や位置によって大きさが変わるような場合には対応できないので、ABCの値は参考程度にしか使えないと思います。 フォントリンク先のフォント情報(LOGFONT)は、メタファイルに出力後そのメタファイルを解析するというちょっとトリッキーな方法で可能です。 https://stackoverflow.com/questions/54050095/how-to-tell-if-a-surrogate-pair-unicode-character-is-supported-by-the-font 大変有用な情報、ありがとうございます。 確かに、筆記体のような手を繋ぐフォントの場合、うまくいきませんね。 これは気づきませんでした。 実際にはそういったフォントが使われることはまれなので、大きな問題にはならないかな、と思います。 HBITMAP hBitmap; に既に bitmap image が load されているとき BITMAP bm = {0}; GetObject(hBitmap, sizeof(BITMAP), &bm); で bm.bmBits の指す場所に pixles data があることは確認出来るのですが bm.bmBits は何時 GlobalFree(bm.bmBits); すれば良いのでしょうか? 放置しても memory leak の心配はありませんか? ウインドウのキャプションを SetWindowText で変更したいのですが そのウインドウはブラウザ(クローム系)でして SPY++が使えなくなっているので自作のウインドウ一覧で調べると ブラウザのトップレベル・ウインドウは、アクティブなタブのキャプションが ウインドウのキャプションになっており、クラス名は"Chrome_WidgetWin_1"でした これで取得したウインドウ・ハンドルを使って、ブラウザの位置を操作したり 最小化したりできるので、このハンドルで間違いないはずですが SetWindowText でキャプションを変更することはできません ブラウザには使えないということでしょうか 御存じの方、教えて下さると幸いです そうです ウインドウのキャプションを変更したいけど それはブラウザでは、タブのキャプションを変更したいということですね ブラウザのトップレベルのウインドウハンドルで、GetWindowTextを使って そのタブのキャプションが取得できるのに 逆に、そのハンドルでタブのキャプションはSetWindowTextでは変更できない ということのようです タブが子ウインドウになっていてアクセスできればいいのですが そこらへんブラウザは色々と特殊な作りなので無理っぽい気はしてます ふーんGetはできるんだタスクバー用かな? どう見てもオーナードローだし htmlのtitle変える方が早そうだね SetWindowText実行後にGetWindowTextしたら変更後のキャプション取得できてるんじゃない? 表示処理が別なだけで >>385 その通り、内部的には変更されてました!! ありがとうございました 聞いて良かった、自分だけで考えていたら堂々巡りで違う発想は出てこないものですね 見た目のキャプションはどうでも良くて ブラウザを複数起動して、全て同じサイトを開かせるので それをUWSCで操作しようとすると、どれが処理済なのか区別つかないので 処理済のやつのキャプションを変えてやろうということだったのです 処理未済のテーブルのキーは windowハンドルつこたらあかんの? 386の話? そんなことないですよ ウインドウキャプションと、クラス名が同じウインドウがいくつもあるので UWSCはそれのどのウインドウが処理対象か分からないってことです YouTubeから動画をDLするサイトを自動で開いて 新着の動画アドレスを自動入力してDLさせるんですが 一つがDL処理中に、別の新着動画が来ることがあるので 入力されたキーコードをキーボードの文字に変換してくれるAPIとかありますか? それかC/C++の関数とかで。 SHIFTのコードを渡すと、"SHIFT"みたいに文字が返ってくるみたいな。 どとねとにはあるけどお スレ違いかな 大した手間でもないしご自分で用意すれば そもそもC/C++ならマクロを糞すればリテラルを文字列に変換できるんだし ちょっとは頭使え? VisualStudio2022で C++でGdiplusを利用して、メタファイルとして描画した図形を保存するプログラムを作成しました。 (描画時メタファイルのパラメータはGdiplus::EmfTypeEmfPlusDualを使用して作成しました。) 保存した図形ファイルをエクセルで開いて、Ctrl+Cでクリップボードにコピーしました。 この状態で、EnumClipboardFormatsを使用して、クリップボードのフォーマットを取得しました。 予想だと、WinUser.hで定義されている #define CF_ENHMETAFILE 14 になるのかと思っていたら、実際は49161が取得されました。 質問ですが、この時取得された49161は何のフォーマットを意味しているのでしょうか? >>399 ありがとうございます。 すいません、質問なのですが Gdiplusを利用して作成したメタファイルをAPIを使用して汎用データオブジェクトとしてクリップボードに設定したいのですが、 参考になる書籍、ホームページ等ありましたらお教えいただけないでしょうか? EnumClipboardFormats()使ってるんだからOpenClipboard(),SetClipboardData()はわかるよね 何を聞きたいんだろう? >>401 昔からあるGdiで拡張メタファイルを作成して OpenClipboard() SetClipboardData(CF_ENHMETAFILE, handle_enhanced_metafile) CloseClipboard() で問題なく、拡張メタファイルがクリップボードに設定されていました。 それをGdiplusを使用してメタファイルを作成して OpenClipboard() SetClipboardData(CF_ENHMETAFILE, handle_enhanced_metafile) CloseClipboard() に改造したら問題が発生しました。 問題というのはエクセルにクリップボードからペーストすると、「図の書式設定」で「高さの倍率」「幅の倍率」が100%以下の数字になり 意図していたサイズより小さく表示されるようになってしまいました。 クリップボードに設定したメタファイルを、ファイル出力して、エクセルからファイルを開いて描画した図形を表示すると問題なく意図したサイズで表示されていました。 以上の事により、問題が発生する原因はクリップボードへの設定に問題があるのではと考えました。 エクセルにペーストしたGdiplusメタファイル図形を、さらに、エクセルでコピーすると、クリップボードには、なんのフォーマットとして扱われているのか調べてみました。 EnumClipboardFormatsを使用して、クリップボードのフォーマットを取得するとCF_ENHMETAFILEではなく、49161でした。 以上のことによりSetClipboardDataの第一引数はCF_ENHMETAFILE:14ではなく汎用データオブジェクト:49161を設定すべきかと考えました。 しかし、単純にCF_ENHMETAFILEを49161に変えただけでは、クリップボードにGdiplusメタファイル図形は設定されず、エクセルに何もペーストされませんでした。 希望は、Gdiplusメタファイル図形を汎用データオブジェクトとしてクリップボードに設定する方法を知りたいということです。 何かご存じの事がありましたら、お教えお願いします。 スレ立てるまでもない質問スレで詳しいこと言ってたら教えてやったんだがな 流したやつに教えてやる気にはならんわ >>404 すいませんでした。 こちらで聞いた方が良いとレス頂いたので こちらに移って質問していました。 もし、何かご存じならご教授頂けないでしょうか よろしくお願いします。 >>403 レスありがとうございます。 ENHMETAHEADERについてですが精査してみます。 (出力先をクリップボードでなくファイルにした場合、エクセルで開いても問題が発生していないのでメタファイルには問題ないかと、あたりをつけていました) CF_ENHMETAFILEについてですが、メタファイルは以下の3種類があるようです ・Windows メタファイル形式 (WMF) ・拡張メタファイル (EMF) ・EMF+ 描画時メタファイルのパラメータはGdiplus::EmfTypeEmfPlusDualを使用して作成しましたので EMF+として作成されているのかとも思っています。 そうするとENHMETAHEADER←拡張メタファイル (EMF) を使用しても良いものか疑問に思っています リンクありがとうございます。検討してみます。 >>406 すいません、一部訂正です。 【誤】そうするとENHMETAHEADER←拡張メタファイル (EMF) を使用しても良いものか疑問に思っています 【正】そうするとCF_ENHMETAFILE←拡張メタファイル (EMF) を使用しても良いものか疑問に思っています マルチするアホは原則スルー ネットマナーおじさんとの約束だぞ ? 他スレを勧められて続きはそっちでやることを宣言したのに、マルチ警察はこの上何を望むんだろう。 前スレで詳しいやつが回答してるのにアスペから自分にはわからんから移動しろと言われてここに来てるだけのアホだから マルチがどうこうより、せっかく回答したのに無視されたのが気に入らないってことね。 回答があるのに他で聞くのはマルチだろ マルチがなぜ嫌われるのか理由までは知らないのか マルチをしないからといって回答が無視されなくなるわけではないからそこは的外れだと思うぞ。 >>408 スレ立てるまでもない質問はここで 162匹目 に質問を出しました。 253 で49161は何のフォーマットか質問しました。 254 で汎用DataObjectだとレスを頂きました。 256 で254に対するお礼のレスをしました。 257 でWin32API質問箱 Build127の方が良いのでは?とレスを頂きました。 258 で そちらで聞いてみます と257にレスしました。 その後Win32API質問箱 Build127 に移って 398 で質問を始めました。 以上が今までの経緯なのですが、何か問題があるのでしょうか? 面倒くさいから追いかけないけど、別に問題あるようには見えない >>410 が正解書いてるような空気醸しだしてるから、その回答レス番書いてくれたら話が変わるかもしれんけど 実は正解ではない別のレスを書いててスルーされた恨みで警察に転職した可能性も感じる 恨みとか知らんし警察は俺じゃないけど雑な質問だからそれなりの回答しかしてない 詳しく聞けば教えてやったけど こっちの方が詳しい人がいると聞いてすぐ移ったから回答しなかっただけだが回答しなきゃいけない理由もないだろ こっちの詳しい人()に聞けばいいだけ それで何か問題あるか? 向こうのスレみて来たけど、マルチ嫌いの俺ですら全く問題ないなw なにを拗ねてるんだこやつは 知ってることを回答しないだけで非難される言われはないぞw お前が教えてやればいいだけ 本人でないならな 俺より詳しいやつがいるスレだからそれで問題ないはずだが何を怒ってるのか >>417 その通り マルチの話題でも何でもない無関係なことで話を拡げず、すっこんでろとしか 元スレで回答出てるならそれで終了 スレ移して質問続くなら普通にやってくれ 49161は何のフォーマットか?なんてのは枝葉で 本質は同じフォーマットになるような方法はないのか?なんだよな わからん 枝葉への回答は前もココにも付いてる通り 汎用データオブジェクト これで最初の質問は完了してるん この手のマニアックなのはstackoverflow漁るか英語で聞いた方が早いよ 特定のウィンドウがFlashWindowしてるかどうか知りたいのですが、何か方法はありませんか? 画像取得して色確認するとかしかないですか? セッションID=0のタスクスケジューラーのプロセスから他のセッションID=1以上のGUI持ってるプロセスの操作したいんだけど 同じセッションIDのプロセスを作ってやらないと無理だったかな >>431 サンプルソースは見たの? >サイズならTEB構造体から取得できるようなんですが 正確にはStackBase, StackLimit を取得できるので、その差分からサイズを求めている。 teb->Reserved1[1] を使えばよいはず。 >>432 あー確かに減算してますね。 気がつかなかった私がどうかしてました。 ご指摘ありがとうございます。 ディスクへの書き込みを別の場所へ書き込むようにインターセプトすることってドライバじゃないと不可能? ReadDirectoryChangesやFindFirstChangeNotificationって通知だけでディスク変更操作に手を加える事は出来ないよね パスが常に一定の物であればジャンクションやシンボリックで対応可能なんだけど その程度の知識の素人が手を出せるレベルの処理じゃないだろ 仮想デバイスとかどうすんの 古い32bitプログラムをVS(ツールセット2010)でx64でビルドしてるんですが 「外部シンボル "sprintf" は未解決です」などのリンクエラーが大量に出て困ってます。 「legacy_stdio_definitions.lib」を使えという情報もあったんですが 2010ベースだと恐らくない?為か見つからないと怒られます。 色々事情があって最新版には移行出来ません。64bit化は諦めるしかないでしょうか? >436 チマチマと自分で設定弄ったりしてたら解決出来そうでした。 Windows Explorerではファイルに由来する属性、例えば画像のサイズとか、 MP3のタイトル、プログラムの説明とか表示できるけど、 それを取得するAPIは用意されててつかえたりしますか? それともあれはExplorerで頑張って色んなフォーマットに対応してるの? >>440 Shell32.dllのGetDetailsOfを使うのずばりでした。 ありがとう!自前で全部揃えるのは嫌だとおもってたから。 >>440 2つ目のURLは違ったね。多分こっち↓だ Shell object (Shldisp.h) - Win32 apps | Microsoft Learn https://learn.microsoft.com/en-us/windows/win32/shell/shell 訂正します >436-437 もう解決したみたいだけど 文字通り legacy_stdio_definitions.lib をリンクすれば良い あるいは sprintf をやめて安全な snprintf (それ以外の legacy があればそれらも) 等を使うコードに変更する 俺もそろそろANSI32bitアプリをunicode64bitアプリに更改したいなあ まあ64bitにする意味は全く無いんだけど せめてunicode化して、流行りの顔文字ぐらい表示できるようにしたい あれのレンダリングはどうやるんだろうね TextOutみたいなレベルのAPIじゃ無理だよね? >>444 Direct2Dなので描画ハンドラ関数の丸ごと書き換えが必要 正確にはDirect2D+DirectWriteだね QueryPerformanceFrequencyで取得した値が10MHzになってるんですが 何時からこの値になったのか、時期と実装が変わった経緯分かる方いますか?? >>447 最近2台のPCで取得したら10MHzだった。第8世代か第9世代のCoreと第10世代のCore。 ぐぐったらもうちょっと小さい値が出てきた。 ResEditが無くなってしまったみたいだけど、何があったんや? 単に需要がなくなっただけ? ウィンドウメッセージキューと socket を WaitForMultipleObjects みたいに同時に待ち受ける方法はある? 現状は通信処理は別スレッドでやってるけど、これを敢えて GetMessage のループでやりたい。 というのも、好奇心上の取り組みでメモリ使用量を極限まで減らしたくて、まずスレッドを減らしてみようと思って。 あとちょっと API の話からは逸れるんだけど、VisualStudio で C++ のデスクトップアプリの雛形をビルドしただけのものでもメモリをコミットサイズで 2MB とか食ってて、スレッドも 4つくらい動いてるんだけど、これって何? 起動してから少し放っておくとスレッドは 3つくらい終了するから、いらないものなら排除したい。 いろいろ削ぎ落とすリンカオプションの設定とかあったら教えてほしい。 スタックサイズやヒープサイズは数十KBに設定してみたけど、あんまり違いは見えない。 >>453 MsgWaitForMultipleObjects を使う ソケットなら WSAAsyncSelect でソケットのイベントを WindowMessage に連動させる案もある >>456 それの方が GetMessage のループに馴染みそう。 そっちも試してみるよ。ありがとー シンプルにやるならGetMessageじゃなくPeekMessageでノンブロックループして定点観測するという事も出来る >>458 そのループがノーウェイトのビジーループになっちゃうじゃん やることあるときだけ GetMessage が返ってくれるんだから、そっちのがシンプルでしょ。 ところで、メッセージループで GetMessage したメッセージを DispatchMessage せずに、そのループ内で処理しちゃってもいい? ウィンドウプロシージャに書いてる switch やら DefWindowProc をループ内に直接書いちゃうの。 >>459 いや何も処理する事がなければSleep(1)でも挟むのが常套手段 GetMessageの内部だってそうなってるはず GetMessageの場合はカーネル空間でループ回してるだろうからPeekMessageループよりIO回数が減ってパフォーマンス上は有利だろうが >> 460 ダメです DispatchMessageは自プロセスに飛んできたOSとか他プロセスのメッセージも振り分ける >> 461 待つならSleep(1)よりもWaitForSingleObjectのほうが軽い >>461 常套手段ってw そしたら到着したメッセージを即座に処理できないでしょうよ。 イベントを待つというのは待ちながらもシグナル時は即座に反応できるというのが最大の利点なのに、わざわざそれを殺してどうするの。 そしてカーネル空間でも GetMessage は sleep しながらのループでなんか回してないと思うよ。 アプリケーションが何かを待ってる時には、スケジューラがそのアプリの実行を止めてしまう(タイムスライスをあげない)。 GetMessage で言えば OS がメッセージをキューに入れた段階で GetMessage してるプロセスにタスクスイッチする。 ディスクI/O しかり、socket しかり、タイマーしかり。 本当に CPU が何もしないときなら HALT してハードウェア割り込みを待ってる。 WM_KEYDOWN Ctrl+0(ゼロ)とかShift+0は来るのに、Ctrl+Shift+0は来ないのはなんでなん? 定番のSleep(1)にこれだけ噛みつけるのも面白いな イベント待ちはSleep(1)のポーリングでもどうでもいいと思うぞ シングルスレッドで全部処理する場合問題はそこではないし 扱う内容によっては毛局スレッドを分けた方がいいって結論になる 今時とかじゃない >>463 を読むほど笑えるという話 イベントキャッチは1msほどの間隔の粒度でいいの? タイマーの精度が高くないからSleep(1)でも30msくらいウエイトかかるけどな 1つの応答基準の60fpsが16.7ms間隔だからその間に処理が終わってれば常人の目には判らないし 待ち行列にメッセージが溜まってたりイベント処理が発生した場合、処理してる間にコンテキストスイッチが何度も起きて場合によっては1msなんて超えてくる Sleep(1)はOSに時間を明け渡す気がありますよ程度の意味しかない マウス、キーボードの処理、ダイアログの更新のメッセージ処理くらいなら事足りる 昔のゲームもOllyDbgやIDAつかって覗いてみるとPeekMessageやGetTickCount等を使って一定時間間隔のメッセージ処理ループをやってた >>473 それはウィンドウメッセージ以外の処理を並行してやるためでしょ。 均等時間で処理を進めたいとかそういう事情が無ければ大人しくイベント待ちすればいいのに、そうせずわざわざ Sleep するとどんないいことがあるの? 昔の知識否定されてファビョってるだけだろ わざわざ昔のゲームとかw 前レスよく読まなかったけど、GetMessage()で済むところをPeekMessage();Sleep(1);でループしてメッセージのポーリングするってことか。 なんでわざわざそんなことを?w WinFormsのソースもPeekMessageでWindowメッセージがあればそれの処理、無ければタスクキュー処理って流れだったはず >>477 それと > PeekMessage();Sleep(1);でループしてメッセージのポーリングする が同じに見えるのか? >>478 Sleepは知らんがPeekMessageでブロックせずに他の定期処理挟むのは別に普通って言いたかっただけ >>479 > Sleepは知らんが 話の流れも読めないのかよ... そもそも454-457で解決してるのになんで盛り上がってきたんだw 質問ですがOpen(Save)Dialog等でOFN_DONTADDTORECENTが無効の場合、この履歴情報はどこに保存されますか? すみません エクスプローラの履歴を消したら消えました 質問を取り下げます Win32APIはC言語が前提 C++で同様なものはMFCであってます? >>484 C++でもWin32APIはWin32APIです。 MFCは別物。 元々はC/C++からWin32APIを呼び出す前提だったけど、 今はC#、Python、Rust等いろいろな言語から呼べるらしい。 GDI+ はリファレンスは C++のインターフェースだけど 細かくほぐしたら Cや他言語に対応できるのかな >>484 MFCを使わせたかったのはVisual C++だった。 WindowsアプリケーションはC言語かC++を使うのが前提の歴史があって、MFCはWindows APIをラッピングしたものだった。 マイクロソフトはライブラリの作り方がよくわからず、MFCはコードが複雑になるだけのもの。 Java SEのライブラリが登場してから、マイクロソフトは失敗に気づいて.NET Frameworkを作ることになる。 >>489 MicrosoftのVisual C++のMFC BorlandのC++ BuilderのVCL 当時のWindowsでのC++用クラスライブラリでのシェア競争の結果Borlandが敗れてMFCが主流になった .NET FrameworkはもともとWindows DNA構想から産まれてきたものでMFCとは起源が別 MFCの設計が変なのは出てきた時期も悪かったと思うね まだVC++含めて各C++コンパイラでtemplateもまともに動かない&互換性に問題があるような状態だったし MFCは最初から死産だったがMS製だからVisualStudioに標準で入ってるからと使わざるを得なかっただけ 設計思想はDelphi(C++Builder)よりも数段劣ってる 当時のC++がうんこすぎたのもあるがこれは処理系の設計者のセンスの問題だろう MFCはDocument-Viewアーキテクチャがわかりにくいとかそのパターンに合わないアプリが 作りにくいとかはあったけど、それ以外は当時のC++でよくやったと思うよ。 C++じゃなくてCからでもGDI+は使える 面倒だから避けるけど >>490 Frameworkの出来としてはBorlandの方が完全勝利だったが マーケティングで負けたな >>491 いやいやMFCの設計者が馬鹿過ぎただけ Document Viewが分かりにくいとか そんなんで音を上げるやつがセンスとはよく言うよ Smalltalkの下手な真似は目が点になったけどね 使わざるを得なかっただけてw 使うも使わないも使用者の自由だろw MFC ATL WTL 用途によって使い分け ひとつのクラスライブラリに固執する必要性も必然性もない それは途中参加した案件が使ってるから使わざるを得ないだけで VSに入ってるから使わざるを得ないわけではないね 言うまでも無く地雷案件 参加する前に嗅覚で判断して離脱 上から降ってくる仕事を、雇われの立場の者は断れない 退職して出家でもすんのか 頼むから犯罪に加担するのはやめろ Win32というかVC++だけど_itow_s系列って何文字書き込まれたかを返してくれるバージョンなんてないよね? ChatGPTに聞いたら最後にint*で返してくれるオーバーロードがあるって言ってたんだが 意味の分からない現象に遭遇したので質問させてくれ。 ここが適切かどうか微妙だけれど、もしスレが違っていたら案内いただけるとありがたい。 さて、VC6時代に作成され、プロジェクトを随時新しいVSに移行して開発しているアプリがある。 特にフレームワークは使用しておらずwin32Apiで書かれている。リソースエディタは、VS付属のリソースエディタだ。 windows10/VS2019までは問題なかったんだが、windows11/VS2022でビルドしたとたん、ダイアログのサイズが横に6ピクセル縦に2ピクセル小さくなって、中身の右と下が詰まる現象が発生した。 同じプロジェクトに新規にダイアログを加えても同じだった。 なお、この現象は、タイトルバーを追加したときだけ起こる模様。また、フォントの指定をしてもしなくても同様だ。 当たり前だが、新規にテストプロジェクトをwindows11/VS2022で作成した場合は起こらない。 なお、windwos10でビルドしたものを windows11で実行すると正しく表示される。 また、windows11でビルドしたものを windows11 で実行した場合は上記のようになるが、windows10で実行すると正しく表示される。 windwos11の互換モードをチェックすると、少しだけ改善される(詰まりがわずかに改善する) user32.dll関連で何かあるのかな? 正直訳が分からないよ。 識者の意見を求む。 AdjustWindowRect AdjustWindowRectEx windows10/VS2019 で 新規作成し 同環境でビルドしたものを windows11 で実行 windows11 でビルドしたものを windows11 で実行 で差があるんかな? _WIN32_WINNT _WIN32_IE WINVER あたりの値を固定化しているのかどうか >515 え、rcファイルで定義されたダイアログを、DialogBoxParam()などで表示したらそうなって困っているという話なのですが。 もしかして、windows11の時だけ、横に6ピクセル縦に2ピクセル広げるという力業でやれということですか?w >516 プロジェクトを作成したのはVC6のようです。 以降ずっと継承しているらしく、そのプロジェクトをwindows10/2019でビルドすると問題が起きないのですが、 windows11/2022でビルドすると、実行環境がwindows11に限り現象が発生します。謎です。 バージョンは定義されています。この辺りを最新の0X0Aあたりに設定してリトライしてみます。 THX。 Windows11/2019でビルドしたらどうなんじゃろ ビルドしたOSのバージョンに合わせてウインドウスタイルを調整する部分があるのでは? VS2019とVS2022の違いで言うと、ヘッダーでの #ifdef の分岐条件の違いでしょ? windwos10でビルドしたものを windows11で実行すると正しく表示される。 →OSがWindows10アプリとして実行しているからオプション未指定でも正常 windows11でビルドしたものを windows11 で実行した場合は上記のようになる →OS的にはwindwos11アプリだけどビルドとしてはWindows10アプリ、その齟齬で表示が崩れる が、windows10で実行すると正しく表示される。 →OS的にもビルド的にもWindows10アプリとして実行しているから問題ない windwos11の互換モードをチェックすると、少しだけ改善される(詰まりがわずかに改善する) →疑似的にWindows10アプリとして実行するが、部分的に完全な互換が出来ないでいる と言う妄想をしてみた >>520 その #ifdef の分岐条件 になりえるのが _WIN32_WINNT WINVER と _WIN32_IE >>521 そうだけど「あたりの値を固定化しているのかどうか」って書かれているから それは「本来条件式に任せるべきところを直書きしているのでは?」と言っているのかと受け取ったけど 逆に俺は条件式に任せているから古い開発環境でうまく行ってないだけでは?と思ってるって話ね だから自分で条件分岐を追加するか、本人が>>517 で言うように力技でねじ伏せるかしかないのでは?ってこと 動作環境を固定化するのに #ifdef _WIN32_WINNT #undef _WIN32_WINNT #define _WIN32_WINNT 0x○○○ #endif というのは、俺はやってる これの宣言の後に windows.h 等を読むように って制限かかるけどね とりあえず関連するライブラリのビルドを込みで、すべてWINVERと_WIN32_WINNTの定義を0x0A00にしてやってみたが結果は変わらず。 >520 問題は、「どこで」そのOSのアプリだと認識しているのかという点ですね。 urn:schemas-microsoft-com:compatibility.v1 で、マニフェストに定義する値って、windows10も11も同じですし。 Common-Controlsの時みたいに、windows11スタイルを禁止するのになにか定義する値でも……と思ったけどみあたりませんし。 >522 とりあえずOSのバージョンを取得しているところをgrepして追いかけてみたが、そういうのはなさそう。 そもそもダイアログリソースからの作成ですしね。 問題が再現する最小のビルドを作成してるのだけれど、これがまあ大変(普通に10/2019で新規作成すると問題が起こらない)なので 問題が起こるプロジェクトを複製して、とりあえず WinMainがあるソース以外を全部削除してから順に試してみます。 泣けるぜ。 締め切りに間に合いそうになかったら、とりあえず超力ワザで。 こうやってクソソースができていくんだなぁ…… Win10/2022でビルドしてみたりWin11/2019でビルドしてみたりはしたんかいな ものすごい大変だったけど、最小化コードを作ったら原因が判明したので報告しておく。 おそらく windows2000 の頃まで遡る話だけれど、 ダイアログをセンタリングするためのクラスメソッド内で、ダイアログをセンタリングするためにSetWindowPos()じゃなくて、MoveWindow()が使われていたのが原因だった。 なんとエアロが有効な状態で、455 x 179 のダイアログを、MoveWindow()を使って、MoveWindow(100, 100, 455, 179) へと動かすと、サイズが、441 x 172 になる! そういうもんなのかー。こんなの知らないとわかんないよ…… sage忘れすまん。 てか、これ客観的に見てバグとしか思えない挙動だ。 とりあえず解決ということで。ありがとうございました。 連投すまん。 確認したところ、windows11/2022で新規作成したプロジェクトでも再現します。 windows11だけなので、11でUIを一新した際に発生した、MoveWindowのバグってことで納得します。 これが仕様だとしたら、ちょっと首をひねらざるを得ないですね。 >>531 ここで報告されたやん 俺らMS本社のエリートなんだから頑張ってfixしようぜ ここで報告できると本気で思ってるのか おめでてーな どう対処していくかは悩ましいところだろうけど さしあたり見つかってよかったね MoveWindowなんて基本的なAPIのバグを報告したら、幾らか貰えそうな気がする ここ見た他の誰かが、もう報告してるかもねw それってバグなのか? LunaやAeroの影響を受けるような前提があるんじゃないか? >>513 読み取った後に、wcslen() で文字数を数えると良い。 >>513 結論から言うと「無い」ハズ。 また、最後の引数が int* 型のものは存在していないように見える。 引数の説明欄も、以下の用に4種類のみで、その中に、該当のものは存在していない。 *Parameters -value Number to be converted. -buffer Output buffer that holds the result of the conversion. -size Size of buffer in characters or wide characters. -radix The radix or numeric base to use to convert value, which must be in the range 2-36. ウインドウサイズの現象どこかで見たな たしかリンカオプションの/subsystem:windows,X.YとManifestFileの組み合わせで APIの挙動が変わるんじゃなかったかな >>537 >>538 ありがとう、やっぱりないか ChatGPTって結構間違った答え出してくるな 自分では調べずにAIに聞いて、その確認も掲示板で他人に聞くスタイル ChatGPTもBingも知らないことを知らないと言わずしれっと嘘ついてくるし回答が人の目に触れてなくて識者からのコメントもないからこれを信用するやつは頭湧いてる Qiitaの方がまだマシレベルでこれに比べるとウィキペディアは神レベル しかしそのどれも公式ドキュメントとは比べ物にならない糞 答えの無い物を探すのが圧倒的に苦手 今までの「自称AI」と何ら変わらん野田 他のプログラミングを出来るとされるAIでも、小学生でも習う円筒の体積すら、 半径の二乗を直径の二乗に間違えた間違いのコードを答えてきた。 今のところは汎用対話AIだからね 対話力に重きを置いてる上に汎用型なので正確性に関してはかなり犠牲にされてる 結局人間もそうだけど専門型が出てきてこそだな AIアート分野はローカルで各々が専門的に学習させられるからその辺一歩リードしてる プロセス間で同じファイルを読んだり書いたりしたいのですが、 一方が開いているときにはオープンに失敗させるのではなく、排他制御で待つようにしたいです。 Linuxとかだとflockという関数があるようですが、 Windowsで同じことをやるにはどういう方法になるのでしょうか? ミューテックスを使うとなると、事前にミューテックスの名前も決める必要が出てくるのですが。 >>550 これって、書き込むときはファイルのサイズは事前にはわからないのですが、 計算してからでないとロックはできないということなのでしょうか。 ファイルの任意の領域というよりは、ファイルそのものをロックしたいのですけど。 >ミューテックスを使うとなると、事前にミューテックスの名前も決める必要が出てくるのですが。 別にそんな必要はないでしょ ユニーク名+ファイル名でミューテックスを使えばいい (※ユニーク名ってのは自分しか使わない名前のことね、例えばGUIDとかだけどそこまでがっちりやる必要もないとは思う) >>551 指定できる最大値を設定しておけばいい > ファイルの現在の終了位置を超える領域をロックすることは、エラーではありません。 とあるから事実上ファイルそのものをロックしたのと同じ >プロセス間で同じファイルを読んだり書いたりしたい 問題を無闇に複雑にしてると思わないか クライアント・サーバーモデルで、 サーバーだけが書き込めるとか言った制約があった方が良いかも知れません。 アドバイスありがとうございます。 あるアプリから別のアプリを起動する際、 コマンドラインでは収まらないような長い情報を渡す必要があり、 ファイルに必要な情報を書いてやりとりするようにしています。 (コマンドラインにはそのファイルのパス名を渡している) なので、ファイルを作成するアプリと、そのファイルを読み込むアプリがあり、 多重起動などのタイミングによってはアクセスがぶつかる可能性があるので、 このファイルに対する同時アクセスを制御したいという質問でした。 ミューテックスとLockFileExとどちらで実装するか、検討させていただきます。 >>554 コンパイラとリンカで同じファイルを読んだり書いたりするのも 問題を無闇に複雑にしているのか? >>556 それはやり方が違うだろ GetTempFileNameとか使って一時ファイルを作成すればすむ話 >>559 それもやってみたのですが、多重起動などのタイミングによっては、 どうやっても、読み込まれずに放置されるゴミファイルができてしまいます。 テンポラリフォルダなんて気にしなければよいといえばよいのですが。 Tempなんか使わずとも末尾PIDの名前でファイルなりを作れば重複起動その時においては名前は被らないし 引数の受け渡しとか程度の話ならオープン失敗したら数秒待って開き直せばいつか開けるだろ 書いてる間はどうせ読めても無意味なんだし WM_COPYDATAとかメモリマップドファイルとか >>556 >>558 と被るけど名前付きパイプがお勧め。 >>560 いや、ゴミファイルが出来る事があり得ないけどね… その多重起動というのがどういうものか知らんけど、GetTempFileNameで上手く行かないのは、プログラムが悪いと断言できる ま、これで駄目なら何やっても上手く行かないだろうね >>548 twitterで流行ってたものを誰かが試した結果を見て気付いた。 >>565 それで遊んでみようと思ったのだけど何を使用していたのかわからないなら遊べないな残念 >>490 正確にはMFCはMS-DOSの開発ライブラリ だからGUIのWindowsとうまく噛み合わなかった Ruby では普通、外部コマンド・子プロセスの終了を待つから、実行順序は書いた順。 Process.#wait 一方、Kernel.#spawn は、終了を待たない。起動しっ放し IO にはパイプ、ブロッキング/ノンブロッキング、同期/非同期もある >>567 コマンドベースの開発ライブラリならSDKだろ MFCはGUIが前提のクラスライブラリとアプリケーション構築のプラットフォームをセットにしてWin32APIをラップしたもの >>567 これはひどい そんなの関係ねぇ GUIのWindowsとうまく噛み合わなかったのは MSVCの開発陣がC++への理解が足りなかったから インストーラーの無い野良EXEのAUMID(Application User Model ID)をOSに登録する方法教えてください >>570 Microsoft Cがいつからあるのか知らないのか。 MFCにはGUI限定などという定義はない。 そもそもMFCはCUIのライブラリから始まっている。 >>570 SDKの意味すらわかってねえのか? あんたのいうMFCは、Windows SDKが扱うWin32APIをさらにラッピングしたMFCのことだ。 あんたの言っていることは滅茶苦茶だ。 >>571 どうでもいいけど、マイクロソフト内でC言語とC++の混在そのものに悩んでいたのも知らないようだな マイクロソフトはC言語派、C++派、Windowsを普及させるためにVB流用派と、試行錯誤を繰り返していた時代にMFCが誕生したと思っているなら、時期がずれていてリアルタイムでは知らなかったと言っているようなもの MS-DOS の頃ってMSのコンパイラは統合環境だった? C++ どころか Cコンパイラで コマンドライン上から nmake 叩いてわ ウィキペディアの説明が、Microsoft C 7.0以前の話がないせいで、Microsoft CとVisual C++の区別がついていないのね。 Windows 95、98の時代は、MS-DOS 6.2とWindows 95・98(内部MS-DOS 7.0・7.1)の併存期間で、MFCはMS-DOS 6.2をターゲットとしたものと、Windows 95をターゲットとしたものがある。 まず俗称「MSVC」と呼ばれるものは、Windows 95アプリケーションの開発を意識したもので、マイクロソフト「VC」と言っているあたりからわかるようにC言語でのWindows 95アプリケーションの開発を主としている。 ここでC言語からC++の移行をマイクロソフトはやろうとして、Windows APIがオブジェクト指向ではないところで無理が生じた。 そこでMFCを大幅に強化することでC++でのアプリケーション開発をしてもらおうとしたが、すでにWindows SDKの開発の知識がある開発者は、Windows SDKでのCでもC++よいというのに慣れていて、MFCを使えというのは、それまでの知識と違っており、無駄なクラスライブラリとしか思えなかった。 MFCはWindows 3.1でも影が薄い。マルチタスクではないと言えてしまうWindowsでは、MFCのメリットなどなく、無駄にサイズが大きくて重いコードが作られるため、性能、スペックの低いパソコンではMFCを使う理由がなかった。 MFCはGUIだけで使われるものではないため、CUI環境の開発でも使われている。 MFCどころかWindows 32APIでも、画面がある前提になっているコードを書かないといけないが、実際には画面がないものを作るのにも使われる。 MFC、Visual C++、Windows SDKの話がごっちゃになって、MFCを使うにはVisual C++でMFCを利用して、MFCがWindows SDKとセットだと認識できない点は理解できる。 まあ、ウィキペディアの記事は、根拠不明の創作が多いとわかってないとだまされるよな。 Win32がオブジェクト指向ではないって? ハンドルを使う関数(つまり大半)はオブジェクト指向だと思うが もしかしてオブジェクト指向とはC++やSmalltalkを使うことだと思ってるのか? >>578 統合開発環境と何の関係があるのか? Windows 95アプリケーションでも、統合開発環境は必須ではない。 画面のデザインのときだけ利用するという使い方が多かった。 Direct Xが普通に使われるようになってからは、統合開発環境は画面ごと吹っ飛ぶので、統合開発環境そのものも動かないこともあるし、統合開発環境を自分が作ったもので壊すことがあるから、Windows 95、98系では、Visual製品に期待しても、Visual統合開発環境とWindows OSのポンコツコンボは、いま思っているより意味をなしていなかったんだよ。 >>582 MFC=マクロ出力とセットになった統合環境前提って印象だったものでね リソース周辺のアレ >>581 そこで使われるオブジェクトとオブジェクト指向とは関係ない アセンブラのオブジェクトファイルと同様だ >>581 オブジェクト指向設計ではなかったんだよ。 C言語とC++は書き方が少し異なるだけだったので、Windows SDKではC++で書くとオブジェクト指向っぽくなり、C言語で書くとこれでいいのかという書き方で、Windows 95のアプリケーションが作れた。 ここはWindows SDKがオブジェクト指向ではないという理由がある。 APIそのものはオブジェクト指向ではなかったので、オブジェクト指向にするにはMFCを挟むという変なことをすることをしていた人間もいる。 たった数年で変わった話なので、過渡期を知らないと誤解が生じるのはわかる。 >>584 GetObject()なんか多相そのものやん すまん関数名間違えた SelectObject()だ GetObject()はオブジェクト指向と手続き型の切り替えだね Win32APIの基本構造そのものがイベントドリブンのメッセージ駆動なのでオブジェクト指向を土台にしている Windowsのマルチタスクはオブジェクト指向で成り立っているだろ そうそう ウインドウプロシージャのcaseなんか典型的だな >>575 >そもそもMFCはCUIのライブラリから始まっている。 doubt >>577 でたらめ言うなよ ボケが始まってるんだな爺さん ばあさんかも試練が >>580 おまいは Windows 3.1 の知識が抜け落ちておるな >>585 むしろ Win(32以前も)API / Win32API がオブジェクト指向で MFC の方がオブジェクト指向出来ていなかったんだよ だから判ってる香具師はみんな MFC は使わなかった 使ってたのは馬鹿だけ >>594 APIについてはその通りだが MFCがOOPでないという主張には 賛成しかねる 下手なところがあるのは俺も認めるが 原理主義者の言いなりである必要はない MFCとかけて、C++と解きます その心は、オブジェクト指向ではあるけど、なりきれていない これでどうでっしゃろ GUIの無い単純なアプリならまだしも、それなりのGUIを持つアプリは MFCを使ったほうが楽にアプリを作れるし、出来たコードも読み易い 確かに最初はMFCは取っ付き難いから、そこで挫折した人が >>590-594 みたいな事を言い出すんだろうなあ >>599 そんなことは無いと思うが Win32APIをちゃんと知っていればMFCなんて使う理由が全く無いし MFC関連のDLL何かも入れないといけないし単に開発効率がおちるだけ 実際当時Windowsアプリの仕事を結構やったけどMFCを採用していた所は少なかった たまたまそういう場所ばかり行ってた可能性はあるがMFC何て使うなよって当時から思ってたよw でも世の中的に勝利したのはMFCだよね 俺もATL/WTLでいいじゃんとは思ったけど でかいライブラリも整備されてりゃそれなりに便利だからね仕方ないね >>578 PersonalWorkBenchってのでFortranやったような気がするんだが 今ググっても全然出てこないな VB→.NET の流れがGUI開発の勝ち組というなら分からなくもないが MFCは・・・ >>600 >Win32APIをちゃんと知っていればMFCなんて使う理由が全く無いし WindowProcに case WM_… をだらだら書かなくても済むだけでも大きな利点 >MFC関連のDLL何かも入れないといけない ユーザー層やアプリの配布形態に応じて、必要ならMFCをStaticLibraryでリンクしてしまえば良い >>602 >VB→.NET の流れ 社内ツールとかならともかく、それこそユーザーにVB入れさせるなんて問題外でしょ 大量のデータ処置を行うようなアプリでは処理速度も遅いし 一般販売されてるアプリでVBで作られてるものなんてある? DLL hell, OCX hell とかVB案件の負の遺産なんじゃなかろうか >>600 >MFC関連のDLL何かも入れないといけないし単に開発効率がおちるだけ 昔Win32+CだけでDLLの追加が要らないよう頑張ってみたこともあるけど辛かったね。 C++の機能使ってしまうと結局CランタイムDLLが必要になるし。 >>601 だよな 8086しかりwindowsしかりMFCしかり 技術的に劣っていてもデファクトになると 好むと好まざるに依らずそれ関係の仕事が来る 元々BSD使いだった俺がwindowsに転向したのもメシのため DLL便利じゃん プラグインで機能後付けもこれのおかげだし >>603 BtoCよりBtoBの方が物は多いと思うが 金融界隈では未だにVB6が現役だし MSにしては大成果だったと言える Windows API インデックス https://learn.microsoft.com/ja-jp/windows/win32/apiindex/windows-api-list Windows API を使用すると、各バージョンに固有の機能を利用しながら、すべてのバージョンの Windows で正常に実行されるアプリケーションを開発できます。 (これは以前は Win32 API と呼ばれていたことに注意してください。 Windows API という名前は、16 ビット Windows でのルートと 64 ビット Windows でのサポートをより正確に反映しています)。 Windows11でPrintDlg使って印刷すると1度目は印刷できるけど 2度目はPrintDlg()呼ぶと反応無しになるのはなんか間違ってるのかな レジストリ弄ってLegacyなダイアログにしとくと印刷できる、あと管理者権限でプログラム実行して 印刷も勝手にLegacyなダイアログになるので印刷できるんだけど 試しに、VC2022で新規プロジェクトで雛形ちょっと弄って試してもやっぱり 2度目のPrintDlg()呼び出しで無反応になっちゃうんだっけど debuggerで見てもPrintDlg()呼び出しでエラーも何も出てこなくてわからない 10で平気なら11のバグだな 窓板の11バグ多すぎワロタスレに報告しとけよ PrintDlgってcomdlg32.dllだよな comdlg32.dllはバグで有名なやつじゃないか Microsoftの直接的な関係者ではなく、TSF (Text Services Framework)の仕組みを知り尽くしている人を募集中。成功報酬あり。 katayama.hirofumi.mz@gmail.com Firefoxのにゃるるにコンタクトすれば? あと成功報酬ではなく労働報酬あるいはコンサルタント報酬であるべきだよ 書き込めなかった、ローマ字で検索して にゃるる が地球にいたころ って言うか自分で勉強検索してたら最も頻繁に出てくる WaitOnAddressってアドレスの値が比較対象と違う値に変化したら自動的に起きるっていう魔法みたいなものではないんだね 呼んだ瞬間に比較対象と違ったら即返る、同じだったら後ほど変わったとしてもWakeByAddress系で通知しなきゃ起きないっていう原始的なイベントと言うほど変わらない感じか directoryなら監視してくれるけど https://www.youtube.com/watch?v=hKLBPXg8oik 呼んだ瞬間に比較対象と違ったら即返る 同じだったら返らない っていうのを期待してる? >>626 その挙動は既にWaitOnAddressに組み込まれてる訳だけど 対象アドレスの値が変わったら通知とか無しに自動的に戻ることを期待していた そうじゃなくてマニュアルでWakeByAddress呼ばなきゃいけないからイベントとそこまで変わらんなぁと まあハンドル作らずに済む点で手軽ではあるけど 8で追加されたAPIは頭悪い OSが頭悪ければAPIも頭悪いという当然の帰着 APIを使うだけならWin32よりWinRTの方が簡単でしょ >>630 ウィンドウ表示するコードはこれだけ #include <windows.h> #include <winrt/Microsoft.UI.Xaml.h> using namespace winrt; using namespace Microsoft::UI::Xaml; int WINAPI wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int) { init_apartment(); Application::Start([](auto&&) { Application(); Window window; window.Activate(); }); return 0; } ラッパー系は手をつけにくいなあ、MFCやOWLの悪夢が蘇る 便利そうに見えて、覚えることが増えるだけだったり 見えざる制約が足枷になったり、バージョン管理が面倒だったりと やむを得ない場合は仕方ないけど WinRTってMS的にはWin32と同列の扱いだけど、WinRTは内部でWin32を使ってるのだろうか? COMを焼き直して名前変えただけと言えばいいのか ただCOMの利点だったIDispatchで適当な言語から扱うみたいな事ができないうんこです WinRTはC#の情報ばかりでC++の情報が少ないから苦労するかも その点Win32は情報が多いからいいね >>628 WaitOnAddressは利便性目的ではなく手軽さ+パフォーマンスが要点だからそうとも言えない Thread立ち上げて立ち上げたスレッドがある地点まで到達するまで待ちたいみたいなちょっとしたシーンでは結構便利 パフォーマンス的にもイベント待ちに比べて1000倍近く早かったはず Chromeのタイトルバーに「^」の文字を上下反転させたボタンがあって押すとミニウィンドウ的なのが開くのですが、このボタンを実装したいのですがどうしたらできますか? Chromiumのソースコード見てもどこに該当コードがあるかわかりませんでした c言語で実装したいです タブを検索ボタンか。ソースをTab Searchで検索すれば出てくるんじゃないの 検索してみました ttps://github.com/search?q=repo%3Achromium%2Fchromium%20tab%20search&type=code タブを開いた時の挙動などはTypescriptで書かれているようでした ttps://github.com/chromium/chromium/blob/cd5fe35a69d697dd48ad34d5670d090afcdc57be/chrome/browser/resources/tab_search/app.ts#L560 既存のアプリにc/c++で手軽にタイトルバーにボタンをつけてポップアップウィンドウが開けてそこでボタンなどを選択できるような方法を知っていますか? LoadLibraryに渡されたlpLibFileName引数をどうにか呼ばれたdllmainから取得する事って出来ないかな 32bitならスタックフレーム遡ってLdrLoadDllを呼んだところの第3引数のスタックのUNICODE_STRINGから手に入れる事に成功したが 64bitだとfastcallになっちゃって第4引数まではレジスタ渡しされるからこの手法も通用しなくて詰んだ kernel32やntdllのアセンブラ決め打って取得することは出来るだろうけどそこまではしたくない ちなみになぜGetModuleFileNameではダメかというとハードリンクやシンボリックリンクのときにある条件下においてlpLibFileNameとGetModuleFileNameで一致しないケースが出てくるため >>643 その >ある条件下 で TCHAR PathBuffer[BUFFSIZE]; GetMappedFileName (GetCurrentProcess(), (void *)hModule_DLL, PathBuffer, BUFFSIZE); で、lpLibFileNameと同じパス(NT形式)が返ってくる?それともエラー? 試してないので結果を教えて >>644 GetMappedFileNameだとリンク先の実体ファイル名が返ってきた ある条件下というのは既に同じリンク先のdllがロード済みの場合に違う名前のリンクからロードしようとすると同一の物と判定され先客の方のhModuleが帰ってくるためGetModuleFileNameも先にロードしたほうの名前になる C:\mod.dll ← 実体 C:\link0.dll ← シンボリックリンク C:\link1.dll ← シンボリックリンク 最初にC:\link0.dllをLoadLibraryした場合、以降C:\link1.dllをロードしGetModuleFileNameをしてもC:\link0.dllが帰ってくる GetMappedFileNameだと常にC:\mod.dllだった >>645 確認ありがとう、参考になった こみ入った環境なんだね 所望の動作でなくて残念だけど、他の手段に心当たりがない... pe iat import address table 辺りを弄れば 鶏卵かもしらんけど load されたときの名前からパラメータ参照ファイルな .ini ファイルの名を変えたいって感じなのかな? >>645 のケースだと C:\link0.dll でロードした場合には C:\link0.ini を参照し 以降 C:\link1.dllをロードした場合には C:\link1.ini を参照したい と この場合 単に同じ実体でリンクカウントが1増えるだけであっても区別したい ということか DLLはメモリに直接ロードする方法もあるから 不正を正したいって意図なら無力だよ 1. FindFirstFileでリンクか実体かを判定 2. VirtualAllocExで実行可領域のメモリを確保 3. ReadFileでDLLを読み込む 4. PEヘッダのIMAGE_OPTIONAL_HEADER64.ImageBase+IMAGE_SECTION_HEADER.VirtualAddressに各セクションをコピー 5. DLL内のImportLibraryを同じ手順で再帰的にロード 6. DLL_PROCESS_ATTACHとDLL_THREAD_ATTACHでDllMain呼び出し Win32APIのGUIに著作権ってある? 自分用ならまぁ好きにしたらって程度だと思うけど ボタンとか目コピで丸パクリしてアプリケーションとして配布したらダメなのかな 腐ったバナナの皮ですらアートとして認められるからな 許諾なしなら著作持ってる奴次第 ReactOSはかなり似てるけどね アイコンはTangoのを使ってるけど、形的なものはそっくりだな テーマ機能があるから、訴えられても簡単に変えられるし、大した問題でもないが https://monolith-law.jp/corporate/design-ui-copyright-law レイアウトや色の使い方ぐらいじゃ侵害にはならないだろうって判断と あとは「思想又は感情を創作的に表現」したものであるかが関わる それと著作権法に触れなくても意匠法にに触れる場合はあるとさ >>651 複雑なデザインのボタンがあってそれを丸コピしたなら危ないけど WinAPI程度のボタンだと「レイアウトや色の使い方」の範疇に思う >>651 あの大きさでは目コピって言いわけしても無理だろw 90%一致できるw 悪目立ちしなきゃ大丈夫って感じかな どうもありがとう 素直に使いこなせれば変なことしなくていいんだけど >>654 Windows自体がMotifのパクリ あの立体的に飛び出たボタンは誰が最初にやったかを少し調べてみたら、やっぱりMotifが最初にやった可能性が高いな Windowsも旧Mac OSもMotifより前にリリースされてるけど、ボタンは黒い線で縁取られてるだけだからね Motifがリリースされた1989年の直後、1990年にWindows3.0がリリースされてボタンが立体的になった ただ、リリース直後のMotifの見た目は確認出来なかった 誰も突っ込まないけどWin32APIのGUIってなんだよ? GDI32.DLL つうかWindowsはGUIだろ 面倒なことしなくてもDLLからアイコンロードすればいいんだけどな >>659 CreateWindow()とか知らないの? CreateWindow() のどこがGUIなんだって話なんだけど。 GUIを構成するためのAPIの一つではあるがGUIと言われても違和感しかない。 皆行間読んで回答してるんだよ そういうのを読み取れずにいちいち突っかかってくるお前に違和感しかないわ 行間が読み取れてないわけでも突っかかったわけでもなくて 気になる人いないの?って問うただけなんだけどね。 GUIじゃなくてGUIパーツね それを指摘してどうすんの? GUIのデザインパクっていいっすか?だろ? 左上にシステムメニューと閉じるボタン 右上にアイコン化、全画面化がWindows3.1のGUIだ よく読めよ ボタンのビットマップとかのGUIパーツについて言ってるだろ GUIのメソッドについてはパクるまでもなくAPI呼び出せば自然にそうなるから Win32API の話ならム板 Win32API の著作権の話ならマ板 Win32APIのGUI?(ツールのデザイン)? の著作権の話なら著作権板 だろうな 遠すぎる winsqlite3って勝手に最新版のsqlite3でstdcallにしてコンパイルして上書きしても問題起こらないんかな テキストカーソルインジケーターをアプリに組み込みたいんですが、どこかにサンプルコードないですか? >>674 >>618 : 蟻人間 似た状況の話に見えるどnyaruruはどうなったんだ? >>674 キャレットはXORペンで描くのがコツだね。 >XOR 灰色背景だと見えなくなるから賛同できないわ 標準のエディットコントロール内に居るキャレットって XOR 描画してるよね たいていは白色がテキスト入力で灰色は入力不可の部分だからいんじゃない キャレットもそうだけど、最近なんか範囲選択表示で、半透明の矩形上に重ねるだけのエディタ多くね? あれ見づらいんだよなぁ・・・フルスクラッチで作るなら確かに横着できて楽なんだろうけど エディットコントロール自作はやめたほうがいい IMEが機能してるように見えても、音声入力や音声入力編集、読み上げで制限があるのが大半だから キャレットもOSの強調表示機能があるし、知らないところで多機能を要求される 自作エディットコントロールわざわざ作るときって巨大ファイル編集したいとかじゃないの OSが勝手に後付けしたアクセシビリティ機能とか知らんでいいよ 老舗エディタ(mifes, em)は巨大ファイル対応 これが異彩を放ってる 小さいメモリ(100MB以下)で大規模テキストファイル(5TB以上、2兆5000億行以上)を編集できる世界唯一の超巨大テキストエディター https://szkwjp. サクラ.ne.jp/ https://i.imgur.com/isKK2x5.png Meryもdelphi製コントロールをヘビーカスタムしてたと思う http://www.haijin-boys.com/ >>686 emEditor世話になっているけど意外に保存遅いんだな まぁ頻繁に保存するような用途じゃないんだけど そういや日本語フォント最速表示って今なんなんだろう、DirectWrite? アルファベットなら予めテクスチャに全部落とせばいいんだろうけど >>686 ,688はフリーじゃない >>690 >意外に保存遅い emEditorは今でも活発に最適化に努めてるから最新ではどうなのか不明 飽くなき高速化への挑戦! 「EmEditor」はマルチスレッド・SIMD命令・仮想メモリをフルに使って進化 https://forest.watch.impress.co.jp/docs/special/1483714.html freetypeが早いけどDWはOSがキャッシュしてくれる(ctfmon.exe)のが有利 harfbuzzもラスタライズしてくれるけどbitmapヒンティング切捨て、速度は不明 GDIはカラー絵文字ないから新規では厳しい 古い記事だけど 2017-05-21 GDI vs DirectWrite vs FreeType https://i.imgur.com/8nDxIa3.png https://silight. ハテナblog.jp/entry/2017/05/21/220505 TATEditorはfreetype (本来の速度より遅い気がする) MeryはDW選択可能 今のnotepadはDWだと思うけどパラメータのせいなのか、同じ日本語フォントでもMeryの方がキレイ 一度気が付くと気になって仕方ない 昔はメモ帳やらエディットボックスが32KBだかしか開けなかったせいでちょっと長いテキスト表示したいなら自作するしかなかったし 今のエディットボックスも使いやすいというわけでもないし >>693 むしろエディタには完全自作しかない エディタにあるような複雑な禁則事項はエディトボックスでは扱えない 高校生の頃からHTML直打ち自前サイト始めたから、秀丸にはお世話になったわw >>691 690だけど遅レスですいません、詳しくありがとうございます 社内で使う遊びツールに活かさせて頂きます というかここまで詳しい人ってもう FindWindowで他プロセスの生存確認を行っているのですが、その該当プロセスが死んではないものの 応答無しレベルで重い場合にFindWindowがNULLを返すことはあるのでしょうか? ここでは他プロセスのトップウィンドウを検索しています。 該当プロセスが本当に死んでるなら当然でしょうが、それ以外でNULLを返す可能性があるならば 対策をしようと思いつつも、そんな可能性がないなら無駄なのでご存じの方よろしくお願いいたします。 さっとググった感じでは、他プロセスの子ウィンドウを検索する場合は問題ありのような感じですが、 本件はそうではないですしほとんどの場合NULLではなく正常にウィンドウハンドルを返してくれています。 詳細なエラー情報を得るには、GetLastError を呼び出します。 他プロセスの生存確認はEnumProcesses()でやるべきなのでは >>701 その通りなのでその辺の修正を視野に入れていますが、中々再現性が薄いのもあり、そもそもの仕様として どうなのかなという確認の意味で質問しました。 >>702 どうもすみません。説明に抜けというか間違いがありました。 生存確認だけではなく、WM_APP+nメッセージも送るためウィンドウハンドルが必要となります。 (実際、死んでいるなら起動処理も入れていますが) 要はプロセス間通信をしているのですが、データ自体はファイルマッピングによる転送、転送のトリガー通知を メッセージ送信にしています。 FindWindowで見つからないならHWNDも取れないんだし居ない者でいんじゃね つかそこ悩むことじゃなくね >>700 ,703 ちなみにそのアーキテクチャはいつの設計なん? まずプロセス間通信するなら相手が居ない場合を必ず想定すべきでFindWindowの1度の呼び出しで一喜一憂すべきではない プロセスの起動し直しも前提に数秒おきのFindWindow呼び出しポーリングはしたっていいと思うよ メインウィンドウなんて高々数十個だしそんな負荷にならない 該当プロセスを他プロセスから起動してたりするとどうなんだろ あとFindWindowじゃなくてEnumWindowsなら拾えないことって無い印象だなぁ、ハンドルも取れるし あまり関係ないけど、うちのクソシステムだとブラウザからサーバー上にあるエクセル開くんだけど、 Workbooksで拾えたり拾えなかったりするのよね(ExcelVBA) >>704 複数起動しないようmutexかけてるので、プロセス生きてるにもかかわらずFindWindowがNULL返すのなら好ましくないなと。 >>705 古いよ。保守だけで毎月3桁くれるんだからおいしい。 >>706 とりあえず見つからないならエラーも取得しつつ数秒間再試行かけてみました。 これで様子を見ます。 >>707 該当プロセスは他のプロセスからも起動したりテスト作業で自分で起動したりしてますが、一応拾えてますね。 mutex の排他って CreateWindow する前 & メッセージループする前だから プロセスは存在してるけど、window は無いって 中間的な状態じゃね? >>701 詳細なエラー情報を得るには、関数を呼び出します。 >>710-711 お前らその金額でおいしいの?仕事してくんない? POSIXのopenatとかをWindowsで実装したいんだけど、 NtCreateFileを使えとは見るんだけど、 実際のコードは見たなことない。 gnulibから実装した方がいいのかな? 不特定多数に文字だけで意思疎通するには答えやすい尋ね方というのがあると思うが、そんなことよりスクリーンセーバー作ろうぜ IME のオンとオフの実装で以前は ImmGetContext ImmSetOpenStatus ImmReleaseContext の3点セットで完全にオンとオフが機能していたように記憶しているのですが 今のWindowsでは機能しないことがあります(Windows 11 Home 22H2 OS Build 22621.2070) この原因や解決策をわかる方がいたら教えてほしいです Windows の公式サンプルでもこの3点セットでオンオフを実装しています github.com/microsoft/Windows-classic-samples/blob/ac06e54a15e9a62443e400fffff190fb978ea586/Samples/Win7Samples/winui/input/ime/fullime/Main.C#L237 旧版MS-IMEじゃないとダメなんじゃないっけ?知らんけど 心配無用 Win11でなら上手く動かなくても許される y=f(x)のグラフを描こうとした場合、GDIのLineTo()で書けますが グラフとx軸の間の領域を背景とは異なる色で描画しているアプリを 見かけることがあります。 ベタにやろうとすると(x,0)から(x,f(x))までを別のペンでLineToすれば できそうですが、それだとあまりにも遅そうなんでどのようにするのが 一般的なんでしょうか? >>721 グラフを描画するのであれば、さすがにそういうのに向いたプログラミング言語を使ったほうが 本質的な所に時間を使えるんじゃないか? (分かりやすく)グラフが丁度収まる矩形サイズの描画メモリをCreateDIBSectionとかで確保して 掛け算や条件文をなるべく使わずに、直接メモリを塗りたい色で書き換えて、 最後にその描画メモリをバックバッファへ転送する、とか データ左端,Y軸下端 to データ左端,Y値 to データX値,Y値 to ... to データ右端,Y値 to データ右端,Y軸下端 (to データ左端,Y軸下端) 自分で線描画してメモリDCでダブルバッファするか 既製のチャートコントロールを使う jもしくはavascriptにグラフ描画のは沢山あるからそ!をwebview2か何かで表示する いや、GDI+かDirect2Dを使えばいいんだよ メール関係のライブラリを知っていたら教えてください。 Windowsで使えるライブラリってないのでしょうか。 まああるかないかで答えればあるんだけどさ メール関係って言われても色んな技術の集合だしなあ その質問をこのスレで聞いちまう所がまずセンスないよね 送受信はたいしたことないけど お行儀悪いのを忖度して可視化するのがとても大変 GetTempPathで取得できるフォルダ(AppData\Local\Temp)の中を見ると、 固定名と思われるサブフォルダを作っているアプリが結構あるのですが、 こういうアプリって、その固定名のサブフォルダが他のアプリと競合したり、 同じ名前のファイルがすでに存在していてサブフォルダを作るのに失敗したりするケースは、 ちゃんと想定しているものなんですか? >>741 想定していないアプリなんかは、事前に同じ名前の空ファイルでも置いておけば、 テンポラリフォルダを作れなくて正しく動かなくなってしまうということですよね? 同名のファイルが存在してサブフォルダが作れずに阻害された後 どうなるかも作り手次第だろうね 名前を変えて悪あがきするか、エラー報告して終わるか、だんまりするか・・・ 単なるファイルのコピーすら気を付けても穴だらけだしな その時点の知識で最良を目指すしかない >>740 そもそもTempは一時的なフォルダでしょ 本アプリは上書きで使っていくだけだから影響はないでしょ キャッシュや恒久的に使用するデータをそこに保存している場合は不具合のもとだろうけど データ検証しない場合はエラー吐いて落ちるだけじゃね? Tempフォルダの中身は削除されても文句言えない物だから なんなら同名あったら問答無用で削除して自分用作るすらあると思うわ その通り 既存の同名があって作成者が自分じゃなければ消して新しく同名で造れば良い >>740 勝手に数字をつけて存在しない名前を探してくれるAPIがあっただろ 数字は16ビットなので65536個全部あったらだめだが APIを呼び出した次の瞬間名前が衝突する可能性も考慮するんだぞ みなさんありがとうございます。 >>745-748 テンポラリファイルではなく、固定名のサブフォルダを作るアプリに対する疑問でした。 フォルダ上に同名のファイルがあったら、その名前のサブフォルダは作れないですし。 確かにそれを言い出したら、インストール時も、 Program Filesの中に同名のファイルがあったらどうするんだとか出てきますが。 >>750 作る前に存在の有無ぐらい確認するでしょ それはアプリ作成側がそこまで思いを致すかどうかなんだよ >>750 テンポラリファイルではなく、固定名のサブフォルダを作る場合は C:\Users\ユーザー名\AppData\Local\会社名 で作るのが一般的では?(暗黙のルール?) 個人で作ってるならアプリ名を元に他と被らないようにするとか その為のレジストリなんじゃないのか? キーは基本的に会社名含めてるから被らないし、ファイルを作成して消耗するより楽だろ テンポラリの作業用にレジストリ使うの? ファイル造る方が楽 >>753 とか>>754 とか 世の中に同じ名前の会社が一切存在しないと思ってんだろうか ファイルやディレクトリ造るために社名変更するまである >>750 >確かにそれを言い出したら、インストール時も、 >Program Filesの中に同名のファイルがあったらどうするんだとか出てきますが。 Windows Installerは排他実行だった気がする。 >>750 >確かにそれを言い出したら、インストール時も、 >Program Filesの中に同名のファイルがあったらどうするんだとか出てきますが。 Windows Installerは排他実行だった気がする。 リソースの作成は、片山さんのを使っているのですか? MoveFileExにはMOVEFILE_WRITE_THROUGHというフラグがあって、 直後にディスクへフラッシュすることができるけど、 これと同じことをCopyFileで行うことはできますか? >>771 Microsoft公式で、こんな苦し紛れな方法が紹介されているんですね。 MoveFileExはNT3.1以降の関数なのに。 >>770 ,771 どっちもそれだけでは不意の電源断でロバストじゃないのが難しい。 タイムスタンプが1970年だかのファイルを仮置きして別名でコピーしたら挿げ替え 電源断が怖いなら挿げ替え部分だけアトミックに作ればいい >>774 >電源断が怖いなら挿げ替え部分だけアトミックに作ればいい この部分は具体的にセオリー的なやり方があるのですか? 挿げ替えで思い当たるReplaceFileはアトミックか分かりませんでした。 CopyFileではいったんテンポラリファイルにコピーして、 それをMoveFileExで正しいファイル名に変更するとかやれば、 ちゃんと書き込まれる可能性は高くなるんですかね >>775 Rep略はアトミックだよ MSのどっかに書いてあった RtlReAllocateHeap(GetProcessHeap(), 0, lpMem, dwBytes) これをそこそこの頻度でやってると特定回数目にクラッシュしてしまうんだけどどういうことなのだろうか よくある戻り値null未チェックとかそういう事ではなく上記関数内で落ちるんだよね lpMemも間違いなく生きてるメモリなのは確認済みでdwBytesも不自然な値ではない 呼び出し方が悪いのかと思ってmalloc、reallocに変えてみてもやはり同様の場所でクラッシュしてしまう API変えても発生するならAPI関係ない場所のお前のバグじゃん >>781 WindowsのreallocはHeapReAllocのラッパーでHeapReAllocの実態はRtlReAllocateHeapへのリンクに過ぎない訳だが mallocやreallocもまともに使えない子はこのスレに来るのはまだ早かったねー free 済のポインタに対して 再び free したんじゃないの? 特定回数でクラッシュするなのがわかってるなら アドレスがどう変化した時にクラッシュするとかわかりそうなもんだ mallocで大きなメモリを取得して、その領域から切り出すalloc関数などを作って差し替えてデバッグするとか? 組み込み系で良くやるけどね。 >>786 それはおかしいだろ (アドレスが変わる場合は)freeする前に新しいアドレスに内容コピーしないといかんから BoundsChecker か PURIFY ですぐ究明できそうな気がするけど メモリのフラグメンテーションで大きい領域がとれないんじゃない? ファイルパスなんかはカーネルが結局UNICODE_STRINGとして扱うからwchar版の方がパフォーマンス良いけどadvapi32のレジストリ系関数はどうなんだろうか? WM_MOUSEFIRSTからWM_MOUSELASTのメッセージって、 これから追加されるメッセージもLPARAMはすべてマウス位置のクライアント座標が入る、という約束はありますか? Spy++のメッセージウィンドウには、「S」や「P」の文字が表示されていて、 それがSendで送られたのかPostで送られたのかがわかるようになっていますが、 これと同じ区別を、自身のメッセージハンドラ上で行うことはできるのでしょうか InSendMessageというAPIは見つけたのですが、 Spy++で「S」と表示されるものでも0が返ってきてしまいました InSendMessageは別のスレッドからSendMessageされたかを判断する、と説明があるから、 単純にSendMessage呼び出しを判定するものではなさそう 同一スレッドからのSendMessageの呼び出し判定は、ウィンドウプロシジャのコールスタック辿って SendMessageのエントリポイントと比較するとか、何か追加で頑張る必要がありそう Snedはメッセージキューに来ないからあればPostなければSendやぞ 内部でIsPostMsgとかフラグ作ってDispatchMessage()を呼ぶ時に1にする終わったらゼロにする Postでキューに入ったのを取り出して呼ばれるのはそこだけでしょう Sendでは直接呼ばれる もしウィンドウプロシージャの中からSendしてたらこれは使えない 自アプリ側で予め SendMessage PostMessage をフックしとけば良いのでは? >>796-803 ありがとうございます Spy++はメッセージをフックしているから、SendとPostの区別もできるということなんですかね 自作アプリに対してSendMessageでWM_APP送ってるけど送れてない(受信できていない)ことがあったので 送信側でGetLastErrorしたら > 0x05:アクセスが拒否されました。 が取れました。 ここによると ttps://learn.microsoft.com/ja-jp/windows/win32/api/winuser/nf-winuser-sendmessage > メッセージが UIPI によってブロックされると、 GetLastError で取得された最後のエラーは 5 (アクセス拒否) に設定されます。 これに該当してる?のか他の原因でアクセス拒否されているのか分からないけど、 受け側のアプリはずっと起動したままで直前までメッセージ受信できていたことと、 その後もアプリが死んでいるようには見えず操作できるし動作ログも残るため、 ただただWM_APPメッセージ受信のみ(?)できなくなっているような状況です。 ここで質問ですが、どういう時に急にメッセージ受信できなくなるのか、エスパーお願いします。 今後の対策としては受信側でChangeWindowMessageFilterを使ってWM_APPを許可すれば良さそうだと当たりは付けていますが・・ 権限レベルを弄ったりということは一切していないので、問題の発動条件が知りたいです。 んで、この手のシステムからの意図しない介入問題が起きた場合は、 原則プロセスの再作成で解決するしかない これはLow Level Hookが外れた時の対処と同じ 恐らくSendMessageの処理が規定時間以内に終わらなかったとかで適当に介入してるんだろう 知らんけど >>808 再現性ないと言っていいのか、手元では再現できず エラーが出た環境でも普段は問題出てなくて、たまたま問題が出たのに気付いてログを漁ってエラーコードが分かり、 過去ログも遡ると半月前にも一度エラーが出ていたのは分かりました この問題が出た環境は24時間PC&アプリ起動しっぱなしということらしく、その時点で 何となくお察し感がなくもないですが原因ははっきりさせたいなと >>809-810 受信側は一切メッセージの受信を感知していない(ログに全く残らない)ようなので 規定時間以内に終わっていないというようなことではないとは思いますが、 何かしらの原因で適当に介入されている感はすごくあります まあ適当に〜されたとしても、はっきりしたいところです 断片化回避のためにSetFilePointer -> SetEndOfFile -> SetFilePointerサンドイッチってもう古いやり方? .NETのFileIO実装がSetFileInformationByHandle(FILE_ALLOCATION_INFO)でやってるんだが >>811 ちょっと調べてはみたけどstackoverflowでも迷宮入りしててだめだったんよね SYSTEMプロセスから送れば拒否られないとは思うが 確実にプロセス間通信をしたかったらメッセージよりは名前付きパイプが無難だろうな >>815 迷宮入りまで調べてくれてたんですね 確かにパイプが無難です 今さらコイツを修正するには作り直しレベルなのでもう無理ですがw とりあえずしばらく放置して色々な環境でログ収集して情報整理します ありがとうございました >>807 再現性はともかくとして、SendMessageが途中から拒否られる事象がOSのどのバージョンで発生したか書いといてくれると嬉しい >>817 どうもすみません Windows11 home 23H2です ちょうど今おかしな環境のPCがまたおかしくなっているようなので調べていましたが、 受信側プロセスが管理者特権に変更されているようで、これが原因ですね 送信側は管理者特権は付与されていませんが、送信側プロセスから受信側プロセスを 起動していますから、最初は特権が付与されていないはず・・・ ということでどちらのプロセスも再起動させたところ、どちらも標準ユーザーになっていました explorerからexeプロパティを見ても管理者権限はチェックされていないようです 意図せず途中で管理者特権が付与される可能性はあるのでしょうか? (プログラム的にはそんなことしているつもりはもちろん無いですが) 無意識にそんな特権付与されたら怖すぎるがなw システムが一時的に特殊な状態にしてるんじゃないの APIの先で起動されるスレッド(OSが起動する)が管理者特権付きで それがアクティブな瞬間はプロセスが管理者特権付きに見えて、 そんなタイミングのプロセスに一般ユーザがメッセージ送ると、 管理者様に対して頭が高いぞってアクセスデナイド。 とか想像してみた。 818です ログを見ると、一度メッセージ受信できなくなるとずっと受信できていないようです 管理者特権が付いているのを確認したのはタスクマネージャでの目視ですが、 見たところずっと特権がついているのでタイミングの問題ではなく、何かしらの拍子で特権がついたまま という感じですね 今のところ、24時間起動したまま使い続けていますがあれから特権はついていません 特権を必要とするようなコードを書いたことない(つもり)なので、原因にたどり着くのは中々難しい状況です 例えば、どんなことをすると特権が付与される(UIもなく勝手に?)のでしょう? 心当たりが無いなら今月のCVE-2024-30051だとか特権の昇格の脆弱性のどれかに引っかかってる可能性あり >>813 自己レスだけどSetFileInformationByHandle(hFile, FileAllocationInfo...)でやるとサイズが小さい場合にMFT内にデータ埋め込んで完結する場合でも1セクタ確保されてしまうようなので旧来の方法でやる方が無難だった >>813 埋め込みサイズ上限を上回る新規ファイルを作る場合ならハンドル作成時にアロケーションサイズも同時指定する方が良さそう >>807 ,821 疑ってすまないけど、本当に隅から隅まで自分で書いたプログラムなのか? OSSをちょっと弄った程度で自作アプリと言っているだけなんじゃないか? リストビューで範囲選択したときの青い枠の色や内部の半透明な色の値は、APIで取得できるのでしょうか この辺りlinuxやMacのWMとかと違って有る程度の値の取得変更できるのはWindowsの強みだったよな >>828 GetSysColorはRGBの値で、透明度の値まで持ったものを返すようには見えなかったのですが、 具体的にどのパラメータを指定するのでしょうか? 他スレでスクリーンショットのマルチポストがあるけど、加えてコントロールの色を取得か AIに食わせるUI Automation学習データを整備してるのかな >>832 XPの頃からある範囲選択時の半透明の青なのですが >>833 プログラム組んでるのなら自分で逆算しろ >>834 どのWindowsでも画面設定とか関係なくこの青なら直値で計算してもいいけど、 なにかのAPIで取得できるなら合わせておきたいです 稀によく自分で手を動かすのと人に訊く比率がバグってる奴がいるよな 本人は自覚があるから分散してるつもりだろうけど一回そう思われたら終わりなんだよ 職場で塩対応されてるんだろうな >>835 GetThemeColor じゃだめ? COLOR_HIGHLIGHTとCOLOR_HIGHLIGHTTEXTじゃないの? read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる