2013年07月23日

東方レスキュー補足記事 - 最小化時のGetWindowRectの罠2

昨日の件で、ではプログラムする側から考えてどのようにするか、ですが、昨日のブログの参考リンク先にも書いてあるAPI GetWindowPlacement() を使うことでしょうかね。

あるいは、GetWindowRect() で得られた値に、あからさまにおかしな値が入っていたら、バカ正直に信用しないことも挙げられます。

実際の所、この「ウィンドウ位置の保存」を完璧にこなそうとすると、色々な困難があって、

負の座標だからといって、あり得ない座標とは限らない。デュアルモニタを採用し、右側に配置したモニタをプライマリに設定すれば、左側のモニタは負の座標となる。
今まで正しかった座標だからと言って、明日も正しい座標とは限らない。デュアルモニタからシングルモニタに戻せば座標範囲は縮小するし、画面解像度は何時変化するかわからない。
・中抜けの座標がないとも限らない。

ということがあります。
本格的に行うなら、画面環境を構成する全てのモニタを列挙し、その範囲内に収まっているかを検証するなどの方法もあります。
意図的にウィンドウの半分だけを外に出しておきたいユーザーもいるかもしれないことも考慮して、画面の一部でも範囲内に収まっていれば良いのかもしれません。

そういえばデュアルモニタ構成の場合の「最大化」って、どういう状態を指すのでしょうか。
2つのモニタに跨がって最大化? それとも、プライマリモニタ内を占拠することが最大化?

同じく、画面中央表示はどのような状態を指すのでしょうか。全ての画面の平均値が中央?
プライマリモニタ内の中心が、画面中央?

そういえば、CHMヘルプを表示するWindows標準のプログラムが、「最大化状態」のままプログラムを終了すると、次回起動時に「全てのモニタに跨がった最大状態」で起動するとかいう不具合(?)を抱えていたのを思い出しました。
マイクロソフト純正のプログラムですらこの有様なので、一般のプログラムが誤った理解をしてしまうのも無理は無いかもしれません。

結論として、あまり凝った、ウィンドウ位置の保存処理は行わない方が良いんじゃないかなぁと思ったりしています。
posted by ayacy at 00:00 | Comment(0) | TrackBack(0) | ゲームソフト作り
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/71180571
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック