Most of the applications that I write are hour long sequential tests for electronic equipment. The equipment under test has a specification that is a state-machine that looks like...
- Get the equipment into mode A.
- Now that the equipment is in mode A, do a test.
- Get the equipment into mode B.
- Now that the equipment is in mode B, do another different test.
- Get the equipment into mode C.
- Now that the equipment is in mode C, do a third and final test.
Note, that the equipment can only be put into mode B after going through steps 1 & 2. Then, the equipment can only be put into mode C after going through steps 3 & 4, so on and so forth. So therefore these steps have to be run in the exact order, or the equipment won't respond. Because of this model, most of my applications will consist of the following:
- A field, where the results of the test steps are displayed as they happen.
- START button (get the task running, performing the test).
- STOP button (launch some cancellation token to the task).
- PAUSE button (pauses the task, with ManualResetEvent).
The applications will typically perform in the following way:
- The user clicks on START and a Task will get started that runs all the steps of the test.
- As the steps of the test get completed, events will be launched that are consumed by the GUI.
- The GUI consumes the events launched by the Testing thread, and displays the results of the tests (contained in the event arguments).
Note, the only reason we even use one Task to begin with is to keep the Windows form responsive.
I am trying to adopt my coding style as much as possible to keep up with the trending patterns. I am thinking about using some of Microsoft's newer features such as async/await in order to accomplish my same old method of writing programs (shown above).
Does the state-machine-esque style of the software warrant a good use-case for async/await? Will I be able to adopt this event-driven procedural style into using async/await?