Jumping back into HUD-1
Over the last week, I have created new rendering classes and moved the beta code to them. I also enhanced the error trapping capabilities of the classes and did a lot of reorganization to the top structure of the class library.
This type of reorganizing is a bit unusual for me, as I usually very clearly see the needed structure of a library in the first few minutes of design. But rendering has been so large, using so many different components, that making it simple and easy to use has been a real challenge.
As I tested the various components of the rendering branch the final structure evolved to a class library with five basic classes.
A containing class
This class is provided for project designers in which to drop all the other classes and to write controlling methods and properties. In that way, it is like the FFForm class used by the earlier version of the Form Framework.
A script rendering engine.
The engine reads a script containing position and size information about various visual elements, such as lines, text, images, opacity and color. It then uses GDI+ to render those elements onto an output. The rendering engine need have only two distinct classes: image and printer. Image creates an image, specifically a bitmap, that can be loaded into a form or control (IE, a print preview form). Printer puts output to a local or network printer.
A script generator.
This class reads script description tables, and invokes a provided data server class to grab data from various sources, puts it all together into a single script and makes it available to the rendering engine. There are no provisions to change the way the tables are formatted or organized, but that could be an enhancement for the future. At present, there is only a single class.
A data server.
This is a base class with all the code necessary to read a formatting table and format the incoming data. What the base class does not have is the code needed to read a particular data source, which is handled by specific code written into a subclass. In traditional fashion, I also refer to this class as the Print Computational Matrix, a very old term for the formatting array used to hold the data and format strings.
Sources for the data server would be:
–A HUD-1 flat file.
–A HUD-1 data form, from either a caption name or an object reference.
–A more complex table or relational database structure.
–An HTTP, FTP or other IP source. Note that this would split the data server into two pieces, with the near piece being only a network client and the far piece being a network server, as well as having the code to grab the data.
–An OCDB connection.
–A MSSQL or MYSQL database.
Each one of these sources, or combination of sources, or even sources not listed here would be handled by a distinct subclass. The subclasses would be written for the particular application, and would work with all the other components and the base code, so long as the data server subclass can find each data item by a distinct name. To extend this even further, a name could even be a distinct query string, as in SQL.
It is in the data servers in which the largest changes were made. I first tried to make the server remote from the generator using object references over two forms, but ran into a problem with closing both forms independently. If the object reference is not disconnected the form will refuse to close. Fixing this problem added so much complexity to the project as a whole, I scrapped it. The form framework is supposed to add simplicity, not “impossibly hard to use.”
My eventual compromise is very close to the structure of the original Print Preview: have the generator and server in the same container and adjust the data server as necessary. The final solution is to have the containing control hold the rendering engine, the script generator and as many specific kinds of data server as needed for the project.
The container would receive the command string (IE, “FORM:Billing Invoice” or “FILE:c:\data\mydataform.dbf”), select the proper data server, set up the rendering engine and the script generator and then start the rendering process. After it is done, the container would then signal that it had either finished the rendering and where the results would be found or had failed and indicate the reason why.
At this point, the prototype overall container would not contain the code to make the Print Preview form work. That will still be handled by the FFForm control. I will have to create a new subclass of the control, and migrate all the relevant code from the current version of the Print Preview form’s FFForm to it (such a FormInit, right-click or double-click), and create new methods to handle the image zooming and panning, page switching, and doing the actual rendering.
My plans for the new Print Preview form are a bit ambitious, but that is for the next post.