Question

We have a DLL that monitors changes in status and looks for events from a separate, purchased product. Actually, it is a ScreenPop API from Siemens, for those of you who may know what that is. I am using C#.NET 3.5 as the platform.

This API takes a looong time to initialize, so we want to use a separate thread to initialize it. Currently, we have the functionality in a class called ScreenPop. The class monitors 2 events, a status change event and a screen pop event (data that tells us who the customer is that is calling).

The way this is currently implemented doesn’t work, or at least doesn’t work reliably. Within the ScreenPop class, there is an initialization method where all the long-running startup code is placed. This is called from the constructor of the class, like this:

public ScreenPop( string Address, int Ext, CallbackStatusType pStatusFunc,       CallbackScreenPopType pPopFunc  ) {     CallbackStatus = pStatusFunc;     CallbackPopup = pPopupFunc;      Thread t = new Thread( StartInBackground );     t.Start(); } 

In the GUI code, the func at pStatusFunc updates a status label, and the func at pPopupFunc will fire off some other code to do the screen pop – right now it just displays the data from the event.

There is a lot of glue missing, but I hope you get the point. The problem with this approach is the GUI is not updated. I know the events fire and the event handlers run, and the callback functions are getting called and they seem like they should be running, but the GUI is never updated.

So, my question is, should I abandon this in favor of a BackgroundWorker approach? Or am I just missing something in getting the GUI to update?

More info on request… Thanks, Dave

Answer 1

You can never update the GUI from a different thread – only from the UI thread, which is the one that started the application. You need to use the Control.Invoke method to run code on the UI thread. Form instance, frmMain.Invoke.