1

Compact Framework のフォーム ペインティングで奇妙な問題が発生しています。基本的に、ShowDialog を使用して別のフォームの上に開かれる小さなフォームであるログイン ダイアログがあります。カードがスワイプされると、ログイン ダイアログが閉じ、いくつかのログイン タスクが実行され、その背後にあるフォームがアクティブになるはずです。問題は、ログイン ダイアログの背後にあるフォームが更新されていないため、何らかのユーザー アクションによって背後のフォームが更新されるまで、ログイン ダイアログが削除されないことです。これはおそらく、ログイン タスク部分で実行される重い処理によるものですが、これを解決する方法が見つかりませんでした。

基本的に、負荷の高いログイン タスクを実行する前に、アプリケーションに強制的にダイアログを閉じてすべてを再度描画させる方法が必要です。私は運がなくても多くの更新方法を試しました：

Form loginDialog = new Form();
DialogResult result = loginDialog.ShowDialog();
loginDialog.Dispose();

//I've tried everything at this point to get the form to refresh before performing
//login tasks
this.Refresh();
this.Invalidate();
Application.DoEvents();


PerformHeavyLoginTasks();

誰が何がうまくいかないのか知っていますか？ありがとう

4

2 に答える 2

1

私はこれを理解しました。問題は、長方形などを使用して自分自身を手動で描画する背景フォームのカスタム コントロールにありました。そのコントロールでも Refresh と Invalidate を呼び出し、再描画する必要があったため、これはコンパクトなフレームワークのバグだと思います。Invalidate と Refreshed はほとんど無視されていたため、コントロールの OnPaint オーバーライドを直接呼び出すメソッドを作成する必要がありました。

于 2010-09-21T18:15:46.723 に答える
0

The issue, I believe, is that you're not fully understanding what's going on system-wise here.

When your fore window (the Dialog) is dismissed, the background window (the Form) is given focu and tol to repaint the clipping region where the dialog was. This happens via a PostMessage call, which sends a Windows Message that has to be popped, translated and dispatched down in the bowels of the Application.Run call.

This is, by design, a fairly slow process as the UI should not be preempting things that are important.

If you are doing heavy processing immediately after that PostMessage happens, the processing of those windows messages can often be slowed, ending up with the UI appearing "locked" or drawing really slowly. This is exacerbated if the processing you're doing is on the same thread as the UI.

Why are your efforst not making things better?

  • Calling Refresh simply sends another message. That message now gets in line for processing, so it would actually make things worse.
  • Calling Invalidate does pretty much the same this as Refresh, just asynchronously. Again, it makes things worse.
  • DoEvents tells the message pump to pop, translate and dispatch a message. That dispatch still has to be processed on the UI thread, so noting is going to happen until the thread has time to do the work (i.e. after your processing)

So how do we "fix" this?

The first step is often to put the processing on a separate thread to allow the scheduler to round-robin tasks between the UI and processing threads, up to the default quantum. Thgis means that the processing can only starve the UI for a maximum of 100ms before some sort of drawing is allowed to occur (assuming equal thread priority).

new Thread(PerformHeavyLoginTasks)
{
    IsBackground = true
}.Start();

You can go a step further and give the UI a "jump start" on the processing (of 10ms in this example):

new Thread(new ThreadStart(delegate
    {
        Thread.Sleep(10);
        PerformHeavyLoginTasks();
    }))
{
    IsBackground = true
}.Start();

Of course this may mean you need to now handle the next "display" asynchrously if the UI you want to display is dependent on the processing result. There are plenty of online resources for async patterns, so I won't beat that dead horse here.

于 2010-09-21T18:20:08.760 に答える