As a code-based tool, reports generated with VPE+ are implemented entirely in standard Delphi code. You write code to output text and other objects to a page.

• you are not tied to the constraints of automation often encountered in a visual designer
• there are no constraints on access to data sources, no need to "pipe" or "link" data into the report environment
• there are no constraints on access to code resources
• there are no constraints on how Delphi language features can be applied during report generation

This hands-on flexibility means you can pretty much code whatever is required to get the job done!

The Playing Field

If you're not using a visual design environment for your reporting requirements, then you're probably writing reports directly in code - or code-based reporting. The former is much closer to WYSIWYG - you see a reasonable layout of what your report will look like as you design it. The latter is only code, without visual design layout.

It would be fair to say that most reporting tools these days are based around a visual designer. A WYSIWYG drag-and-drop tool is certainly an attractive solution, and, inevitably, one has to conclude that this reflects perceived demand: most developers look for and expect a visual reporting tool.

On the other hand, you might be hard-pressed to find a code-based reporting solution.

Despite this imbalance of favour, however, I feel there is a strong case for the code-based approach. After all, this is why VPE+ has been created!

My Experience: The Problem With a Visual Design Environment

The biggest single issue I have with visual designers is that they necessarily exist in their own environment. There is an "inside" and an "outside".

On the outside are data sources, and application components and code.

On the inside are tools and report objects needing to utilise those resources.

You access the inside by opening an independent reporting IDE or application.

From this concept stem some very basic implications:

• data sources must exist on the outside before they can be utilised on the inside
• data sources must be "piped" or "linked" into the reporting environment to be accessed
• code and objects on the outside are not necessarily accessible on the inside
• native coding available on the inside is likely to be restricted

These are not issues pertaining to a given report as such, but rather artefacts of the visual designer. ie There are some inherent overheads and trade-offs involved in using a visual designer at the very outset - a point that is typically overlooked. This is not to disparage the concept of visual designers by any means. If you do accept this basic philosophy, then these issues simply become matters to be worked around for the greater gain of what the designer is offering. Conversely, however, if you have a problem with these restrictions, whatever else the designer may offer is very much of lesser significance.

Another conceptual challenge I encountered very early on in my use of a visual designer was that of line spacing and positioning of text and objects.

I wanted a vertical array of 5 single line text fields to appear adjacent to a multi-line comment field. Placing the required text objects on the designer was easy. However, I soon discovered that the line spacing of the individual text objects did not quite match the evenly spaced lines of the multi-line comment field. Dragging-and-dropping these objects was simply too random. Selecting the 5 text lines in the designer and using an alignment option to "evenly space" them, while achieving even spacing, had more to do with how you happened to place the text boxes in the first place, and nothing to do with the even (constant) spacing of text lines given the size of the font. There was no concept of precise positioning, or the ability to reference font metrics to achieve vertical alignment.

It seemed to me that object positioning principally involved a process of "squint and guess" (literally the "visual" of the visual designer). Did it really matter that the lines were fractionally uneven if you looked really closely, or perhaps if the top of the font did not quite align with a drawn line on the page, or if content seemed to finish at a slightly different place on each page? My answer was emphatically, "Yes! It most certainly did matter".

For my mind-set, visual drag-and-drop placement of objects was probably not going to be adequate.

The report I had chosen to emulate in a visual designer by way of a trial just so happened to have a somewhat tricky page wrapping algorithm. It involved multiple fields, consideration of page widows and orphans, and differential break points dependent on data content.

In short, the automated wrapping mechanisms of the designer, while sophisticated, could not achieve the desired result. They simply could not pre-calculate space requirements and make the necessary conditional decisions about where and how to break the page.

The crux of the issue here was the degree of "automation" in the designer. Automation is a necessary concomitant of the visual environment where there is little recourse to alternative methods of control. For the most part, this is an advantage because it "handles it all for you". However, this same automation becomes a disadvantage if an exception to the rules is encountered and it is not possible to circumvent its behaviour.

As a generality, the greater the automation the less the flexibility.

If the designer cannot handle all reporting challenges, what do you do? Are a few exceptions (or are there more?) enough to discourage using the visual environment altogether? Again, for my mind-set, I wanted a reporting tool that was going to afford me a good chance of being able to navigate my way around ALL the curly reporting issues I might encounter - not just "most".

Code-Based versus Visual Design Environment

So, in a nutshell: The code-based reporting environment is your application environment. One and the same. Whatever your application can access your reports can access.

Providing parameters to a report, for example, is quite direct. You can use any components on any form anywhere in your application with all the necessary event handlers and bindings you may wish to supply information to the report. No special linkages, pipes, or interfacing variables are required.

Although much is automated in the code based context, and much more can be automated for your own specific purposes, you are never really constrained by this automation because you can code anything you like!

For some, this perhaps seems a little on the "manual" side - but generally, the work involved with either approach is quite similar. With a little experience of code-based reporting, you would never want to sacrifice the freedom and precision it offers.

Conclusion

• Code-based and visual-design are two different general approaches to reporting.
• Both have their merits and their drawbacks.
• In different circumstances, one or the other approach will potentially offer the better (or only) solution.
• Like differing styles of code formatting, people are likely to have personal preferences for one or the other.

However, if like me, you conclude that at the end of the day the "cons" out-weigh the "pros" with visual design environments, and you favour hands on precise control, then the open flexibility of VPE+ may well be a great alternative!

Enjoy trying VPE+.