Before we start, check whether that the relation ConFMSVehicleTable on ConFMSVehServiceTable has the CreateNavigationPropertyMethods property set to Yes. This will create a navigation property method that appears as the table name. You can change this using the NavigationPropertyMethodNameOverride property. This is useful because it is possible to have more than one relationship to the same table. This property allows you to give each relation method a unique name.

We will use this in the following code to get the service table's vehicle record in order to determine whether it has a schedule:

public boolean hasServiceSchedule()
{
    ConFMSVehicleSchedId serviceSchedId;
    
    serviceSchedId = serviceTable.ConFMSVehicleTable().VehicleSchedId;
    if(serviceSchedId != "")
    {
        if(ConFMSVehicleSchedule::exist(serviceSchedId))
            return true;
    }
    return false;
}

The choice to make this method public is because it may be useful outside the class.

The ConFMSVehicleTable method on ConFMSVehServiceTable was created for us by setting the relation's CreateNavigationPropertyMethods property to Yes. This method is not visible in the AOT; it is there just to be used. It uses the relation's definition, so if the relation changes, then so does the method. This saves time and simplifies navigation, especially when the tables become more complicated.

In the highlighted part of the preceding code, it may seem strange that we did not check whether a record was returned. AX will always return a record, and if none were found, the fields will be initialized with empty values; they will not be NULL. A normal way to check whether a record was returned is to check whether RecId is 0—its uninitialized value.

In this case, we are interested in the VehicleSchedId field. If a record is not found, then this will be an empty string. If a record that has no value for VehicleSchedId is found, then also it will be blank. In either case, it means the vehicle has no schedule.

The next method involves getting the service schedule record:

public ConFMSVehicleSchedule getServiceSchedule()
{
    ConFMSVehicleSchedId  serviceSchedId;
    ConFMSVehicleSchedule schedule;
    
    serviceSchedId = serviceTable.ConFMSVehicleTable().VehicleSchedId;
    if(serviceSchedId != "")
    {
        return ConFMSVehicleSchedule::find(serviceSchedId);
    }
    return schedule;
}

This method is similar, but what do we do if we don't have a schedule? Since the schedule is not mandatory, we shouldn't throw an error. We simply return the empty schedule record buffer, relying on the calling method to handle it properly.

We should therefore place a comment to this effect, which appears when we use the method.

Go to the top of the method and enter ///, like this:

///public ConFMSVehicleSchedule getServiceSchedule()

AX will replace this with the comment header template. Complete this as shown in the following code snippet:

/// <summary>
/// This method will lookup the <c>ConFMSVehicleSchedule</c>, 
/// returning empty if not found
/// </summary>
/// <returns>
/// An instance of <c>ConFMSVehicleSchedule</c>, empty 
/// if not found
/// </returns>
/// <remarks>
/// This method will not throw an exception if a record
/// is not found.
/// </remarks>

The special tag, <c>ConFMSVehicleSchedule</c>, can be read by AX, which understands that it is a type.

To see this in action, go to another method in the class and start typing this.get. Watch IntelliSense pick up the comment text, as shown in the following screenshot:

We should now create the methods to set NextServiceDate and NextServiceOdo.

The service schedule definition stores the number of days and distance between services. We can add days to a date variable by simply adding the number of days to it, as shown in the setNextServiceDate method:

public void setNextServiceDate()
{
    if(this.hasServiceSchedule())
    {
        serviceTable.NextServiceDate = 
                serviceTable.ServiceDate +
                this.getServiceSchedule().Days;
    }
}

This sets NextServiceDate to ServiceDate plus the days returned from the vehicle's service schedule record. Again, if no record is found, the days will be zero and the next service date will be set to ServiceDate. We will therefore need to add validation to ConFMSVehicleSchedule to check whether days is greater than zero.

The next point of note is that this code will not trigger modifiedField or validateField for the change to NextServiceDate; remember that these are only called from the data bound form controls via the form data source. We can call validateField and modifiedField programmatically, but we run the risk of a recursive loop.

If we want to validate NextServiceDate, we should write a dedicated check method instead, like this:

public boolean checkNextServiceDate(TransDate _nextServiceDate = serviceTable.NextServiceDate).
{
// validate logic on _nextServiceDate
}

This method can be used to test a future state by passing a proposed NextServiceDate value, or check the current record's value using the default parameter.

The next method, setNextServiceOdo, is similar:

public void setNextServiceOdo()
{
    if(this.hasServiceSchedule())
        serviceTable.NextServiceOdo = serviceTable.CurrentOdometer
                             + this.getServiceSchedule().Distance;
}

Finally, we need to hook up these methods with the modifiedField method in our class so that they are triggered when the user alters the ServiceDate or CurrentOdometer fields.

In our class, open the modifiedField method and adjust it, as follows:

public void modifiedField(FieldId _fieldId)
{
    switch (_fieldId)
    {
        case fieldNum(ConFMSVehServiceTable, ServiceDate):
            this.setNextServiceDate();
            break;

        case fieldNum(ConFMSVehServiceTable, CurrentOdometer):
            this.setNextServiceOdo();
            break;

    }
}

This may seem complicated to create, but the way we have created specific methods simplifies readability and allows future changes to be made more easily than writing logic in a single method.

The preceding code is summarized by the following sequence diagram, which follows the events for a form control bound to the NextServiceDate field: