An even more convenient printing interface is provided by the KOLReport printing package (this is my development, using one of the above modules - by choice - to perform low-level printing). In fact, this module is ported from the NormalReport component set, which I developed for the VCL.

 

The main difference between this package and all kinds of XXXXXReport, usually used by Delphi programmers, is its minimal visibility. For a programmer who is faced with printing time after time (that is, extremely rarely, like me), a thorough study of any reporting system, in which visuality is brought to deadly perfection, presents certain difficulties. Every time you need to prepare a report, you have to remember where what properties are and how to change them so that everything becomes the way you need it - this is not a task for the faint of heart. This is especially annoying if you really rarely have to deal with printing, once every couple of months or every six months.

 

So I took a different path than providing a fully visual design-time interface. In addition, no matter how super-sophisticated this interface is, it will still have some limitations. And then go and prove to the user that his order with the placement of the logo here in this place on the sheet is not feasible, or that this method of transferring cells to another line is not supported by the print component, and he must accept it.

The final result is actually more convenient for programmers who are great at writing code. It is much easier for a programmer to write loops and use unambiguously understandable language instructions to check all the necessary conditions than to set up a complex visual component, which also needs to be figured out beforehand.

 

So, working with KOLReport is structured as follows. First, you are on the form (for this you can select a separate form, or several separate forms), the cells and rows of cells of the report are "drawn". In general, any visual control, for example, a label or a panel, can work as a cell. But in order for cells to have a white background and can have custom borders without further complicating their existence, the same package implements cell constructors such as TReportLabel and TBand. Of course, they have MCK mirrors so that the report can be designed semi-visually using the MCK environment.

 

Those cells that are used to accommodate fixed information (text and images) can be customized at the design stage. Other cells will get their value just before printing. Of course, it is enough to "draw" one standard ruler, fill it in immediately before issuing it to the report, and reuse it after sending it, creating as many lines in the table as necessary. The process of displaying rulers and individual cells, as well as changing pages, is handled by your code placed in the OnPrint event handler. You have a wide range of methods for displaying cells, formatting them, managing the grouping of information on a sheet, and so on. But the most important tool remains the programming language.

 

Fulfilling the most incredible user requirements is a breeze with this reporting system. And, most importantly, such code is easy to modify in the future and is not at all difficult to maintain (as I have already had the opportunity to see from my own experience). For programmers developing projects using KOL, the argument of the compactness of the resulting application will not be superfluous. For example, the compiled application takes up no more than 40KB in compiled form.