Home Accounting is an application to help manage your personal cash registers and provides a simple means of budgeting your income and expenses.
The Help window is the manual.
In HA all register functions occur in a single window. Setting application preferences occurs in another window. All budgeting information is contained in two other windows ( annual and monthly ).
This article is an update to a previous article of mine covering my Home Accounting application ( version a1p1 ) that appeared in the April 1994 Visual News ( issue #8 ). Home Accounting ( referred to as HA ) has undergone four rewrites since then.
Alpha 1 Releases:
The a1 release moved HA from it's prototype development phase into it's application development phase. The primary changes were the inclusion of a file converter, preliminary print engine, the Core Suite of Apple Events, a registration system, a color grid system for the register window and a font color menu. Improvements were made in every other component of HA.
Alpha 2 Releases:
The a2 release converted HA from a window centric application to a view centric application. This means that view classes were used to break up the code into smaller and more manageable pieces. This also reduced the size of the window sections ( which reduced the chances of corruption ). The primary changes were the inclusion of a preliminary reconcile function, a palette management system ( to manage color resources ), window and view manager classes to isolate HA's window an view classes from the ABCs. The register window and help system were significantly expanded.
Alpha 3 Releases:
The a3 release was a major rewrite that took eight months to complete. Up to this version the data managed by HA was contained in persistants and managed by each method that referenced the data. As requests for new features rolled in, maintaining the data and code became a nightmare. A single change in the structure of any data item ended up requiring most of the code to be rewritten. This design is reflective of a procedural type language. A procedural type language generally couples the interface ( user interaction ) and model ( data interaction ) layers together which intern creates the previously described problem.
The largest change in the a3 version was the separation of the interface and model layers. The model layer is composed mostly of the data base engine. The data base engine manages many data bases in HA. I created an application, Home Video Library, to efficiently create and test the data base engine. The data base engine was then imported into HA.
The next largest change was in making HA handle multiple open data bases. This required a complete rewrite of the window management, security, preference, error management and document management systems. The HA's application class had to be rewritten to handle multiple documents differently than the ABCs.
The Menu system was rewritten and is managed mostly by HA's application class. The window classes only manage those functions specific to them ( which are few ). HA's application class enables and disables menu items based on context.
The following highlights several additions of the a3 release; Documents Manager class ( allows the user to close a data base or select the active data base ), Date and Time management system, Window Info Manager class ( manages a data base's window information ), Address book ( creditor data base ), Memory Monitor floating window ( watches memory consumption ), a bug reporting/status system, application preferences and data base preferences are now separate, application password and the data base encryption passwords are now separate. The class structure of the source code was relayed out into functional sections.
Alpha 4 Releases:
The alpha 4 version is the final conversion step in converting Home Accounting from a procedural type application to an OO ( object oriented ) type application. The current version of the data base engine is designed around a record number rather than entry position. The primary changes were the inclusion of a window item flasher system, a multiple column scroll list class, a functional help button to windows that have multiple function views, a tutorial (SimpleText format), query windows now allow button selection from the keyboard by their first character, all Core Suite Apple Events are now implemented. There are now three versions of HA available; 68k, PPC and FAT binaries. The heap resource has been adjusted for all four memory models. Mac Toolbox code has been moved to universal sections for the Windows port. Many functions have been moved to stand alone sections and are packaged as extension sets. There is now a Dynamic Multiple View Editor.
In addition to converting Home Accounting to an OO ( object oriented ) type application, I have been attempting to implement more system 7 features; balloon help, Apple guide, scriptability, unlimited undo, drag and drop and much more.
Home Accounting has grow to the point that it is now classified as a large CPX application. This is the primary reason for the new layout in the sections ( Figure 1 ) and the class structures.
I recommend the following when creating a new application:
Subclass the following ABC classes; Desktop, Application, View and Window. Use these subclasses to overshadow the ABC methods of interest. Each of the subclasses should be in their own section.
Use a standard naming convention for your application's sections. I have six applications that use this naming convention:
!HA Home Accounting
!CC Concentration ][
!BD Bishop's Draw
!WE Wizard's End
!HVL Home Video Library
!WS Word Search
Separate general purpose code into functional sections ( Figure 2 ) such as the following examples:
Dynamic Multiple View ( Multiple View replacement )
Allows dynamic monitoring of free memory
Separates Pen and Fill patterns plus adds graphic classes
Separate Mac specific code ( Figure 3 ), use universal methods, such as the following examples:
!!TB Color Picker
Color Picker references
!!TB File Manager
File Manager references
The use of the ! and !! pushes these section names to the top in the section list which also reduces the Check Memory time. Sections beginning with !!, I call extension sets and are stored in an extension sets folder in CPX's ABC Sections folder ( the ABE Sections folder has a similar setup ). When I create a new application I add the needed sections to it from the extensions folder.
Use interpreter only sections to isolate code that is not to be compiled.
The Data Base Engine Core:
The basic component of the data base engine is the Data Record class ( Figure 4 ). This class is composed of one attribute, Record Number.
If more than one record is needed, then a manager class is used to manage the records. To allow multiple data bases, a Record Manager class is made a subclass of the data record class. This class adds four attributes:
The Data Base attribute stores instances of the records of a data base.
The Next Record Number keeps track of the record number to assign to the next record added to the data base.
The Encrypt? attribute is set TRUE if the data base records are a subclass of the secured record class.
If the Auto Add? attribute is set TRUE, then the Insert Record and Update Record methods of the Record Manager class will add the data record to a managers data base automatically if the data record does not already exist in the data base, otherwise the method fails.
Most methods of the base classes are overshadowed in the security system in order to extract the requested information from an encrypted record. The base methods are:
Encrypt Record? - Called to check to see if a new data record is to be encrypted.
Extract Data - Extracts the values of all instance attributes.
Extract Record - Calls /Extract Data. Overshadowed in many subclasses to provide root comments (another level of documentation).
Get Attributes - Extracts both class and instance attributes.
Get Class - Returns the type of data record ( class name ).
Get Entry - A part of the debug system. If the attribute exists for the given data record, then returns it's value.
Get Record Value - Returns the value of the given attribute ( no validity tests are made ).
Make Encrypted Record - Creates an encrypted record ( overshadowed in a subclass if real encryption is to be performed ). If the data record is not to be encrypted, then returns an instance of an encrypted record ( this provides access to the encrypted record class that handles encryption/decryption ).
Set Entries - A part of the debug system. Sets multiple attributes of a data record to the given values. Calls the /Valid Attribute? method to verify the attributes and new values. If no attributes are provided, then all attributes are to be set. Used by the file system to converted file data back into data records.
Set Entry - A part of the debug system. Calls the /Valid Attribute? method with all attributes ( class and instance ) to verify the attribute and new value.
Valid Attribute? - If the attribute exists for the given data record and the new data type matches the current data type, then passes. Otherwise, fails. NULL values bypass the value tests.
Universal methods ( Figure 5 ) are added to make accessing the various managers more efficient.
The Secured Data Base Engine Core:
The basic component of the secured data base engine is the Secured Record class ( Figure 6 ). This class is an abstract class and only provides a base for secured records.
Basic process of adding a record to a secured data base:
Call Record Manager/Add Record.
Adds a unique record number by calling Record Manager/Make Record Number.
If the Encrypt? flag is TRUE, then calls Data Record/Encrypt Record?.
This method calls Data Record/Make Encrypted Record.
This method calls Encrypted Record/Encrypt Record.
This method stores the record number and class of the given data record, then calls Encrypted Record/Encrypt Data method.
This method calls Encrypted Record/Do Encryption, then stores the encrypted data. The default do encryption method extracts the values of the data base record and converts that list to a string. This allows easier testing of the encryption system, but it should not be used as the encryption system for an application.
The HA Encrypted Record methods, Do Encryption and Decrypt Data are the only restrictions in Home Accounting. At present they do no more than what is needed to allow the encryption system to be tested. In the future they will call external methods to perform all security functions for Home Accounting.
Home Accounting's Data Base Manager class modifies the above as describe below:
Data Base Manager/Add Record calls super Add Record, then updates the Cash Accounts and Budget Accounts data bases.
Data Record/Encrypt Record? is overshadowed by HA Secured Record/Encrypt Record?. Checks for the encryption level set to 2.
Calls HA Data Record/Make Encrypted Record. This method supplies an instance of HA Encrypted Record.
In the future the method Encrypted Record/Do Encryption will be overshadowed by HA Encrypted Record/Do Encryption.
The many levels of method calls allows an application many ways to hook into the encryption/decryption process. At present Home Accounting hooks in at several points ( file system and preference system to name two ) to manage application security.
The Document System:
The document system is the link between the data base engine and the file system.
The Application Class:
The application class is the link between the document system and the operating system.
The Window Manager:
The window manager is the link between the data base engine and user interface.
The View Manager:
The view manager class is the base view class for all other view classes and is used to isolate HA's view classes from the ABCs view system.
The Data Entry System:
The Preference System:
The Data and Time System:
This article was to appear in the Visual News Issue #23 and is not complete and is several years behind the current release of Home Accounting.
Last updated: Mar 4, 2011