By using this method, we have added a coupling to the process class structure by means of the binding to the UI builder. This seems to make it so the data contract is no longer reusable for other purposes—but this is actually desirable in this case. When writing processes that use the SysOperation framework, the data contract is used to both pass data and also create the user interface. The only time we might have some sharing is when we are designing a set of processes that share a set of common properties, and in that case, we would use a data contract base class that each specialization would extend.
The process may seem a little complicated at first but, when we break this down, it will become clearer what is actually happening.
The first task was to declare to the DialogField variables that we want added to the resulting dialog, and then to bind them to the data contract data methods. However, in order for this to work, we had to bind the UI builder class to the data contract. We did this by adding the SysOperationContractProcessing attribute to the data contract.
Once this is done, the DialogField variables are now bound to the data contract methods. We then wrote a method to validate the vehicle group control, and bound this to the control's validate event using the control's registerOverrideMethod method.
Once this is all done, the dialog created by the framework can be validated interactively, allowing the user to correct any errors without having to start again.
The changes to the main method were to handle the situation when the vehicle ID should be hidden. We want the vehicle ID to show by default and only be hidden when it is called with a vehicle record. So we set the HideVehicleId data member to No as a default, setting it to Yes if it was called from a vehicle record.