Create a form from a worker thread .net

[ASB]

.NET 2.0

Some code is running in the context of a .NET console app. It happens to be its main thread, obviously there is no message pump on this thread.

This thread needs to create a form. So it needs a UI thread.

Once it has a form it can marshal the calls to that thread via form.invoke or via the synchronization context which was current when the form was created.

So, I create a worker thread; and within this call application.run.

Problem is creating the form on that thread.

If it was only ever one form I could create it before calling application.run; but there are many - and multiple - forms that I need to create.

I only know which ones from the worker thread; thus I need either a sync context or a form in order to be able to marshal execution to that thread. But of course the sync context doesn't exisit until a form is created.

Any suggestions?

Hack is the create a dummy form and marshal to this. But surely there is a better way.

[DimPrawn]

If you want a multiple form .NET application it begs the question why you have a console application to start with?

[eek]

If you want a multiple form .NET application it begs the question why you have a console application to start with?

got to agree. That approach sounds very back to front.

[DimPrawn]

I smell a Bob behind this "requirement".

[eek]

I smell a Bob behind this "requirement".

Regardless of nationality he's a muppet and not one of the cleverer ones.

[ASB]

Whatever.

I shall just go tell the clients and developers of the applications etc that they are a bunch of ******* and have to rewrite it all because they didn't have the foresight to see a change which was going to be mandated some 10 years after the original design and implementation.

Obviously all the great and the good just tell their clients this, never change anything other than to say "ooh you can't do that;means a total rewrite"

The fact is that is the way it is. The application pre-exists and is a console application driving a pre existing set of peripherals that are not a screen.

Now due to various changes it needs some windows. These are hooked at various points in the application apis.

[/rant]

In the real world it's sometimes necessary to work with the things one has. Not the things one would prefer to have.

[DimPrawn]

Perhaps a solution is to have the console application communicate data/messages to a new windows forms application via WCF named pipes / TCP rather than tacking forms onto the console app?

I'm sure you know about WCF client / server but if not, here's a little intro article:

http://tech.pro/tutorial/855/wcf-tut...-communication

[ASB]

Perhaps a solution is to have the console application communicate data/messages to a new windows forms application via WCF named pipes / TCP rather than tacking forms onto the console app?

I'm sure you know about WCF client / server but if not, here's a little intro article:

WCF Tutorial - Basic Interprocess Communication - Tech.Pro

I did look in that direction. Essentially producing a seperate app and sending data into it purely for ui purposes.

The issue is this is only half of the problem. The component that produce the forms etc are fully developed and there is a degree of reluctance there to do much change. They of course take the view that its all fine when called on a ui thread.

Thus I am trying to create an abstraction layer to broker between them which will ensure the forwarded calls go through on a ui thread. If I ingerit a form with no visuals I can get its sync context, this gives me an ability to get the code onto a ui thread and forward to the external library.

Its sure a firkin mess. But glueing things together is a right pain in the arris.

Ther other alternative would be a dispatcher. But I cant go beyond 2.0.

This sort of integration is always deep joy.

Just thought there might have been something id missed rather than dont start from there.

[DimPrawn]

I'd post a detailed description of the problem on stackoverflow and hope someone has been through the hoops and has a solution. Good luck, but if it were me i'd decouple the existing console app and put the UI forms into a dedicated windows forms application and have them communicate by some interprocess protocol. I've been bitten on the arse before by these sort of multiple app in a lump kludges before and not been thanked for the results, when the threading model doesn't work quite right.

[ASB]

I'd post a detailed description of the problem on stackoverflow and hope someone has been through the hoops and has a solution. Good luck, but if it were me i'd decouple the existing console app and put the UI forms into a dedicated windows forms application and have them communicate by some interprocess protocol. I've been bitten on the arse before by these sort of multiple app in a lump kludges before and not been thanked for the results, when the threading model doesn't work quite right.

Agree. If my code were responsible for the control of the ui forms that's what i would do. Unfortunately its the api into the other external components which manages them. So im stuck with trying to give those the threading environment they need.

My arse will get bitten somewhere.