Check customization is generally easy (at least theoretically) as it revolves around two objects, namely CustVendCheque (a class ) and Cheque_USReport (a Visual Studio Report ).
First we’ll walk through the cheque class itself and see what methods are generally modified to get the checks customized:
1. getSlipText (or fillSlipTxt)
The getSlipText method is responsible for most of the data that is printed on the check slip lines; the key point here is that it is sent as a single block of text which leaves the developer very little room to actually modify the cheque without getting into a stream of circular reference errors (I’d call them ‘black-hole’ type errors, which we will discuss in ‘Check – Intermediate’). So, whatever we need to do as far as Text formatting (for check stubs) goes, we should get it done before this text (‘chequeSlipTxt’) leaves the class.
The output method mainly contains the code for adding the check number to the stub. One can also use ‘\t’(tab) or StrlFix or StrRFix methods for aligning the string lines, such as if a customer wants check Number to fit the pre-printed cheques, we can deliberately use ‘\t’ tabs:
tmpChequePrintout.SlipTxt = strFmt(‘\t\t’+ “@SYS22495″+’ ‘+slipChequeNum+’\n);
The second part of modifying the check is modifying the Cheque Report itself, i.e. Cheque_USReport. If I have lot of modifications involving re-sizing, or particularly changing the layout of the textboxes on the report, I personally try to modify each textbox (or each subsection) and then go for build/deploy to see what the modified cheque looks like. I’ve found it easier to play it by ear this way, rather than modifying all the textboxes and then eventually realizing that you accidentally added some extra space somewhere, causing the text to get jeopardized or print extra pages (every developer’s nightmare).
With that said, yes theoretically there are couple of settings one can tweak around to get rid of the extra page issue, but they don’t work like charm at all (at least not all the time). So, the best bet is to work on a subsection of report, build/deploy and see if that subsection on the check looks the way you wanted (if not, work on the subsection you just modified) , if yes then work on the other subsections turn by turn. It may seem like a repetitive process, but it’s legit and pays in the long run.
We will discuss more about the checks, extra spaces issues and other possible ‘black-hole’ scenarios in my next post. Stay tuned.