Is BackgroundWorker a good subsititute for AsyncOperationManager?

Question

Here's what I'm trying to solve:

My class (which could be hosted by an UI app or a windows service or whatever), needs to receive windows messages. Somewhere around here, someone gave the suggestion (and some source code) to create a windows form in a separate thread that will create the form and whenever a windows message that I'm interested in receives on the WndProc, it triggers a delegate using context.Post.

I've been trying to make it work but unsuccessfully. Instead of spending more time on that avenue and before I try to replicate the problem I'm having there to post here for help, I'm thinking I'm going to try to implement the same solution using BackgroundWorker.

From the tests that I've done, I would expect it to work pretty good when I'm using UIs, but my question is: is there any advice against using BackgroundWorker when not dealing with UIs?

Edit: The way I'm envisioning it, every time my "child" form (the one running in the background worker) receives a message, I will issue a ReportProgress. The only thing that I need to pass through threads is the message ID, so technically it should suffice right?

Answer 1

I would say if its at most every 5 seconds, then you should be fine passing the message id (as userState) back via the ReportProgress event.

Answer 2

The BackgroundWorker object is an excellent method of performing the tasks you're looking to perform. You may, however, find that a simple message ID is no longer sufficient when you get things coded up, but the BackgroundWorker.ReportProgress method allows you to pass in a state object. If you code up an efficient state object you can literally send back thorough snapshots to report back to the parent form.

Answer 3

BackgroundWorker and a window are water and fire. A window requires an STA thread and a message loop, neither are provided by BGW. Check my answer in this thread for an alternative.