How it works...

There are two new topics here: an event where the super can be canceled and the lookup code. We just know that FormControlEventArgs can be cast to FormControlCancelableSuperEventArgs. If it isn't, we will get an error at run-time.

We have made three assumptions, which we could test for and throw an exception at runtime:

• The control is bound to a data source.
• The bound data source is a SalesLine record.
• FormControlEventArgs can be cast to FormControlCancelableSuperEventArgs.

We could make the code more robust by considering the following:

• Testing that the control is bound:

if (sender.dataSourceObject() != null)

• Test that the bound data source is based on SalesLine:

 if (sender.dataSourceObject().cursor().tableId == tableNum(SalesLine))

• Testing that FormControlEventArgs can be cast to FormControlCancelableSuperEventArgs by:

if ( !(FormControlEventArgs isFormControlCancelableSuperEventArgs))
{
    // throw a suitable error e.g. "<class>.<method> was called 
    // incorrectly"
}

In many cases, the assumptions are appropriate because the code can only be called if these assumptions are true anyway. A table data-event sender parameter will always be the table it is handling.

Lookup code is common for most lookups. Lookups would usually be written on the table that we are applying the lookup to, but in our case this isn't possible. The form event handler class is sufficient in this case as the lookup is specific to a form of control.

We had two other options for writing the lookup and query. One was to use an inner join—this would allow us to add fields from the service order line to the lookup grid. This would also cause duplication if the same item was added to a service order. The other option we had was to make the lookup simply use the ConVMSVehicleServiceLine table, and just add a range.