When I started implementing and testing Control 4.0 one of the first things I noticed was how easily I could accidentally calculate prices that were incorrect, from a product definition that was not flawed. The errors stemmed largely from the fact that control would allow me to enter values or make combinations of choices that were simply impossible representations of what actually happened in my shop. Being a programmer I quickly realized that I would need to add what is reffered to as validation code, or sometimes is reffered to as constraints. The lay persons term for this is “Hey you can't do that !”. If you have 1 digital printer, and it can print up to 48“ and will accept material up to 52” wide, then chances are you will only ever buy rolls of material that are 52“ wide or less. Now if you buy a new 96” wide printer, and therefore you start buying 96“ material, what would happen if someone accidentally selected a 96” wide roll to be printed on a 48“ wide printer ? There isn't any circumstance when you would want that to happen, so you now have 2 choices.

1. duplicate the product definition, or the selection lists so that you have a distinct product or selection list for each machine……or

2. add a constraint that limits a user from selecting a material that is wider than the printer he/she has chosen already

I think once you start you'll find there's an endless list of things you could validate so that employees that lack your level of experience can still create valid accurate estimates, and if your error messages are well written they might also assist in training new employees about the way your shop actually produces things.

This how-To will explain the a method that is available to validate input at the product definition level, please be aware that if you require the validation of a single variable, then it might be easier to do that at the variable definition, although validating single variables using this method does allow you to customize the message that the user is given.

Control provides two easy-to-use mechanism for validation of all of the data in a line item before saving, Product Warnings and Product Errors. Both Product Warnings and Product Errors take a valid CFL statement and return either a blank string (i.e. ”“) or a message (e.g. “The material selected is not wide enough to print on.”). If the resulting string is blank, Control does nothing. If the resulting string is not blank, however, Control displays the message to the user he/she clicks OK on the pricing form during order entry. In the case of the Product Warning, the user is shown the message and the screen then closes. In the case of the Product Error, however, the screen stays open and the user must resolve the issue before the pricing form will close. In either the warning or error case, the CFL tests are evaluated either when the product layout pop up window is closed, or when the estimate/order is saved. Product Warnings will cause a dialog box to appear that simply warns the user that something is not exactly right, after a user acknowledged the warning message by clicking [ ok ] the estimate/order continues to save. A Product Error differs in that the user is returned to the data entry screen and the estimate/order can NOT be saved until the error has been corrected.

This how-to demonstrates the use of the Product Warning / Product Error for this kind of validation.

This how-to has a pre-requisite knowledge of the formula builder and CFL. You should have moderate previous experience customizing product definitions.

There are two places that you can write a CFL logical equation, intended to validate user input. They Both appear on the Pricing Tab of the product Definition. The first is the expandable code area named Product Warnings, the second is immediately below and is also an expandable code area, it is named Product Errors

Both Product Warnings and Product Errors require a CFL statement that results in either a String of Text or a False boolean (zero) result, and as discussed in the Concept section you should choose a Warning to simply inform the user, or use an Error if you want to force the user to correct the invalid entry.

You validation code can be as simple as ……

if quantity < 10 then “There is a minimum order of 10 pieces required for this product” else ”“ endif

or more complicated like:

if PartUDFbyVariableName(RollStock_Material, “Substrate - Roll Width”,0) > PartUDFbyVariableName( LargeFormatPrinters,“Printer - Max Width”,0)

Then “The Material you have chosen is too wide for the printer you have chosen, please go back and select a wider printer or a narrower material”


The first example is a more descriptive way of telling the user that there is a 10 piece minimum, the same results can be achieved by setting min/max values to the specific variables but this method allows you to display a message that is more helpful to the user. Specifically if we had set the minimum value of Quantity to 10 then Control would simply adjust the quantity up, whereas this method would allow you to suggest or remind the user of the 10 pcs minimum without actually enforcing this as a hard rule. It would display a dialog box similiar to:

The 2nd example checks to make sure that the material roll width is not larger than the Large Format Printer that has been selected. If the user does select too large of a material width then they would be forced to return to the product dialog and fix the problem after they see the following dialog:

You should always test your code to ensure that it doesn't have any undesired effects, it is for this reason that I always add my validation code to the Product Warnings section first, and only after I”ve tested it will I move it to Product Errors. Regardless of your preferences try and imagine all possible combinations of data entry because nothing is ever truly idiot proof….. someone else is always trying to create a better idiot.

Once you've added your first validation test, chances are you'll think of something else to validate, so how is this achieved ? after all there's only one area for validation code.

The answer is simple, you can have as many individual validation statements as you like, each must be a logical choice that yield a message in string format, or a zero value, and they should be separated by a semi colon ;

The order of your statements isn't critical, but you might want to give it some thought. Control will attempt to resolve all of your validation statements, it will display all of the error/warning messages that result in a single dialog box. Errors show up first then warnings. If a logical test cannot be evaluated (perhaps because you haven't chosen something on the form that is required in the evaluation formula) then it will not appear in the list.

Adding validation code is not a replacement for carefully checking the validity of an estimate, I would recommed that all estimates over a predetermined value be examined by a 2nd estimator before they are presented to a client. It can however trap some of the common errors, yet it should always be used sparingly. If you are noticing an abundance of errors for a given product definition then perhaps there is more than simply data validation to be examined.

Contributor: Neil Balchin, Albion Screen Printing Inc.

Date: 12/3/2009

Version: Control 4.0+

You could leave a comment if you were logged in.