Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Resources » Articles » Databases »
Forms and Object-Oriented Programming
|
Forms and Object-Oriented Programming
Microsoft Access was not designed to be a full object-oriented programming environment, yet it has many characteristics found in object-oriented application development systems. Before you dive into building forms, it's useful to examine how Access implements objects and actions, particularly if you come from the world of procedural application development.
In classic procedural application development, the data you need for the application is distinct from the programs you write to work with the data and from the results produced by your programs. Each program works with the data independently and generally has little structural connection with other programs in the system. For example, an order-entry program accepts input from a clerk and then writes the order to data files. Later, a billing program processes the orders and prints invoices. Another characteristic of procedural systems is that events must occur in a specific order and cannot be executed out of sequence. A procedural system has difficulty looking up supplier or price information while in the middle of processing an order.
In an object-oriented system, however, all objects are defined in terms of a subject and an action performed on that subject. Objects can contain other objects as subjects. When an object defines a new action on another object, it inherits the attributes and properties of the other object and expands on the object's definition. In Access, queries define actions on tables, and the queries then become new logical tables known as recordsets. You can base a query on another query with the same effect. Queries inherit the integrity and formatting rules defined for the tables. Forms further define actions on tables or queries, and the fields you include in forms initially inherit the underlying properties, such as formatting and validation rules, of the fields in the source tables or queries. You can define different formatting or more restrictive rules, but you cannot override the rules defined for the tables.
Within an Access database, you can interrelate application objects and data. For example, you can set startup properties or define an initial macro (called Autoexec) that prepares your application to run. As part of the application startup, you will usually open a switchboard form. The switchboard form might act on some of the data in the database, or it might offer controls that open other forms, print reports, or close the application.
Attached Figure 13-1 shows the conceptual architecture of an Access form. In addition to operating on tables or queries in a database, forms can contain other forms, called subforms. These subforms can, in turn, define actions on other tables, queries, or forms, and they can trigger additional macro actions or Visual Basic procedures. As you'll learn when you read about advanced form design, macro actions and Visual Basic procedures can be triggered in many ways. The most obvious way to trigger an action is by clicking a command button on a form. But you can also define macros or Visual Basic procedures that execute when an event occurs, such as clicking in a field, changing the data in a field, pressing a key, adding or deleting a row, or simply moving to a new row in the underlying table or query.
Attached Figure 13-1. The conceptual architecture of an Access form.
"Automating Your Application with Visual Basic" you'll learn how several of the more complex forms in the Microsoft Press Books and Entertainment Scheduling sample databases are automated with Visual Basic. Attached Attached Figure 13-2 shows a few of the automated processes for the frmContracts form in the Entertainment Scheduling database. For example, printing the contract currently displayed in the form is triggered by using a command button.
When you print the contract, a Visual Basic procedure marks the contract "Active." If the contract is issued by RM Productions (the first agent code is RMP), another Visual Basic procedure generates one payment record in the tblCommissions table for each week of the contract with the appropriate commission due. Clicking the Payments button opens a form for recording payments for the current contract. If you change the group name in the contract, other procedures copy the group member information. (This application copies the group member information because the group membership can change over time; each contract records the band members at the time the contract is issued.) When you change the start or end date of a contract, a Visual Basic procedure automatically calculates the contract's length, in weeks.
Object-oriented systems are not restricted to a specific sequence of events. So a user entering a contract in Access can minimize the contract form and start a search in a groups table for musical style or start a search in a clubs table without first having to finalize the contract. You could provide a simpler way for the user to do this in your application by means of a command button on the contract form.
Attached Figure 13-2. Some of the automated processes for the frmContracts form.
 Attachments
Figures Understanding (34540-3128-Forms-and-Object-Oriented-Programming-Figures.zip)
|
Responses
|
| Author: greeny_1984 03 Nov 2009 | Member Level: Diamond Points : 0 | Hi,
Good article..
Keep posting more..
regards,
greeny_1984
|
|