Pierrot le Fou: TESTFIELD and Error Messages in Microsoft Dynamics NAV
My ArcherPoint colleague, the illustrious Matt Traxinger, gave a presentation back at NAVUG Summit 2014 called “Principles of Good Design: Applying The Design of Everyday Things to Microsoft Dynamics NAV.” Matt also gave the presentation internally to the ArcherPoint development staff, and the concept was that we need to consider good design principles as we write code. This idea sort of goes without saying, but I think it was good for us developers to hear it anyway as a reminder. Just like Peyton Manning still runs practice drills throwing the football, or how Daigo Umehara goes into training mode in Street Fighter to do stuff, we developers always need to be sharpening our skills.
One of the specific points that Matt brought up was the idea that we need to avoid using the TESTFIELD command in most situations. I thought this would make a pretty good blog entry, and I figured that since Matt wasn’t writing about it, I might as well give it a try.
TESTFIELD is a pretty simple command. It looks like this:
[RecordVariableName].TESTFIELD([Field Name],[Value])
The command will look at the record specified by [RecordVariableName] and then compare the value in the field specified by [Field Name] to the [Value] parameter. If the field does not match the [Value] parameter, then the user gets an error like the following:
[Field Name] must be [Value] in [table name and primary key]
The [Value] parameter is optional; if [Value] is not specified, NAV will check to make sure that [Field Name] is not blank or zero.
TESTFIELD does a good job of checking that there is a value in a particular record field, but it has one problem that should keep you from using it regularly: It generates a completely unhelpful error message. The user will know that a particular field needs to have a particular value, but they have no idea why that field needs a value, and they may not have any idea what they should put in there or where to find it.
After hearing Matt’s presentation, I stopped writing TESTFIELD statements most of the time. Nowadays, instead of writing a TESTFIELD statement, I prefer to use an IF statement combined with an ERROR and a text constant that explains what needs to be in the field. It’s a particularly good idea if you’re dealing with a situation where you’ve got some conditions that require a certain value in a field. That way, instead of seeing a message like “Unit Price must be 5 in Sales Line Order SO999999 10000,” the user sees a message like “Unit Price must be 5 for all Sales Lines for the FIVEDOLLARCHARGE Resource.” It helps give the user an explanation of why they’ve gotten the error.
Anymore, there are only two times I’ll use TESTFIELD. The first time is when the error message that TESTFIELD generates is the exact one I want. The other time is when I’m dealing with a condition that’s so thoroughly buried in code that the user could have gotten there one of a dozen different ways, and there’s no easy way to determine how things got this messed up.
If you have any further questions about this or other development questions, please contact one of our development experts at ArcherPoint. If you liked this, you might like to read more of Tom Hunt’s blogs, or check out our collection of Development Blogs.