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.
- Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
- Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Reply to: Create a form from a worker thread .net
Collapse
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
- You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
- You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
- If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
Logging in...
Previously on "Create a form from a worker thread .net"
Collapse
-
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.
Leave a comment:
-
Originally posted by ASB View PostWhatever.
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.
Leave a comment:
-
Originally posted by DimPrawn View PostI'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.
My arse will get bitten somewhere.
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by DimPrawn View PostPerhaps 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
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.
Leave a comment:
-
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...-communicationLast edited by DimPrawn; 11 July 2013, 20:19.
Leave a comment:
-
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.
Leave a comment:
-
If you want a multiple form .NET application it begs the question why you have a console application to start with?
Leave a comment:
-
Create a form from a worker thread .net
.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.Tags: None
- Home
- News & Features
- First Timers
- IR35 / S660 / BN66
- Employee Benefit Trusts
- Agency Workers Regulations
- MSC Legislation
- Limited Companies
- Dividends
- Umbrella Company
- VAT / Flat Rate VAT
- Job News & Guides
- Money News & Guides
- Guide to Contracts
- Successful Contracting
- Contracting Overseas
- Contractor Calculators
- MVL
- Contractor Expenses
Advertisers
Contractor Services
CUK News
- Streamline Your Retirement with iSIPP: A Solution for Contractor Pensions Sep 1 09:13
- Making the most of pension lump sums: overview for contractors Sep 1 08:36
- Umbrella company tribunal cases are opening up; are your wages subject to unlawful deductions, too? Aug 31 08:38
- Contractors, relabelling 'labour' as 'services' to appear 'fully contracted out' won't dupe IR35 inspectors Aug 31 08:30
- How often does HMRC check tax returns? Aug 30 08:27
- Work-life balance as an IT contractor: 5 top tips from a tech recruiter Aug 30 08:20
- Autumn Statement 2023 tipped to prioritise mental health, in a boost for UK workplaces Aug 29 08:33
- Final reminder for contractors to respond to the umbrella consultation (closing today) Aug 29 08:09
- Top 5 most in demand cyber security contract roles Aug 25 08:38
- Changes to the right to request flexible working are incoming, but how will contractors be affected? Aug 24 08:25
Leave a comment: