What Are Objects?

Chapter 18 - The Object-Oriented Primer
Mastering Crystal Reports 9
by Cate McCoy and Gord Maric
Sybex 2003

Objects are reusable and shareable programs. Objects are frequently described in abstract terms as entities that have methods, properties, and behaviors. These abstract concepts are difficult to grasp when learning to use objects and dealing with object-oriented programming. Often these abstract concepts are confusing to beginners learning OOP.

Objects contain code and data, the same stuff we use in every formula or program we have ever written. We are going to look at objects through their code and data. We will start with a simple stand-alone program and move to the evolution of objects. Once you understand the mechanics of objects, we can then look at them from a more abstract point of view and define some of the confusing OO terminology.

Note 

Entire books have been written about object-oriented programming. The purpose of this chapter is to give you as much information as you need, as quickly as possible, so you can gain the necessary understanding of OOP concepts and then return to the task of using Crystal Reports. We have kept the examples and details as simple so you can concentrate on concepts and not get bogged down in details.

Note 

All or most of Crystal Reports is written in C++, an OOP language. The developers often create their own documentation. If you understand their lingo, you can understand what they are trying to say.

A Stand-alone Program

When the first computer programs were written, whether on punch cards or old green 3270 monitors or formulas in Crystal Reports, the programs stood alone. They usually read some data, processed the data, saved the data, and maybe printed a report about the data. Listing 18.1 is an example of a simple stand-alone program that adds interest to money borrowed.

Listing 18.1: Stand-alone Program

Dim BorrowAmount As Number Dim InterestRate As Number Dim InterestAmount As Number Dim Total As Number BorrowAmount = {Customers.BorrowAmount} InterestRate = {Rates.Interest} InterestAmount = BorrowAmount * (InterestRate /100 ) Total = BorrowAmount + InterestAmount Formula = Total 

Note 

The above program is written in Crystal Basic syntax so that you would be familiar with the syntax. However, this program can be written in any language and compiled to run on the computer. This sample is not meant to be compiled; it is simply meant for illustration purposes.

The program reads the amount borrowed from the Customers table and the interest rate from the Rates table. It stores that information in two variables, BorrowAmount and InterestRate. It then calculates the interest amount and stores it in the InterestAmount variable, and finally it adds the original borrowed amount and calculated interest amount to calculate the total amount. The total amount is the result of the formula.

Listing 18.1 can also be broken down conceptually into two categories:

Data Variables and data used in the program:

Dim BorrowAmount As Number Dim InterestRate As Number Dim InterestAmount As Number Dim Total As Number

Code (logic) Work that the program does using the data:

BorrowAmount = {Customers.BorrowAmount} InterestRate = {Rates.Interest} InterestAmount = BorrowAmount * (InterestRate /100 ) Total = BorrowAmount + InterestAmount

This is a stand-alone program because it does not depend on any other program to do its work. Everything it needs, the data and code, is self-contained.

Note 

We’ve kept the program very simple to illustrate the concepts. In reality, the data and logic sections could be very large and contain thousands of lines of code.

Running the Program

Before this program can be run, it must be compiled to instructions that the computer will understand. The program shown in Listing 18.1 is called source code, and both a programmer and the compiler can understand it. A compiler is a computer program that takes the code and compiles it to machine instructions that a computer can understand. The output from the compiler is an executable program, a file with an .exe extension. Figure 18.1 illustrates this concept.

Figure 18.1. Compiling the program

From a reusability point of view, this program is not very flexible. The code section cannot be shared with another program. For example, if another program needed to calculate interest, then that program would need to contain the same logic again. This is an expensive proposition, especially if the logic is complicated because the same logic would need to be rewritten in that program. It also leads to support problems because you must support the same logic in multiple places. If you were to find a bug in one place, you would have to fix it in many places.

Libraries

To get around this problem, computer scientists came up with the concept of libraries. Libraries contain sections of code that can be reused in multiple programs. Figure 18.2 illustrates this concept.

Figure 18.2. Reusing program code

We can rewrite the original loan program to include code from a library and use the same library in a different program. Listing 18.2 shows the interest calculation library.

Listing 18.3 is the same program as Listing 18.1 except that the logic in the program is copied from an external library.

Listing 18.4 uses the same logic as used in Listing 18.3. It is reusing the Listing 18.2 logic. Notice also that Listing 18.4 adds 3% to the total after the total is calculated, showing that a program can use existing logic and add logic as required. This demonstrates how two programs can do different things but share the same core logic. This approach is much more flexible than the Listing 18.1 approach.

Listing 18.2: Interest Calculation Library

BorrowAmount = {Customers.BorrowAmount} InterestRate = {Rates.Interest} InterestAmount = BorrowAmount * (InterestRate /100 ) Total = BorrowAmount + InterestAmount

Listing 18.3: Interest Program One

Dim BorrowAmount As Number Dim InterestRate As Number Dim InterestAmount As Number Dim Total As Number <<Include Listing 18.2 Interest Calculation Library>> Formula = Total 

Listing 18.4: Interest Program Two

Dim BorrowAmount As Number Dim InterestRate As Number Dim InterestAmount As Number Dim Total As Number <<Include Listing 18.2 Interest Calculation Library>> Total = Total * 1.03 Formula = Total 

Note 

We are using Crystal Basic syntax for clarity. However, Crystal does not support including logic as described above. The purpose of this code is simply to illustrate a concept. This type of code is called pseudo code. We are using the pseudo code to illustrate code techniques that are used.

Running the Program

Just as with the stand-alone program, before we can run this program we must compile it. The compiler copies the library of code and uses it in the compilation. Figure 18.3 illustrates this point. Because the compiler copies the code and compiles it, this is called static linking. If the library changes, the program will not change until the program is recompiled.

Figure 18.3. Compiling the program

From a reusability point of view, the samples in Listings 18.3 and 18.4 are much more flexible. If a bug is discovered in the library code in Listing 18.2, all you have to do is fix the bug in the library code, and the other two programs will reflect the changes when they are recompiled.

This leads to another problem: If the library code is changed, the changes are not reflected automatically in Program One and Two, Listings 18.3 and 18.4, until those programs are recompiled.

Note 

Older mainframe computer systems use code libraries extensively. Before the arrival of Y2K (year 2000), programmers needed to find date bugs in libraries and programs and recompile the executable. However, some of the programs were so old that the original source code was lost, making compilation very difficult.

Compiled Libraries

To get around the limitation of having to compile all the programs that use the same library, computer scientists created dynamic linked libraries (DLL). A DLL is a library that is precompiled and can be used by compiled programs; it does not need to be compiled with your program. Therefore, if the DLL changes, the program will automatically pick up the changes without you having to recompile the original program. Figure 18.4 illustrates this concept.

Figure 18.4. Using a DLL

To update the loan program from Listings 18.2 and 18.3 to use a DLL, the first thing we must do is take our library source code and compile it with a DLL compiler, as shown in Figure 18.5. This is the same process as illustrated in Figure 18.1. However, the output file has a .dll extension instead of an .exe extension. DLL files cannot run by themselves; they must be called and run in another program.

Figure 18.5. Compiling the program

Listings 18.5 and 18.6 show the programs updated to use the DLL file.

Listing 18.5: Interest Program One

Dim BorrowAmount As Number Dim InterestRate As Number Dim InterestAmount As Number Dim Total As Number <<Include InterestCalc.DLL>> Formula = Total 

Listing 18.6: Interest Program Two

Dim BorrowAmount As Number Dim InterestRate As Number Dim InterestAmount As Number Dim Total As Number <<Include InterestCalc.DLL>> Total = Total * 1.03 Formula = Total 

If we find a bug in the DLL, all we have to do is recompile the DLL, and the programs will automatically pick up the changes.

Note 

Again, we are using Crystal Basic syntax for clarity. The syntax is for illustration purposes only.

At this point, you can see the evolution of computer programming architectures and how code can be reused in a computer system. The concept of OOP is based on being able to reuse code. Before we can jump into OOP, we need to look a little deeper into what makes up a DLL.

In Listing 18.2, which shows the library code that we compiled into a DLL, we imply that a DLL contains one block of code that is reused in the program. This is possible; however, in reality a DLL contains many blocks of code, and the programmer using the DLL decides what code to call in the DLL.

Functions and Subroutines

A DLL includes sections of code called subroutines or functions. Subroutines and functions are blocks of code that are executed when called by the calling program. The only difference between a subroutine and a function is that a function returns a value to the program that called the function. This sounds more complicated than it really is. Let’s take a look at an example of subroutines and functions in a stand-alone program; then we will move them to a DLL to see the difference.

To demonstrate this example we need to make our loan program a little more robust. We are going to add a function to our program that calculates interest on borrowed money and a subroutine that prints the calculated amount. Listing 18.7 contains the sample program.

Note 

Subroutines and functions are created with languages such as Visual Basic or C++. These languages are used to create the inner workings of DLLs; they are also used to create the inner workings of Crystal Reports. If you understand conceptually what is happening under the hood, then using the functionality available to you in Crystal Reports is easier.

Note 

The following code examples are created in pseudo code to demonstrate concepts. The concepts can be applied in VB or C++.

Listing 18.7: Stand-alone Example Subroutines and Functions

Dim Total As Number Dim BorrowAmount As Number BorrowAmount = {Customers.BorrowAmount} Total = BorrowAmount + CalcInterestAmount(BorrowAmount) Call PrintTotal End program Function CalcInterestAmount(LoanAmount)    Dim InterestRate As Number    Dim InterestAmount As Number           InterestRate = {Rates.Interest}    CalcInterestAmount = LoanAmount * (InterestRate /100 ) End Sub Sub PrintTotal    Dim prTotal As String         prTotal = "$" + Total    Print prTotal End Sub

The program in Listing 18.7 can be broken down into three sections: the main loan program, a function, and a subroutine.

Loan Program

The main part of the program is the first six lines of code. It creates two variables, Total and BorrowAmount, reads the Customers.BorrowAmount from the database, and stores that amount in the BorrowAmount variable. Then it adds interest to the BorrowAmount and stores that value in the Total variable.

Notice how interest is calculated by calling the CalcInterestAmount function. The program passes to the function the BorrowAmount in the brackets, and the CalcInterestAmount Function reads that value to calculate the interest amount:

Total = BorrowAmount + CalcInterestAmount(BorrowAmount)

The program then prints the total amount by calling the PrintTotal subroutine: Notice the subroutine does not return any value it just runs the code in the subroutine.

Call PrintTotal 

Function

The purpose of this function is to receive the amount of money borrowed and send back to the caller the interest on that amount of money. It receives the amount borrowed through the LoanAmount variable declared in the brackets beside the name of the function, CalcInterestAmount. It then reads the interest rate from Rates.Interest in the database and stores that amount in the InterestRate variable:

Function CalcInterestAmount(LoanAmount)

The next line calculates the interest amount by multiplying the amount of money borrowed by the interest rate. In the same line it sets the return value of the function by equating the name of the function to a value. This says that the entire function is equal to this value and this value can be used by the calling program:

 CalcInterestAmount = LoanAmount * (InterestRate /100 )

Note 

Some programming languages specify the return value of the function by using the keyword return, such as return = LoanAmount * (InterestRate /100 ).

Subroutine

The PrintTotal subroutine reads the total amount of money borrowed, appends a dollar sign to the amount, and prints the amount borrowed with a dollar sign. The subroutine does not return any values; it just runs code.

This coding style is an example of structured coding. The program is broken down into logical sections that make the code easier to debug and maintain. All the logical sections are contained in the same program. This program is also stand-alone.

As we showed previously, we can provide reusability of the function CalcInterest and subroutine PrintTotal to other programs by moving the subroutine and function code to a separate DLL file. Listing 18.8 demonstrates creating the DLL, and Listing 18.9 demonstrates using methods and functions in the DLL.

Listing 18.8: Creating a DLL

Function CalcInterestAmount(LoanAmount)    Dim InterestRate As Number    Dim InterestAmount As Number            InterestRate = {Rates.Interest}    CalcInterestAmount = LoanAmount * (InterestRate /100 ) End Sub Sub PrintTotal    Dim PrTotal As String        PrTotal = "$" + Total    Print PrTotal End Sub

This program has the same function and subroutine as the stand-alone program in Listing 18.7. The program will be compiled to a DLL and the DLL will be called CalcInterest.dll, as shown previously in Figure 18.5.

The bolded lines of code indicate the changes we made to the original loan program. In Listing 18.9 we create a variable named IntCalc, which will represent our DLL. We set the IntCalc variable equal to CalcInterest.dll, and we call the function and subroutine as we did before, but this time we prefix the name with the variable that represents the DLL.

Another program could make a reference to the same DLL and use it as this program does. Because the DLL is compiled, if a bug is found and fixed, when the DLL is recompiled, any program that uses it will automatically get the changes.

Listing 18.9: Using Methods and Functions in a DLL

Dim Total As Number Dim BorrowAmount As Number Dim IntCalc BorrowAmount = {Customers.BorrowAmount} IntCalc = "CalcInterest.dll" Total = BorrowAmount + IntCalc.CalcInterestAmount(BorrowAmount) Call IntCalc.PrintTotal End Program 

Architecture Review

Let’s stop for a moment to review what we have done. Listing 18.1 is the stand-alone program. It has all the logic and data necessary for the program to run. In Listing 18.6 we moved our logic from the program to a separate file called a DLL. The program in Listing 18.9 contains the data, the program variables, and the DLL. Listing 18.8 contains the logic. The DLL contains more than just a block of code; it actually contains a section of code divided into subroutines and sections. The program that is using the DLL can call the section of code that it requires.

Application Programming Interface (API)

This architecture is an example of an Application Programming Interface (API). DLLs are created to provide reusable code, and many programs use the same DLL. Crystal Reports uses this type of API to provide functionality to the report writer. Crystal Reports also contains an object-oriented API.

Note 

As you can see, this architecture is very powerful but it can lead to problems. A program depends on a DLL for its code, or logic. If the DLL is upgraded from version 1 to version 2, and the programmer who created version 2 removes or changes some of the functionality that was in version 1, then all programs that expect the functionality of the version 1 DLL will fail when the version 2 DLL is installed in the computer. This is exactly why sometimes when you install a program on your Windows computer, suddenly other programs break. The newly installed program updates some shared DLL that was not written to be backward compatible, and the old programs break. This is also affectionately known as “DLL Hell.”

Objects

At this point in our design we have separated the logic in a DLL using subroutines and functions. Programs that call the DLL contain the variables and any necessary code to use the code in the DLL. Objects are reusable and shareable programs. An object combines data and code, and a program can use both the data and the code.

Note 

Objects are compiled into a DLL file. This is the same extension we saw when discussing subroutines and functions. Even though the file extension is the same, the functionality is different. Objects can also be compiled into an .exe extension. Functionally, they are the same, but memory in the computer is used differently.

To create an object, we add data to the DLL. Because an object contains both data and code, it has everything a stand-alone program has. However, objects don’t run by themselves; they are called by other programs like DLLs, as we discussed previously. We now have the power to be able to reuse code in the DLL, as well as access the data within the object.

Terminology Change

Because an object contains data and code like a stand-alone program does, OOP designers felt that it was necessary to use different terminology to identify data and code, hence they came up with the following terms:

• Methods (code) are subroutines or functions in an object. These are the same subroutines and functions as in a DLL. Subroutines run code, but functions run code and return a value.

• Properties (data) are variables declared in an object. These variables can be used by the object or the calling program.

An Abstract Point of View of Objects

So far we have examined objects from a coding point of view, observing how programming has evolved from subroutines and functions into objects. However, OO people look at objects from a more abstract point of view. They view an object as something that represents entities in the real world, like employees, bank accounts, or reports. They describe the entities as containing methods and properties.

• Methods represent actions that the object or entity can do. Methods are sometimes called verbs.

• Properties represent characteristics of the object. Properties are sometimes referred to as adjectives, describing the object.

This view of objects has merit because it forces the person to think of what the object can do from a “real-world” point of view. This makes it easier to design objects to represent actual work entities such as a report or a customer without getting bogged down in the mechanics of what code will need to be written in the object. After the higher level design is done, the methods and properties still turn into subroutine, functions, and variables. We can design objects better if we focus on what they are, not on how they do things.

OO people often start talking about objects from this abstract point of view of methods and properties without tying objects back to the code and data that a programmer is familiar with. This might be okay for a computer analyst, but for a programmer who has to use someone else’s objects, it is important to understand how everything ties together.

Knowing both points of view of an object—the code point of view and the abstract point of view—you will be able to understand the high-level discussion of methods and properties and also understand what is happening under the hood.

It does not matter whether you prefer to understand objects from a code or abstract point of view. The most important thing is to know what they are and what their capabilities are. Let’s expand our program that calculates the interest for borrowed money to give it more functionality and to make it object oriented.

OO Point of View

A business analyst identifies the following characteristics of a customer who has a loan and what they do.

Properties:

• Customer’s name

• Borrowed amount

• Balance

  Methods:

  • Make payment

Code Point of View

The programmer translates the characteristics of the object into code, as shown in Listing 18.10.

Note 

These examples of OOP are not meant to be an exhaustive list of techniques. Their purpose is to identify concepts that you need to understand to be able to use objects in Crystal Reports. The coding examples loosely follow Visual Basic 6 code, which is similar to Crystal Basic code.

Listing 18.10: LoanCustomer Object

Public CustName Public BorrowAmount Public Balance Public Sub MakePayment(PayAmount)    'Lookup customers balance in DB    BorrowAmount = {Customers.Balance}        Balance = Balance - PayAmount + CalcInterestAmount(BorrowAmount)        'Update the database with new balance    {Customers.balance} = Balance End Sub Private Function CalcInterestAmount(LoanAmount)    Dim InterestRate As Number    Dim InterestAmount As Number        InterestRate = {Rates.Interest}    CalcInterestAmount = LoanAmount * (InterestRate /100 ) End Sub Public Sub PrintTotal    Dim PrTotal As String        PrTotal = "$" + Balance    Print PpTotal End Sub

The loan object has these properties and methods:

Properties:

• CustName contains the names of the customers.

• BorrowAmount contains amount of money borrowed.

• Balance contains the balance of the loan.

  Methods:

  • MakePayment accepts as input the loan payment amount and updates the database.

  • CalcInterest calculates the interest on the loan and accepts as input the balance.

  • PrintTotal prints the balance of the loan.

An object can contain public and private methods or properties. Public methods and properties can be called by an outside program. Private methods can be called only by the object itself. This allows the designer of the object to expose only the necessary functionality. When working with Crystal Report objects, you will have access to the public methods and properties.

Listing 18.11 demonstrates using the loan object.

Listing 18.11: Using the Loan Object

Dim CustOne As New LoanCustomer Dim CustTwo As New LoanCustomer CustOne.CustName = "Gord" CustTwo.CustName = "Nancy" CustOne.MakePayment (500) CustTwo.MakePayment (300) 

In this program we create two variables that will each hold one loan object for CustOne and CustTwo. The program will create two copies of the LoanCustomer object, one for each customer.

Note 

We can also say we have two instances of the loan object.

We update the CustName property for both objects to the customer’s name so that each object is identified uniquely.

Then we make payments for 500 and 300 by calling the MakePayment method and passing to that method the payment amount. The MakePayment method calls the private function CalcInterestAmount to calculate the interest and updates the Balance property for the loan.

Finally we call the PrintTotal method for each customer to print the balance of the loan.

Notice the simplicity of Listing 18.11. The complex code is hidden in the object, shown in Listing 18.10. We create the object and use its methods and properties. The complex work of looking up the database and calculating loan payments is done in the object.

Note 

Let’s tie this abstract discussion back to Crystal Reports. An example of an object in Crystal Reports would be the report object. It represents a report and would contain methods to save and export the report and properties to indicate paper size and page orientation. In your program it would create an instance of the report object and manipulate its methods and properties. We will be doing that in the following chapters.

Collections

As you have seen, objects can represent entities and help hide complex code to make our application easier to write. Computer scientists have added another OOP concept to help design objects to better reflect real-life examples. The concept is a collection of objects. A collection is an object that contains a reference to other objects.

If you are familiar with the concept of arrays, through either Crystal formula language or another language, the concept is very similar. A collection usually contains similar objects. The collection object contains the following properties and methods. Notice that the collection is an object, a program that does something.

Properties:

• Count tells how many items are in the collection.

• Item is the actual object inside the collection.

Methods:

• Add is used to add items to the collection.

• Remove is used to remove items from the collection.This is best explained with an example. Let’s continue with our loan discussion.How many loans can a customer have? Answer: one or more loans. In the previous LoanCustomer object, shown in Listing 18.11, the object is limited to one loan per customer. If a customer has multiple loans, we will have to create a LoanCustomer object to represent each loan, and the customer’s name will be the same for each loan. (Have you ever gone to a bank to change your address and they had to do it in several places?) We can better design loan and customer objects so we have one customer object that can have a multiple loan objects.

Customer Object - OO Point of View

A business analyst identifies the following characteristics of a customer:

Properties:

• Customer name

• Loans

Methods:

• Make payment

• Take out a loan

• Loan balance

Loan Object - OO Point of View

A business analyst identifies the following characteristic of a loan:

Properties:

• Borrow amount

Code Point of View

The programmer translates the characteristics of the objects into code, as shown in Listings 18.12, 18.13, and 18.14.

Note 

These examples of OOP are not meant to be an exhaustive list of techniques. Their purpose is to identify concepts that are necessary to be able to use objects in Crystal Reports. The coding examples loosely follow Visual Basic 6 code.

Lines of code that begin with an apostrophe are comments. Refer to the comments for a description.

Listing 18.12: Customer Object

Public CustName As String 'Loans represent the entire set of loans Public Loans As Collection 'ALoan represents one loan in from the set Private ALoan As Loan Private LoanID As Number 'The method accepts a payment amount and the loan number to apply it to Public Sub MakePayment(PayAmount, LoanNumber)    'An individual loan in a collection can be referred to by its index number,in our case the loan number         ALoan = Loans(LoanNumber)    'Read the amount borrowed for this particular loan    BorrowAmount = ALoan.BorrowAmount    ALoan(LoanNumber).Balance = BorrowAmount - PayAmount + CalcInterestAmount(BorrowAmount)    'Update the database with new balance    {Customers.Balance} = Balance, LoanNumber End Sub Private Function CalcInterestAmount(LoanAmount, LoanNumber)    Dim InterestRate As Number    Dim InterestAmount As Number    InterestRate = {Rates.Interest}    CalcInterestAmount = LoanAmount * (InterestRate /100 ) End Sub Public Function NewLoan(BorrowAmount)    'Increment the loan ID key so we can keep track of loans     LoanID = LoanID + 1        'Add a new loan to the collection of loans    Loans.AddItem Loan, LoanID      'Set how much was borrowed    Loans("LoadID").BorrowAmount = BorrowAmount    NewLoan = LoanID End Sub Public Function LoansBalance()    Dim TotalBalance As Currency    Dim x As Integer     'Loop through all the loans in the loan collection    'the count property of the loans object tells you how ' many loans there are For x = 1 to Loans.Count        TotalBalance = TotalBalance + Loans(x).Balance Next x        'Set the return value    LoansBalance = TotalBalance End Function

Listing 18.13: Loan Object

'The loan object contains only data about the loan 'All the code is done in the customer object Public LoanNumber As Number Public BorrowAmount As Currency Private Balance As Currency

Listing 18.14: Using the Loan and Customer Objects

 'Create a new customer Dim CustOne As New LoanCustomer 'Create an object to represent a loan Dim ALoan As Loan 'Variable to keep track of a loan Dim LoanNumber As Number 'Assign the customer name to the name property in the object  CustOne.Name = "John" 'Create a new loan for $500. The method will return the loan number so we can     refer to it later  LoanNumber = CustOne.NewLoan ("500") 'Make a $300 dollar payment to the new loan CustOne.MakePayment(300,LoanNumber) 'Find out how much money I owe in all my loans.  'The loan's balance method does all the hard work and it 'returns the total of all the loans Print "Total Money owed is " & CustOne.LoansBalance

As you can see, most of the code is done inside the objects. The application that creates and uses the object has little code. Don’t get bogged down on what the code in the objects is doing. The point of this exercise is to show that methods and properties call code and work with data inside an object. When working with the Crystal Reports objects, you will never see the inner workings of the object as we have shown here. We are showing you this so you can have an appreciation of what is happening behind the scenes. This will deepen your knowledge of the Crystal object model.

Events

So far we have shown that a program can create an object and use its methods and properties; the communication has always been from the program that created the object to the object. The object can communicate back to the program using events. An event is a way for the object to notify the program that something has occurred.

To continue with our loan example, when a customer makes a loan payment and the balance reaches zero, the object can notify the program that is using this object that this is the last payment. We will modify the MakePayment method in the customer object to cause an event to be raised if the balance reaches zero or less than zero. Listing 18.15 contains the modified method in bold. The remaining code is the same as in Listing 18.12 and is not displayed in Listing 18.15.

Listing 18.15: Customer Object

Public Sub MakePayment(PayAmount, LoanNumber)    'An individual loan in a collection can be referred to by its index number,     in our case the loan number        ALoan = Loans(LoanNumber)    'Read the amount borrowed for this particular loan    BorrowAmount = ALoan.BorrowAmount    ALoan(LoanNumber).Balance = BorrowAmount - PayAmount +     CalcInterestAmount(BorrowAmount, LoanNumber)    'If the balance reaches zero or less than zero    'notify the program and pass back the loan number that    'is paid off    If Balance < = 0 Then       RaiseEvent BalancePaid(LoanNumber)    End If    'Update the database with new balance    {Customers.Balance} = Balance, LoanNumber End Sub

A program that uses objects that can raise events must create an event subroutine that gets called by the object. The object will run the code in event subroutine. Listing 18.16 contains the modified method in bold. The remaining code is the same as in Listing 18.13 and is not displayed in Listing 18.16.

Listing 18.16: Responding to an Event

'Make a $300 payment to the new loan CustOne.MakePayment(300,loanNumber) 'This subroutine will get called by the object if the loan 'balance is zero or less. Public Sub BalancePaid(LoanNumber) Print "Congratulations your loan number " $ LoanNumber & "is paid off" End Sub

The customer object calls the BalancePaid event if the loan balance is less than zero. In Listing 18.16 the Sub BalancePaid is called by the customer object.

The Loan Object Model

We can continue expanding the customer and loan examples until we have a full-fledged banking system. At this point we would have hundreds of objects representing the various components of a banking system. The number of objects and the relationships among them would be difficult to understand. To help clarify the objects and their relationships, OO designers create an object model to model all the objects and their relationships. The OO object model is similar to a relational database model that was discussed in Chapter 9, “Working with Multiple Tables,” in Part 3: “Advanced Reporting.” Figure 18.6 represents our customer and loan object model.

Figure 18.6. Loan object model

The main object in our model is the customer object and it contains a Loans Collection, which is a container that holds the loan objects for the customer.

Crystal Reports and Objects

We have seen objects from a theoretical point of view. The discussions about methods, properties, events, and collections apply to objects within Crystal Reports. Crystal Reports contains hundreds of objects that represent the functionality of the report writer, and their relationships can be complex. The concepts we discussed in our simple banking application are the same that Crystal has in the Crystal Reports object model. Figure 18.7 contains a partial snapshot of the object model.

Figure 18.7. The Crystal Report object model

The entire object model and reference to the object’s methods and properties can be found in C:\Program Files\Crystal Decisions\Crystal Reports 9\Developer Files\Help\Crystal-DevHelp.chm. Figure 18.8 shows a partial list of the report object’s methods, properties, and events.

Figure 18.8. Methods, properties, and events in a Crystal object

We will look at these objects and their use in detail in the following chapters.

Use of content on this site is expressly subject to the restrictions set forth in the Membership Agreement

Conello © 2000-2003     Feedback