Printable View
Hi,
In a previous post I was trying to achieve the display of an animated gif in a windows app. I had hoped that by displaying it in a webbrowser contro that it would always be animated.
Currently it is only animated when the system is not busy however when the app is processing such as returning data the animation freezes. To prevent this wouldit be possible to get the webbrowser control to run in a different thread, and would this solve my problem?
Cross-thread operation not valid: Control 'uctrlBusyDisplay' accessed from a thread other than the thread it was created on.
The error seems to occur when I try and add the webbrowser control to the usercontrol.Code:public uctrlBusyDisplay()
{
InitializeComponent();
Thread t = new Thread(new ThreadStart(DoIt));
t.SetApartmentState(ApartmentState.STA);
t.Start();
}
private void DoIt()
{
WebBrowser wb = new WebBrowser();
wb.Location = new Point(20, 10);
wb.Navigate("www.google.co.uk");
this.Controls.Add(wb);
}
Basically you can't access controls on a form, they need to be accessed from the same thread that they were created on.
To do this, you should use this.invoke(). It's argument is a delegate of your own choosing (probably just a void, for testing you can use ThreadStart as the type).
Within this delegate's code, you do the control updates.
I have simplified the code. the error only occurs when I try to add the control to the form
this.Controls.Add(wb);
I have tried
but still get the error as I dont really understand the method.Code:Action a = () => { Controls.Add(wb); };
Invoke(a);
Also jumping ahead to when I have achieved this when I have added the control will the webbrowser still control be running in its own thread when it is added to the main form?
The GUI can't be modified from a different thread, nor can any attributes of it's children (Controls).
The description on MSDN is actually really good for this topic, including a great example.
Think of Invoke as Thread.Start, you need to pass it a delegate/method that actually runs the code you want on the separate thread. It's the same, apart from the function won't be running on a separate thread, it will run on the existing thread for the GUI.
You can't access the Handle of a control on any thread other than the one it was created on. As you might imagine, a form would have to access the Handle of any of its child controls. That means that you can't add a control created in one thread to a form created in another.
You're looking at this in completely the wrong way. The WebBrowser is a control, i.e. a UI element, so it should do everything it needs to do on the UI thread. If you have processes that are interfering with the UI then THAT is what you should be moving to a different thread.
OK so when I press the button I should make visible my gif then start a new thread to return the data. I think I could do that.
In terms of threading do I need to kill the threads when the data has been returned? If the user presses the get data button numerous times is it risky to be spawning lots of new threads?
If you create a Thread object and Start it then you specify a method as an entry point. Once that method completes, the thread terminates. Unless you need to use it again while it's running, like to call Abort, you can simply discard the Thread object you created right after calling Start.
If it only makes sense to have a single thread retrieving data at a time then you should limit your code to one extra thread. One way to do that would be to use a BackgroundWorker. You check its IsBusy property and only call RunWorkerAsync if it's False. The backgroundWorker also makes getting data back to the UI thread easier, as long as what you need to do isn't too complex. Of course, another way to prevent multiple background threads is to disable the Button that would start one while one is running. That means updating the UI, i.e. the Button and its Enabled property, once the background task completes. Again, may be easier with a BackgroundWorker.
If it is reasonable for the user to initiate multiple background tasks then you may be best off to use the ThreadPool. That way the system manages the number of concurrent threads. You call QueueUserWorkItem and the ThreadPool executes the task on a background thread as soon as one is available. That will usually be immediately but, if there's a lot of background activity, some tasks may have to wait.
Thanks.
http://www.codeguru.com/columns/vb/article.php/c10755
I found this article which I was going to try and use by converting to C#.
It would give me the option of swapping my Animated gif for a progress bar on a loop also.
Basically this is a VSTO app which returns an Excel report. I am now very interested in the thread pool idea though as it could potentially allow the user to attempt to run two or more reports at once which would be very useful expecially since the bulk of the users wait is waiting for the database to return the data rather than the front end.
Just on a sidenote, picture boxes also support animated GIFs.
Thanks JM this is now resolved using the background worker control using a dowork and work complete handler.
Thanks for the added info about Picture box TBB.