Win32API質問箱 Build127
>>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 これでスナップの影響も受けないし、その上でサイズ変更もやりたければできる。 許容しつつアス比を維持するのもいい。ゲームのフルスクリーンモードとかそんな感じだろうし read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる