Important Ugly Details
"God and the Devil are hidden in the details."

In writing code for artificial worlds, as in analyzing any complex real world process, you must continually change your level of attention from global generalizations to local details, allowing your mind to move freely up and down through the levels of abstraction. "God and the Devil are hidden in the details."

Borland's C++ Builder Rapid Application Development (RAD) platform gives you the full functionality of both the C++ programming language and the Windows Application Programmers Interface (API). It does so by encapsulating most of the Windows API code in drag-and-drop components. With the complexities of Windows out of the way, we can focus on the objects and processes of our model without having to worry about the Windows API. In this class we will only make use of a small part of C++ and Borland C++ Builder. We will ignore 95% of what Borland C++ Builder offers.

Nevertheless, we must pay close attention to the details in the 5% that we do use. Here are some important details that you must not forget:

• PROJECT FOLDERS
• PORTABILITY
• WHERE TO START YOUR CODE
• EVENT-HANDLERS
• CODING AESTHETICS
• LANGUAGE
• ARRAYS

Borland opens with a blank application on the screen. Before you do anything else, select FILE | SAVE PROJECT AS, navigate to the WORKSPACE on your computer, create a new folder for your project, OPEN that new folder, and press SAVE as many times as it pops up. For any given project, always FILE / SAVE ALL to that same folder.

To save progressive versions of your project, SAVE ALL and then CLOSE ALL. Manually go outside of the Borland IDE and create a new project folder. Manually copy the old project folder's contents into the new project folder. Then return to the Borland IDE and FILE | OPEN PROJECT to the new folder.

In the computer lab: DO NOT accept the SAVE PROJECT AS default value. You cannot write to the default folder and if you attempt to do so you may be faced with unrecoverable errors! BACKUP copies of all your work! Copy your WORKSPACE project folders onto your ZIP disk at the end of every session! The WORKSPACE is wiped clean every few weeks.

PORTABILITY:

If you want your program to run on any PC you must reset these options. Otherwise it will only run on machines on which "Run Time Library" (helper) files have been installed. "Build with runtime packages" should not always be unchecked.

If you want your program to run on any PC you must reset these options. Otherwise it will only run on machines on which "helper" files are installed. Resetting the following options will insure that all the files you will ever need are included in the application.

In the computer lab: Double check these at the start of every session.

.....

Click "OK"

Check "Default" and click "OK" ONLY if you are running your own private copy of Borland C++ Builder.
DO NOT check "Default" if you are running from the computer lab (it will trigger an error).

.....

Begin entering your code after the last statement:

Let the Borland IDE manage the creation and destruction of all event-handlers. When an event-handler is created properly (through the Borland IDE) many references to it are also created and stored in files other than Unit1.cpp. When an event-handler is destroyed properly (through the Borland IDE) all references to it in other files are also destroyed.

To CREATE an event-handler:
Use the "Object Inspector" or double click on the object. DO NOT TRY TO WRITE OR PASTE-IN THE CODE YOURSELF. In the illustration above Button1 has been placed on Form1 and has been double-clicked to create the highlighted event handler. The event handler will stay in your code as long as it is NOT empty. In this instance I have put the placeholder // my stuff inside to prevent Borland from destroying it.

To DELETE an event-handler:
Simply delete the contents of the handler(the // my stuff statement). When you link and compile the program (press the green run button) Borland will then delete the event-handler and all references to it. However, you may delete the button yourself. DO NOT delete the event-handler yourself - if you do you will get this error message:

There are two ways TO RECOVER FROM THIS ERROR:

1. Type or paste-in the even-handler to restore it as it was before you deleted it. To get the syntax right you will probably need to create another event-handler Button2Click and copy it in detail making sure to change its referent (in this instance changing Button1Click to Button2Click). Make sure that each event-handler is empty (it should be if you haven't filled it in). When you link and compile the program again, both event-handlers will disappear along with all the references to them. Then delete the buttons by highlighting each and pressing delete.
2. Click the tab to change the editor from Unit1.cpp to Unit1.h. Then very carefully delete the line of code referring to the partially deleted event handler.

Even though the compiler doesn't care what your code looks like, you should. Clearly formatted code is much easier to read and understand. It is customary to indent blocks of code to visually indicate its nested structure. By default, the IDE tab stops setting may be too high. Set the indentation to a more reasonable value. Go to TOOLS | EDITOR OPTIONS and change "Tab Stops" to 3:

When programming in C++ pay special attention to the details of case, spelling, syntax and punctuation.

These are the three most common causes of programming errors:

• Parentheses (), Braces {}, Brackets [] and Angles <> are confused or out of place. Each is different and must always be used in pairs.
• Comas (,), Dots (.), Colons (:) and Semicolons (;) are confused or out of place. Each has a different meaning.
• Upper and lower case letters have been mixed. caseSensitive, CaseSensitive, casesensitive and CASESENSITIVE are all different.

C++ allows you to write programs that will overwrite the memory used by other programs or the Windows operating system. C++ assumes that you know what you are doing. Windows may catch these errors, but it may not. Experiment, but experiment with some degree of caution. Here is one common error that will often crash your application:

Suppose you need a list of 100 elements. You can declare an array of 100 integers as follows:

To select any element in that list, you simply specify its index number. Intuitively, you might think that the indices should range from 1 to 100. Counterintuitively they range from array[0] to array[99]. DO NOT FORGET THIS CONVENTION. C++ will let you read elements outside this range in memory, but these may be parts of other programs. Similarly, C++ will let you write elements outside this range in memory, but these may overwrite other programs and data. Strange things might happen.

If we declare the array above, the following assignment statements will write data to memory that does not belong to that array. While it may be obvious that the array does not have a declared element at position 227, it may not be obvious that the 100th element is really stored at the index position 99, not 100. The 100th element is referred to as array[99].

It is easy to overlook this fact when assigning values to elements of an array within a loop. The loop in the first example below stops with the assignment array[99] = 9801 which is within bounds and thus correct. The loop in the second example below stops with the assignment statement array[100] = 10000 which is outside the bounds of the array and incorrect.

for (int i = 0; i < 100; i++) {
xxx array[ i ] = i * i;
}

for (int i = 0; i <= 100; i++) {
xxx array[ i ] = i * i;
}

The help menu gives you access to a bookshelf full of information. Explore what it has to offer.