Resolved Looking for a suitable example of threaded windows forms app

SilverShaded

Well-known member
Joined
Mar 7, 2020
Messages
93
Programming Experience
10+
Hi im looking for some guidance/example of a windows forms app which has the follwing featrures:

An independant solver engine
Seperate winforms interface
The solver engine sends information back to be displayed in the interface periodically
The interface is used to configure the solver engine

I had something working but not reliably, if the interface was re-configured while the sover engine was running it caused conflicts
Just after any hints or example anyone might be able to point me to as threaded programming is new for me.
 
Solution
then transfer the results back to the original flowsheet
If it's simpler to swap out the starting flowsheet for the solved one then you could make it an output of the BGW's work (the runworkercompleted event has an args with a Result property, and the event is also fired on the UI thread for ease of updating controls with the result. If it were as simple as "bind the flow chart display control to a new flow sheet" then the runworkercompleted could perhaps do that binding which would update the UI)

Progress might be a bit more difficult - do you have access to change the code that makes the progress? Can you insert a regular event emit (for exampel) to say that 10%, 20% 30% etc is now done? If so you can capture those events in...
Just had a thought, if i serialise and then deserialise the flowsheet that might be the simplest way to clone it?
Realistically there you're merely relying on the serializer's "enumerate every property and store its value" reflection routine; there must be some alternative deep cloner tool that does the same reflection inspection without tripping it through a string.. I'm sure I've seen e.g. AutoMapper be used for it before (the source and target type are the same)
 
That would suggest that the solver engine is not as independent as you described in your original post.
The engine can be run entirely independently from the graphics via text files.

Alternatively the engine can be configured and run via the graphics interface. So the engine does not need the graphics interface at all to be able to build a model and run. However, clearly when using the interface data and objects are passed to the engine, its just easier to translate the graphical topography in to the engine that way.
 
Last edited:
Realistically there you're merely relying on the serializer's "enumerate every property and store its value" reflection routine; there must be some alternative deep cloner tool that does the same reflection inspection without tripping it through a string.. I'm sure I've seen e.g. AutoMapper be used for it before (the source and target type are the same)
Thanks, Ill have a look at that.
 
The engine can be run entirely independently from the graphics via text files.

Alternatively the engine can be configured and run via the graphics interface. So the engine does not need the graphics interface at all to be able to build a model and run. However, clearly when using the interface data and objects are passed to the engine, its just easier to translate the graphical topography in to the engine that way.
Ah, so it can be completely independent movie, but you are not currently using it in that fashion where you have it dependent on UI.
 
Ah, so it can be completely independent movie, but you are not currently using it in that fashion where you have it dependent on UI.
I have no idea what your point is, if something is running and configured by an interface then in that mode its obviously dependant on the interface. It's kind of implied by the word interface. I fail to see what the point of your comment is. If my use of the word independant has triggered you in some way I profusely apologise.
 
If we were talking missiles, independent means fire-and-forget. Fly-by-wire is not independent because inputs from the launcher are still beingused by the missile. It sounds like your solver can be run either in fire-and-forget mode by feeding it a input file, or it can be run in fly-by-wire mode where inputs come in through the UI. Unfortunately, the fly-by-wire mode isn't working too well when UI changes are made while the solver is in the process of running. You need to put a diode in wire so that you can only see outputs, or not send any inputs via the wire while the solver is running.
 
I think the fly by wire approach is still feasible, going to try it, the solver will be ok if numbers change it just can't handle topogrophy changes on the fly. So if i block them from happening while solving it should be ok. Using a combination of everything both respondees have suggested above. Actually its been really helpfull as originally i was just stuck trying to understand Lock!
 
That's awesome news!
 
Back
Top Bottom