In this article, I’d like to share with you one of the ways to debug through Adobe Forms code initialization routine. The problem is that you can’t just put a session breakpoint in the Code Initialization routine in the form’s interface (transaction SFP). This may be quite annoying as sometimes there is a code you really need to debug through.
As far as I know, it’s not recommended to keep main printout logic in the Code Initialization section, the preferred approach is to pass the ready-to-display data as the import parameter to the interface. But for smaller steps, like fetching a logo or concatenating some values, the Code Initialization routine seems to be the right place.
I’ve been working on a printout that had to contain the client’s logo on it. The BMP graphic was being fetched using cl_ssf_xsf_utilities=>get_bds_graphic_as_bmp in the Code Initialization section of the form’s interface. All worked well on the Development environment, but when we imported the code on Test, the logo ceased to appear on the printout.
The solution I came up with is BREAK-POINT ID. Inspired by this blog post, I created my own checkpoint group in SAAB on the Development environment, assigned it to the transport request, and added one line at the beginning of the Code Initialization section:
BREAK-POINT ID my_checkpoint_group_name.
When the changes were imported on the Test system, I firstly activated it in SAAB:
When saving changes, I picked that I want to keep this activation group active only for today:
And when I executed the form’s driver program, a debug session opened at the BREAK-POINT ID statement:
Of course, it’s not the only way to achieve that. You can put an unconditional BREAK-POINT or a user-specific BREAK [user ID], or find the FM name and put a session breakpoint in %GLOBAL_INIT form, etc.
For bigger development projects (like in my case), it’s probably the best solution to keep BREAK-POINT ID in some key places and activate them only when needed.
Hope this tip will be helpful for somebody.