FormMaker Overview FormMaker Overview
FormMaker is a tool for extracting information from a database in a highly structured manner. Reporting styles can vary from simple columnar output to extravagant form letters and sales invoices. Some reports extract and/or manipulate data from a single database, while other reports may require several databases and complex formulae to generate information in the desired manner.
The accounting system provides many reports where the user can set the limits, however, not every report conceivable can be included in a single software package. The FormMaker option allows the user to create custom reports based on the information stored in the accounting system database files. FormMaker is an extremely powerful tool, comparable in features to software costing hundreds of dollars. Practically any type of report that is required can be created with this simple, yet highly effective tool.
What are some features of FormMaker?
FormMaker can produce a variety of different reports. Reports as simple as a list of numbers to reports involving complex calculations and extensive formatting can all be produced with FormMaker. Here is a short list of features available to the user:
Accessing/Saving Report(s)
•A tree-styled FormMaker screen, much like Windows Explorer, will help the user arrange reports by classifying and grouping them by type and using several folders to store report files.
•An unlimited number of reports can be created and managed.
•Quickly create reports that are similar to an existing report by opening a file, then saving the report to a new file name.
•Windows95 styled long filenames can be used when saving reports.
Data Creation/Manipulation
•Simultaneous processing of several data tables joined in an integrated structure is available to the user.
•Effective and high speed filters and sorting for records using any available fields from applications database file(s), including expressions and functions of the FormMaker's native programming language can be used to organize reports.
•Complex expressions can be easily built with the help of the built in Data Dictionary. The Dictionary contains all the field names, functions, operators, built-in variables and user defined total variables/calculated fields which are allowed for use in an expression. The Dictionary also shares a tree-style hierarchical structure.
•Supports end-user creation of total variables of type Sum, Counter, Average, Minimum, Maximum, Evaluate. Total variables can be reset on the end of appropriate sorting group as well as on the end of each page. These variables can be set up to be evaluated at the start of report, at the each record, at the end of a sorted group, at the end of page, at the end of report.
•Supports end-user creation of Calculated fields. They are very similar to Total Variables but always use the Evaluate type and never need to be reset. Very complicated computations can be made using any number of Total variables and Calculated fields.
•Calculated variables can be set up to evaluate on the start of report as well. By means of dialog window functions provided by the application developer, it is possible to ask an end-user for run-time entered values or browse selection. The value being entered/selected will be accepted to the Calculated Variable. Such variables usually are used in defining filter expressions.
•The report Dictionary can be used to select an individual element from array type data fields (up to 4 dimensions).
•Print the current date and time on a page. The Picture can change the format of a date or time field to any desired format. For example, 02/21/00 can be changed to read "21 February, 2000" at report runtime.
•Wizard style dialog easily helps build a Picture of any type (Numeric, Date, Time, Pattern, etc.).
•Frame contents may be formatted in accordance with a Picture. The Picture can help to change the format of text strings easily. For example, if the social security number is stored in the database as only numbers (123456789) it can be reformatted at runtime to print "properly" (123-45-6789).
•The application developer can create computed fields indistinguishable from the fields from the actual database table.
User Interface
•The Report Formatter uses a word processing-styled interface, with buttons commonly found for formatting text (right align, left align, center align, etc)
•The following report sections (bands) are available: Page header, Report header, Group break, Group header, Detail, Group footer, Report footer, and Page footer. Each band can contain an unlimited number of Frames to represent information.
•Frame contents may be a text string(s), or a formula. This is similar to Microsoft Excel usage: if the frame contents begins with the equal sign "=" then it means the rest is the formula to evaluate. In that way only one variable can be referenced as well as the expression containing as many variables and functions desired.
•Use borders around the Frames to make them standout. For example, a border can be placed around dollar totals at the bottom of reports. Frames with borders can be used and joined Frames side-by-side to get grid-style reports. Frame borders may have varying thickness and color. Also the whole frame can be filled with a selected color.
•The user may select a font typeface, size, style and color for the whole report or report section as well as for individual frame. Use different fonts and font types to make key data stand apart from other data.
•The user can select multiple Frames at the same time for repositioning or alignment operations.
•Frame contents are placed and aligned both vertically and horizontally.
•The current page number as well as the total number of pages can be printed on each page header/footer.
•The number of database records printed on the current page can be printed (useful for page footer information).
•The application developer can change the language from "English", "Russian" or any other interface language. The FRB_NLS.INI file is provided for translation of all the messages and prompts that the FormMaker uses to interact with end-users.
•The application developer can provide additional functions to be used in report runtime evaluated expressions.
•There is the ability to export report pages in WMF format to Microsoft Word for Print Preview, Edit, Save as *.doc format file, Printing purposes, etc.
•The user can add graphics that are stored on the hard-drive to a report. This is a GREAT feature commonly used for office letterhead, computer-generated invoices, etc.
•Support for Inch as well as for Metric coordinate system is available.
•Ability to customize default properties of a new Frame is also available.
•It is possible to set the percent values both for Horizontal and/or Vertical scaling of a whole report page being generated. Default percent value = 100%, effective increment/decrement step = 5%. X and Y percent values are stored in the user's WIN.INI file for each installed printer separately. This unique FormMaker capability allows end users to adjust the actual size of report controls/whole report page on a hard copy for an any specific printer, such as Laser, Matrix and so on.
•The Trailing Text feature is helpful for a MEMO field printing. The Trailing Text option is selectable as a property of a report section (band). Text will be printed line-by-line beneath the band with page overflow control. This feature can handle a text of unlimited length.
Understanding what a database is
As simple to use as this FormMaker is (really!), there are some database fundamentals that should be understood in order to get the most out of this powerful tool. It is one thing to blindly type information into a computer, but learning how a database program really works will greatly enhance the reports created.
A database is nothing more than a collection of information that is somehow related. A common phone book is a wonderful example of a database. A basic definition of a phone book would be a collection of names/addresses/phone number(s) for people and businesses in one physical area (usually a city, or a common area code number). So, a database would be all the names, addresses and phone numbers contained in a phone book.
A database file is comprised of two new terms: database records and database fields. Going back to the phone book once again, each person's name listed in the phone book would be a database record. It contains all the information for one person or business (their name, address, phone number(s), etc). The next name shown in the phone book would be a separate database record, and so on.
A database record is made up of database fields. Using the phone book again as an example, there would be separate database fields for the following information:
Individuals/business name
Street address
Phone number
A database can have only one field, or can have hundreds of fields - whatever it takes to store all the information required for one database record entry.
A phone book is usually sorted on the name of the individual/business, beginning with the number 0, and ending with the letter Z. This type of sort is known as ASCENDING sequence. Going from the letter Z to the number 0 is called DESCENDING sequence. Sorting a database requires the creation of a second type of file known as a database index, which can also be called a database key.
A database index is a file used by a database application to change the appearance of information stored by the database. In the phone book example - every day the phone company creates phone numbers as people and businesses move into the city. Their name(s) are obviously not going to be in alphabetical order when the clerk creates their new phone number - a person named Jones may be first, then Joe-Bob's Barbecue is next, then Alpha-Beta Drugs may be third, and so on. Without a way of sorting this information, a printed phone directory would be a total mess - names would jump around the alphabet! The index file's job is to regain some structure and order to the information being input into the database.
A database index file can be created using one database field, or several database fields. These file(s) are normally opened when the database is opened, and as each database record is added/deleted, an identical action is performed on the index file. For the phonebook example, the desired sort would be the individual/business name to be sorted in ascending alphabetical sequence. The field name used for the index would be the individual/business name. If the phone company were really customer-oriented they could perhaps create section(s) in their phone book that were sorted on the street address - a new index created on that database field would be created/used to print this new section of the phone book.
Index file(s) are most commonly used in browse screens (a screen where all the database records are displayed in columns, sorted alphabetically for easy location of information) and reports.
Index file(s) are also used to relate two or more database files together, which store different pieces of information that belong together. This type of database application is known as a relational database - two or more database file(s) relate to each other by means of a common database field, and an index file that links the two separate files together.
An example of a relational database could be a bank account. When first joining a bank, form with name, address, work history, etc must be filled out. The clerk puts this information into the computer. All this "initial" information is stored in a database. As checks are written to pay for things, a transaction is created for the date it was written, the dollar amount, the date the transaction was posted to the account, the check number, etc. These transactions are stored in a separate database file.
At this point we have one database that stores customer information (name, address, etc) and another database that stores transactions for each check cashed. In both database files is a field that contains the account number, and an index file is created for each database on this field. The two database files are related to each other by these index files created on the account number.
Not all database applications require a relational setup - if the information being tracked is simple, then a single database file will contain all the data being monitored. However, all business type database systems rely on the relational database structure in order to keep track of a large quantity of information. Relational databases greatly reduce the amount of information being kept in database files, which keeps the size of the database file(s) small and increases the speed of the program in retrieving data.
This FormMaker can create reports from single database programs or relational database programs.
This help file breaks down database filters into smaller pieces to help the user understand what a filter is, and how to create increasingly complex filters. It is recommended that the user at least glance over each topic.
Filters 101 Part 1 - What is a database filter?
Filters 101 Part 2 - What are the components of a database filter?
Filters 101 Part 3 - Simple filters to get started
Filters 101 Part 4 - Stopping common filter problems before they start
Filters 101 Part 5 - Combining multiple conditions into one filter