BackgroundWorker Capability For Non UI Classes

[Guest]

I like the concept and features of the BackgroundWorker. However, I observed
that it will only work for clients that implement ISynchronizeInvoke (namely
forms and controls). My instinct is that BeginInvoke uses windows message
loops to synchronize back to the main (UI) thread.

I want this same capability in a business level component so that it can
fire client delegates on the main (UI) thread if it did some asynchronous
work on a background thread, but I don't want to have to force it to carry
around a full 'System.Windows.Forms' form so that I can kludge the
BeginInvoke methods.

Is there a ligthweight WindowImpl that I can programmatically use to post
messages to and handle the callback in a WndProc on the main UI? In ATL I
would create a simple CWindow and host it without a resource file for it or a
visible window. I could receive messages from it and use it to perform
worker thread synch.

Is there anythign comparable in .NET? Or must I carry around the weight of
a complete System.Windows.Form?

Thanks,

 

[Dmytro Lapshyn [MVP]]

Hi Brian,

I used a plain System.Windows.Forms.Control instance to marshal async
callbacks to the UI thread. You can derive from the Control class and create
a Singleton that all the business components will be aware of. It is not
necessary to make the control visible in any way, but you should ask for its
handle to make the control create the owned child window.

 

[Stoitcho Goutsev \(100\)]

Brian,

BackgroundWorker doesn't require any control's to be created. If the thread
that calls the RunWorkerAsync has a message loop runing at the moment of the
method call the BackgroundWorker will marshal correctly the ProgressrReport
and RunWorkerCompleted events to the UI thread. It doesn't matter if there
are any forms or controls created.

Actually unless you use PInvoke I don't see how a managed application can
create a UI thread (run the message pump) without using the Application
class, which is part of System.Windows.Forms.dll.

One last thing. I don't understand your worries about the windows forms dll.
It is already installed on the machine as part of the .NET framework.

 

[Guest]

Thanks, I will give this a try as well.

--
Brian R.

Hi Brian,

I used a plain System.Windows.Forms.Control instance to marshal async
callbacks to the UI thread. You can derive from the Control class and create
a Singleton that all the business components will be aware of. It is not
necessary to make the control visible in any way, but you should ask for its
handle to make the control create the owned child window.

 

[Guest]

The main thread does have a UI, however the main message pump is a Visual
Basic 6.0 implementation. Our system is a COM based plugin architecture and
we are using interop to develop .NET based components.

The invoking component is on the main thread and, hence, does have a UI,
however I was concerned that it wasn't a .NET message pump and the client
that invokes the BackgroundWorker is merely a .NET class with no UI
components.

Are you confident that the call would be marshalled back to the main UI in
this instance.

Also, I wasn't concerned about loading or distributing System.Windows.Forms,
I was more concerned about having to show a form or keep a form around when
it seemed like more code and capability than needed.

Thanks,

--
Brian R.

Brian,

BackgroundWorker doesn't require any control's to be created. If the thread
that calls the RunWorkerAsync has a message loop runing at the moment of the
method call the BackgroundWorker will marshal correctly the ProgressrReport
and RunWorkerCompleted events to the UI thread. It doesn't matter if there
are any forms or controls created.

Actually unless you use PInvoke I don't see how a managed application can
create a UI thread (run the message pump) without using the Application
class, which is part of System.Windows.Forms.dll.

One last thing. I don't understand your worries about the windows forms dll.
It is already installed on the machine as part of the .NET framework.

 

[Stoitcho Goutsev \(100\)]

Brian,

I was looking at the code of the BackgroundWorker. There is nothing that
uses any windows forms control unlike the implementation of
System.Timers.Timer class where the sychronization is based on
ISychornizeInvoke interface (usualy controls).

BackgroundWorker uses the AsyncOperationManager class and works without
controls, but the thread has to have running pump. I believe that it still
uses windows messages but it post them directly to the thread not to any
window.

I tested it with message loop and no controls, but the message loop was
created using the Application class. I don't know if it works with UI
threads where the message loop is created in some other way. You should give
it a try. I can't set up such an environment easy enough in order to test
it.


--

Stoitcho Goutsev (100)

The main thread does have a UI, however the main message pump is a Visual
Basic 6.0 implementation. Our system is a COM based plugin architecture
and
we are using interop to develop .NET based components.

The invoking component is on the main thread and, hence, does have a UI,
however I was concerned that it wasn't a .NET message pump and the client
that invokes the BackgroundWorker is merely a .NET class with no UI
components.

Are you confident that the call would be marshalled back to the main UI in
this instance.

Also, I wasn't concerned about loading or distributing
System.Windows.Forms,
I was more concerned about having to show a form or keep a form around
when
it seemed like more code and capability than needed.

Thanks,