Win32API質問箱 Build127
クリティカルセクションで質問です 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 } に近い感じなので マクロにお任せってあまり好きではない(個人的感想) read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる