Message Loop in Console App?

So it's as easy as starting a thread and calling Application.Run, and the COM object will find that message loop and use it appropriately?  That would pretty much be the threads entire purpose I assume?  Also, do I have to call Application.Exit from the same thread, to exit the message loop?  I don't ever expect to get a message on that loop as I said it is simply need to have a message loop to satisfy the com object requirements.

Yes, that's basically it, but the COM object will not "find" the message loop. It must be run from the thread where you created the message loop, since Windows messages are per thread. And calling Application.Exit will tear down the message loop, so that it's a good idea to call this when you're done. Or just assign the thread's IsBackground proprrty to true and let the thread in the message loop, it will then be aborted when the application closes.

How can I run the COM object on the message loop thread if Application.Run never returns and I will not be receiving any windows messages?  I seem to recall a method that will allow me to schedule method executions for the applications Message Loop thread, InvokeLater or something.  Would this work?

Yes, you can create an invisible form (for instance, which is minimized and not shown in the taskbar), and then you can call it's Invoke() method to have things run in its thread.

OK, only two more questions.  I assume the form must be created on the thread with the message loop.  Is it OK to do this before the loop is started?  Also, is using a form's invoke method the only means to guarantee code executes on a given thread?  It seems like this would be a useful feature in non windows forms applications.

Well, the handles are not allocated when you call the constructor, so you SHOULD be able to construct the form before calling the thread. But I'd rather do it in the thread to be on the safe side, where lies the problem of doing this?

The Form.Invoke() method will put a message in the message queue which is then dispached via message loop. The handler for this specific message then executes the given delegate, and since it was called fromt he message loop, in the thread where the loop is running. You can think as sort of injecting code into the message loop.

To do this with any Thread, you can use the Abort(object) method and handle this in a catch block of the thread, issuing an ResetAbort() inside that block to make the thread continue to run. But since this raises an exception in the thread, it's only suitable for very specifically for this built threads.

OK, I've upped the point value since you've helped me so much!

I guess I don't see how to create the object after the message loop is started.  If I call Application.Run() (no argument version) this function never returns.  You are telling me I can execute arbitrary code on this thread by using Form.Invoke(), but how do I execute the code to create the form on the thread?  Since the form does not exist yet, I obviously can't use Form.Invoke for this purpose.  It sounds like I would need to pump a message to the MessageLoop thread to get this done.  Is this correct?  If so, how do I pump a message to this specific MessageLoop.  Or, since I will have a form, maybe I can use a custom ApplicationContext object to handle this?  I believe it's constructor gets executed on the MessageLoop thread, correct?  If I attempted to use Application.Run(Form form) I believe that version shows the form which is not acceptable.  So, is Application.Run(ApplicationContext ac) the way to go?

Well, like this:

public class ApplicationForm(): Form {
...your form here...
}

public ApplicationForm applicationForm;

private void ThreadCode() {
     applicationForm=new ApplicationForm();
     Application.Run(applicationForm);
}

...your code here...
     new Thread(new ThreadStart(ThreadCode)).Start();
...wait some so the other thread starts and creates the form...
     applicationForm.Invoke(...);

That should to the trick!