2

わかった。すべてを理解したと思ったら、まだ理解していません。

機能的な appbar クラスをコーディングしてテストしました。単純な Windows フォームを使用してクラスを拡張およびテストすると、XP (SP 3、32 ビット) と Windows 7 (64 ビット) の両方で問題なく動作します。他のウィンドウにもアクセスでき、すべて適切に最大化されます。ただし、「複雑な」Windows フォーム (つまり、アプリケーション) を取得して appbar クラスから派生させると、デスクトップがそれを「キック」するように見えます。つまり、最初はすべてが適切にサイズ調整されますが、その後、デスクトップのサイズが元のサイズに戻ります。これは、フォームを appbar モードにした直後に発生する場合もあれば、フォームの外側をクリックしたとき (たとえば、ブラウザーを開くため) に発生したり、フォームが MessageBox を呼び出したときに発生したりする場合もあります。問題の可能性があると考えて、すべてのフォーム機能をバックグラウンド ワーカーに配置しましたが、結果は同じです。以下に3枚の画像を掲載しました。最初のものは、アプリケーションを初期の WinForm として示しています。2 つ目は、アプリバーが「機能している」ことを示しています。最後は、アプリバーが「機能していない」ことを示しています。問題が表示されない場合は、ごみ箱に注意してください。何か案は？

ここに画像の説明を入力 ここに画像の説明を入力 ここに画像の説明を入力

編集：ログを介してこれらの呼び出しを見つけました。デスクトップのサイズが「通常」に変更されるたびに、それらが起動するように見えます。今、「単純な」バージョンに同様のパターンがあるかどうかを確認しようとしています。

  • msg=0x6 (WM_ACTIVATE) hwnd=0x1e03ea wparam=0x0 lparam=0x0 結果=0x0
  • メッセージ = 0x1c (WM_ACTIVATEAPP) hwnd = 0x1e03ea wparam = 0x0 lparam = 0x1a90 結果 = 0x0
  • メッセージ = 0x1a (WM_WININICHANGE) hwnd = 0x1e03ea wparam = 0x2f lparam = 0x9fe048 結果 = 0x0
  • メッセージ = 0x1a (WM_WININICHANGE) hwnd = 0x1e03ea wparam = 0x18 lparam = 0x9fe038 結果 = 0x0
4

1 に答える 1

1

つまり、これは 1 つの野生のガチョウの追跡でした。私の最後のコメントがばかげているように聞こえた場合、それはそうでした。この理論についてはまだ 100% 確実ではありませんが (誰かが証明/反証してください)、2 つの異なるハンドルは、(1) フォームのインスタンス化と (2) フォームがロードされたときの実際のハンドルに由来します。API は QUERY_POS と SET_POS と同じ概念に従っていると思います。つまり、最初に有効なハンドルをチェックして割り当てるということです。次に、フォームが表示される前に、ハンドル値を二重にチェックします。

簡単に言うと、Load イベントのハンドル値を確認する 1 行のコードで、問題全体が解決しました。

編集:さらに良いことに、HandleCreated イベントはかけがえのないものです。

于 2012-12-13T14:24:29.380 に答える