Window drawn from thread not updating

[Claire]

My progress window is created by a secondary thread and then updated by it
while a file is uploaded. There's an avi animation control on there that
should show the move file avi. Plus a progress bar.
Im having problems as the screen isn't being redrawn properly. If I call
DoEvents each time then it works ok.
I want to dump DoEvents to prevent problems.
I'm calling the following from the progress property set function.
InvokeRequired always fails (as the thread that created the window is also
trying to update the percentage)
delegate void FloatDelegate(float Percentage);

public void SetProgress(float Percentage)

{

if (InvokeRequired)

{

BeginInvoke(new FloatDelegate(SetProgress), new object[]{Percentage});

return;

}

ultraProgressBar1.Value = (int)Percentage;

Invalidate(true);

Update();

//Application.DoEvents();

}

 

[Willy Denoyette [MVP]]

Some questions....
I'm I right to suppose you created a windows form from the non UI thread? If
so, did you start a message pump by calling Application.Run(...); passing a
reference to your progress window form?
Also I guess that your "avi animation control" is an active-X control and as
such need to run on an STA thread, did you initialize the secondary thread
as STA?
And last but not least, why do you need to run this on a secondary thread?
You should definitely try to handle all your UI interaction on a single UI
thread.


Willy.

 

[Claire]

Hi Willy

Some questions....
I'm I right to suppose you created a windows form from the non UI thread? If
so, did you start a message pump by calling Application.Run(...); passing a
reference to your progress window form?

It's a standard windows forms application, the application main form is a
config form for the serial port and it hides itself in the system tray on
startup.

We're using Sax Communications .net controls. The thread is created
internally by their serialconnection component.
The dataavailable event is thrown and it's run in the context of their
thread. I don't know anything further, but the thread ID seems to remain the
same over the application lifetime. There's no technical information in
their help files.

Also I guess that your "avi animation control" is an active-X control and as
such need to run on an STA thread, did you initialize the secondary thread
as STA?

The Avi animation control is part of the Infragistic series of .net
components. It works ok when I DoEvents but not from the thread.

And last but not least, why do you need to run this on a secondary thread?
You should definitely try to handle all your UI interaction on a single UI
thread.

See above. The client drives the communication protocol and my app just
listens, provides services to the client and sits in the system tray (so
this worker thread is in reality the main/busiest thread). The comms
protocol opens the progress form just before a file transfer starts and
closes it when it ends.

 

[Daniel Pratt]

Hi Claire,

My progress window is created by a secondary thread and then updated by it
while a file is uploaded. There's an avi animation control on there that
should show the move file avi. Plus a progress bar.
Im having problems as the screen isn't being redrawn properly. If I call
DoEvents each time then it works ok.
I want to dump DoEvents to prevent problems.
I'm calling the following from the progress property set function.
InvokeRequired always fails (as the thread that created the window is also
trying to update the percentage)
delegate void FloatDelegate(float Percentage);

<snip>

Is the secondary thread on which the progress window created also the
thread that does the file upload? Typically, long-running processes (like
file uploads) are done on a separate thread from the user interface in order
that the user interface will continue to update and continue to be
responsive.

In your case, the secondary thread is busy uploading the file and
therefore isn't processing the window messages that are telling the progress
window to update itself. The DoEvents method causes the current thread to
explicitly go process the window messages in the queue and then return,
which is why calling it causes the progress window to update.

The best thing you can do, IMO, is to create and update the progress
form on the main user interface thread, and do the file upload on a separate
background thread.

Regards,
Daniel

 

[Claire]

Thanks for answering Daniel
That's what Id like/trying to do. Pre .net I'd post a message to the main
form and the main application process would pick it up.
If I use Invoke as was suggested, then the same thread that produced the
dialog would call the progress bar update. So the problem remains.
I can't see how to break out of the thread context and into the main process
in order to create or callback to the progress form.

 

[Daniel Pratt]

Hi Claire,

Thanks for answering Daniel
That's what Id like/trying to do. Pre .net I'd post a message to the main
form and the main application process would pick it up.
If I use Invoke as was suggested, then the same thread that produced the
dialog would call the progress bar update. So the problem remains.
I can't see how to break out of the thread context and into the main process
in order to create or callback to the progress form.

How/where is the progress window being created?

Regards,
Daniel