Create a form from a worker thread .net

[jmo21]

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.

Can't you just pull the code out of the console app, stick in a win form app, and solve your current issue that way?

[ASB]

Can't you just pull the code out of the console app, stick in a win form app, and solve your current issue that way?

Sadly not because its maintained and owned by somebody else.

[d000hg]

Have to second (or third or fourth) the new app interop idea.

An alternative way to do that is to communicate through stdin/out rather than pipes... I didn't read all the details to know if that might alleviate some of the problems but it's quite a viable option if they are running on the same box.

[ASB]

Well, the upshot of it is that I have created a wrapper for the public interface of the naughty components. This creates a worker thread on on the it creates a form and then runs a message loop. This gives me an ISynchronizeInvoke from the form a synchronization context.

This expose an identical public interface. When the functions are called the methods are then called via the IsynchronizeInvoke and then they are on the new UI thread.

This seems to work (so far). Bit of a pain because the interface style is lots of parameters into each method call so a fair amount of grunge code to pack and unpack the parameters into objects (ok didn't strictly need to do this but it makes it easier).

Final issue to be resolved was that a bunch of parameters were byref so these need to be manually marshalled back.

There is of course a potential lurking issue if any threads in the client APP are accessing the by ref parameters and expecting to see the values change. But that would be fairly naughty since there is no thread synchronization.

Meanwhile negotiating with the developers of the misbehaving application for a future release which has a less assumptive threading model.

If I do find I'm still stuffed at least I now have the ability to parcel the wrapping code up into a seperate winforms app and communicate with that through remoting or whatever for of IPC I feel like. Also the code is positioned suitablt centrally that I could now do that with zero impact on the client app.