2012-01-04 3 views
1

実験では、Moveが実行されたときにResizeイベントが発生することがわかりました。それだけでなく、Moveアクションはサイズ変更の要素も保持します(文字通りMove = Resize)。実際には、フォームがMoved(ユーザー別)のときに、BeginInvokeで別のスレッドのサイズを変更すると、次のMoveイベントが発生したときに元のサイズ(移動開始前のサイズ)になります。他のスレッドから変更された場合は、移動時にフォームサイズを保持しますか?

ビジネスユースケース/例:ユーザーが動的なサイズのアイテムを含む動的なサイズのListBoxを含むスクリーンを開くと、アイテムの人口にかなりの時間がかかることがあります。並列スレッドでロードが行われた後、BeginInvokeが呼び出されてDataSourceが更新されます。 DataSourceが更新されると、可能な場合は画面上のすべてのアイテムに対応するようにフォームサイズが変更されます(変更されていない場合はページ番号が表示されます)。デフォルトのアプローチでは、リストが自動的に元のサイズに戻ってしまうので、ユーザーが画面を横切ってフォームを移動している(別の画面が最も良い例になる)場合、サイズの更新は効果がありません。

質問:移動やサイズ変更の動作をオーバーライドして、新しいサイズを消費し、元のサイズに戻さないようにすることはできますか?私はWndProcハッキングを調べるべきですか?

+0

私のアドバイスはそれをやって忘れることであろう、プログラムでフォームのサイズを変更することは決してありません。これはユーザーが行うことです。そして、ユーザーが選択したサイズを覚えてみてください。これは予想される動作であり、ユーザーがデータに合わせてフォームのサイズを変更しないと、ユーザーを責めることはありません。個人的には、ソフトウェアがこのような方法で私と一緒に巧みにプレイしようとすると、とても迷惑に思えます。 –

+0

@Mike:あなたの返事をありがとう。問題は、一般的なピックリスト/セレクタであり、1つのアイテムを含む可能性があり、コンテキストに応じて200を超えることもあります。 200アイテムでほぼ画面全体を占めています。これとは対照的に、1つの孤独なアイテムがある白いスクリーンを想像してみてください。あなたのアイデアに基づいて、回避策があります:ユーザーがフォームを動かしているときに、自動的にサイズを変更しないでください。代わりに、フォーム(つまりボタン)に手作業でサイズを合わせるオプションを用意し、ユーザーにそれをさせる。究極の解決策ではありませんが、私の現在のアプローチよりもはるかに優れています。 – Neolisk

+0

さて、問題は、アプリケーションから特定の動作が期待されることです。この動作を示さないアプリケーションは、奇妙なものとして認識されます。つまり、Windowsエクスプローラを見ると、1つのファイルだけでフォルダを開くと、サイズが変更されません。人々はこの種の行動に慣れており、それは彼らが正常とみなすものです。 「サイズに合わせる」ボタンはとても良いアイデアです。 –

答えて

0

私の答えが3ヶ月遅れているのかどうか分かりませんが、私はForm.ResizeBeginForm.ResizeEndイベントを処理することでこの問題を回避しました。これらは、ユーザーが画面上でフォームをドラッグしてドラッグを開始するたびに呼び出されます。 ResizeEndイベントハンドラで

if(beingMoved) 
    needsExplicitSizing=true; 

:ResizeBeginイベントハンドラBeginInvokeメソッドから呼び出されるメソッドで

beingMoved=true; 

beingMoved=false; 
if(needsExplicitSizing) 
    this.Size = new Size(width,height); 
+0

私は一種の解決策をとってきました。 。ベースラインは、安全に処理できるようになるまでこのサイズ変更を延期することです。それにはさらに注意点がありますが、質問には答えがないので、あなたの投稿を回答としてマークします。ありがとう。 – Neolisk

関連する問題