AX / Dynamics 365 For Finance and Operations blog

In this article, we’ll walk through a practical scenario that many developers in Dynamics 365 Finance and Operations (D365FO) face: limiting the number of characters a user can input into a form field without altering the table field definition itself. During this process, we’ll explore using the validateWrite method in a data source of a form.

Initial Goal and Approach

The objective is to restrict the number of characters that can be input into a field (ProprietaId) on a form. Initially, our approach focused on utilizing the validateWrite method for the data source. This approach ensures that the validation logic is applied during the data writing process, offering an effective method for enforcing rules without directly modifying the table structure.

Common Pitfall: Accessing Fields in validateWrite

A common issue when attempting to reference fields within the validateWrite method of a data source arises when using this. In D365FO, you may encounter situations where fields are not recognized if accessed using this.<fieldName>. This is because, within data source methods, fields are accessed via the data source name itself rather than this.

Here’s an example demonstrating the correct approach:

public boolean validateWrite()
{
    boolean isValid = super();

    // Correctly access the field using the data source name
    if (OTS010_Proprieta.ProprietaId && strLen(OTS010_Proprieta.ProprietaId) > 50) // Replace 50 with your desired limit
    {
        warning("The value of ProprietaId exceeds the maximum allowed length of 50 characters.");
        isValid = false; // Prevents the write operation
    }

    return isValid;
}

Explanation of the Code

• Using the Data Source Name: To reference fields within a data source method like validateWrite, you need to prefix the field with the data source’s name (e.g., OTS010_Proprieta.ProprietaId).
• String Length Check: Instead of calling .length() on the field (which is unsupported), use the built-in function strLen() to determine the length of the string.
• Validation Logic: If the field’s value exceeds the specified limit (50 characters in this case), a warning message is displayed, and the write operation is halted by setting isValid = false.

Key Takeaways and Tips

1. Avoid Using this for Field Access: Unlike accessing controls on a form, when working with data source fields in methods like validateWrite, use the data source name instead of this.
2. Use Appropriate String Functions: Functions like strLen() should be used to determine string length instead of attempting to call methods like .length() on a string directly.
3. Form vs. Data Source Context: Always be aware of whether you are working within a form context (controls) or a data source context, as this affects how you interact with fields.

Addressing Edge Cases

During our work, we also noted another common pitfall: not finding fields within the validateWrite method at all. In such cases:

• Ensure Field Inclusion: Make sure that the field is part of the data source.
• Double-Check Naming: Verify that the field name is spelled correctly, and there is no mismatch with its actual definition in the data source.

By following these best practices and correctly utilizing the validateWrite method for data validation, you can effectively limit user input on form fields without the need for table alterations. This approach ensures data integrity at the form level, providing a seamless user experience and enforcing consistent rules.

Conclusion

Limiting field input in D365FO forms using the validateWrite method of a data source is a straightforward and powerful way to enforce business rules. By accessing fields correctly and applying proper string handling functions, you can maintain data integrity while avoiding unnecessary changes to the underlying table structure. This method proves to be particularly useful for scenarios where table-level changes are not feasible or desired.