問題タブ [createwindowex]

WinMain とは異なる cpp ファイルにある関数があり、呼び出されるとウィンドウが作成されます。ただし、その新しいウィンドウのウィンドウ クラスは、WinMain 内で宣言および登録されています。ここで、別の関数でウィンドウを作成すると、CreateWindowEx 関数の 2 番目と 3 番目の変数を再宣言する必要があります。

実際に作成を行っている関数の場所は、WinMain で作成された変数にアクセスできないためです。さて... 私の疑問は、私のプログラムが WinMain に登録したウィンドウ クラスを実際に使用しているのかということです。私が知っている限りでは、これらの変数を再宣言し、WinMain 関数から離れた場所に関数を作成すると、コンパイラが他の標準ウィンドウ クラスを採用する可能性があります。私のプログラムは、WinMain に登録したウィンドウ クラスを実際に使用していますか?

編集: もう少しコードを与える

//++++++++++++++++++++++++++++++++++++++ win main の cpp ファイル:

//++++++++++++++++++++++++++++++++++++++ その他の cpp ファイル:

この最後の関数は、WinMain に配置されておらず、一部の変数が関数で再宣言されていますが、WinMain に登録されているウィンドウ クラスを使用していますか?

私は問題があります。ツールの開発を記録したかったので、スクリーンショットの上に日付を mspaint する代わりに、ウィンドウ名に日付と時刻のデータを持たせたいと思いました。しかし、文字列の代わりに漢字しかありません。

文字列を CreateWindowEx() に割り当てたいコードは次のとおりです。

編集：みんな、あなたの答えに感謝しますが、彼ら全員が私にこれを与えます

やや機能しているのは、まだ削除された回答だけでしたが、次のようになりました。

彼はこのコードを使用しました：

によって作成された子ウィンドウに WndProc を指定できるかどうかを知りたいですCreateWindowEx。

ウィンドウ クラス、メイン ウィンドウ、ウィンドウ プロシージャ、およびメッセージ ループを既に作成しています。コードは機能するので、質問を明確にするためにそれを除外することにしました。

これまでのところ、これは私の Window Proc です。

作成した子編集フィールドでキーを押すと WM_KEYDOWN メッセージがスローされると思っていましたが、そうではありません。キーはウィンドウの編集フィールドに追加されるだけですが、WM_KEYDOWN メッセージは発生しません。

作成された編集ウィンドウは私の WndProc を使用していないようです。どうすればそれを変更できますか?

CreateWindowEx チェックを通過できないため、この作業のほとんどは想定できます。誰かが私の楽しいボタン コードをすべて再確認してくれたら、それも素晴らしいことです。

ここで助けが必要です

残念ながら、はい、ウィンドウの作成に失敗しましたというエラー メッセージが表示されます。

このチュートリアル に示されているように、Windows UAC に似たスクリーン ロッカーを作成しようとしています。バックグラウンドで最大化されたウィンドウ、照明を減らしたウィンドウ、およびデスクトップのスクリーンショットを作成するのに苦労しています。

これまでに試したすべてのコードは次のとおりです。

Microsoft Windows の奇妙な世界を理解するのに苦労しているときに、何年にもわたって多くのスタック オーバーフローを読んできましたCreateWindowEx().. など。 "

WinAPI で次のようなウィンドウを作成するのに苦労しています。

• OpenGL コンテキストを持っている
• 「ウィンドウ」モードまたは「フルスクリーン」モードの場合、マルチモニターとシングルモニターの両方のディスプレイで、メインモニター (またはコマンドライン信号によって決定される任意のモニター) の中央に正しく配置されます。
• クライアントの内部画面サイズが固定されている (viewport 2d)
• 間違ったタイミングで、またはマルチモニターの特殊なケースでフォーカスを失う原因となる外側をクリックすることはできません
• 流動的にサイズ変更できますが、内部の「クライアント サイズ」は変更しません (つまり、固定サイズの OpenGL コンテンツを新しい画面サイズに引き伸ばすことを意味します) ... ここでのアイデアは、仮想化のレイヤーを追加することです。すべてのピクセルは、同じ 1920x1080 (1080p) 座標系で表されます。この部分は私にとっては問題ありません。
• screen->client 比率を介して、screen_size -> client_size と同等のマウス イベント変換を正しく処理します。

自作のアプリ フレームワークでは、表示サイズを設定する必要があります。それでも、Windows は適切なサイズのウィンドウを提供しません。(タイトル バーが差し引かれたり、スクロールバーが差し引かれたりすることがありますが、たとえば、コンテキストはタイトル バーの下に描画されます。)

また、最近 2010 EE (Win32 / Windows 7) から 2015 (win32 / Windows 10) に移行する際、メイン ディスプレイの中心からずれていたため、パラメータを変更してビューを中心に戻す必要がありました。現在、これらの値が正しいか正しくない場合があります。たとえば、「フルスクリーン」にすると、同じ値が画面の上部に描画され、画面の下部に「gl clear color」(私の場合はオレンジ) を示す領域ができます。

次のコマンド ライン パラメーターを指定することで、これらの操作を行うことができます。

• -bordered (デフォルトであり、実際には何の効果もありません。タイトル バーなどを備えたデフォルトのウィンドウ モードです)
• -borderless (win 0,0 が実際には画面中央にあるアプリが中心から外れて、フルスクリーン モードになっているように見えます)
• -windowed (または -window)

-window を指定しない場合、デフォルトで「フルスクリーン」の解像度が調整されます (ただし、サポートされている場合のみ、サポートされていると想定します。サポートされていない場合は、エラーが発生する可能性があります)。

とにかく、これはすべて非常に悪いです.a）1080p用にすべてを書き込んで表示サイズに合わせて調整するのではなく、作業している解像度ごとに膨大な数のケースを書かなければなりません.ラップトップとデスクトップの新しいディスプレイ (これは Windows の記憶です) (そして、これらのコーナー ケースでは、わずかに押しつぶされるだけです) b) ウィンドウのサイズを滑らかに変更できません。デルタのみ -- これは、マウスがウィンドウから離れてデスクトップをクリックしたり、モニターが非表示になっている場合でも、モニターから別のモニターに移動したりするのを避けるためです。また、ユーザーに見えないようにマウス カーソルを非表示にしてから、シミュレートされたマウス カーソルを表示する必要があります。c) 特に 1920x1080 をサポートしていないユーザーは、

誰かが別の質問でこの記事を指摘しました ( Win32 のウィンドウ境界の幅と高さ - どうすれば取得できますか? ): https://web.archive.org/web/20120716062211/http://suite101.com/article/client -area-size-with-movewindow-a17846

そして、私はこれを読んで、AdjustWindowRectEx() にいくつかの問題があることを学びました: AdjustWindowRectEx() と GetWindowRect() は WS_OVERLAPPED で間違ったサイズを与えます

私は WS_OVERLAPPED を使用しないので、これは適度に役に立ちました: AdjustWindowRectEx() と GetWindowRect() は WS_OVERLAPPED で間違ったサイズを与えます

これが私が今それを行う方法です：

上記のコードで得られるのは、サイズ変更機能を持たず、OS マウス カーソルを非表示にし、ALT-TAB (または ALT-F4) でのみ終了でき、終了するとウィンドウの後ろに表示されるウィンドウです。 Windows Z オーダー。全画面表示またはウィンドウ モードで、display.w を 1920 に、display.h を 1080 に設定するパラメータを使用して、常にウィンドウを開きます。次に WM_SIZE が呼び出され、クライアント領域に合わせて調整されます。

次の WM_SIZE は、最初に display.Resized(w,h) を設定した直後の WinProc 中に呼び出されることに注意してください。

これは、アプリのロード中に 1 回だけ実行されます。最初のケースでは、値は次のようになります: 1918,1078

更新:ここで GetWindowRect() の結果、または以下に示すように GetClientRect() を使用すると、ウィンドウが不思議なことに画面の Center-X、Center-Y に移動します! 何を与える??

コンテキストがビューに合わせてサイズ変更され、画面の比率に基づいてマウスが適切に調整されるようにウィンドウを伸縮可能にするには、どのような手順を実行する必要がありますか?

基本的に、これらすべてを理解するにはエッジ ケースが多すぎます。この質問をした 2 年前から時間が経つにつれ、全画面表示とウィンドウ表示の間に別の矛盾が生じてきました。

私が理解していることから、基本的に3種類のウィンドウがあります。

• このブラウザ ウィンドウのような、GUI をウィンドウ操作するための通常の画面上の移動可能/サイズ変更可能なウィンドウ (モバイルを使用していない場合)
• ディスプレイの解像度サポート (ネイティブよりも小さい解像度を含む) に一致するもの - これを「フルスクリーン」(またはフルスクリーン、言葉ではありません) と呼びます。
• 通常の画面上のウィンドウですが、タイトル バー、境界線、およびスクロール バーがなく、画面と同じ大きさで表示されます。「オン・ザ・ストリート」を「ボーダレス・ウィンドウ」と呼ぶ

これらすべてを習得したいのですが、それらすべてにアクセスできるようにし、特別なケースを必要としない方法で。基本的にWinAPIでやるのは諦めていたのですが、明らかに複数の会社がやっています。Microsoft のドキュメントに従うことはあまり役に立ちません。私はさまざまな CreateWindow CreateWindowEx を試しましたが、これらの機能の多くは推奨されていないか、まったく機能しません。

(おそらく、Microsoft はいつこのがらくたを片付けるのだろうか?というのが一番の質問かもしれませんが、私たちは皆、答えを知っていると思います。)

私は現在、C++、Windows API、OpenGL 3.x / 4.x、Windows 10 で作業しています。