Chapter 7: Classes, Constructors, Overloading, and Help

Public, Private, and Unspecified Classes

The designator public at the start of a class declaration in a form (window) means that the object (for example, a variable or function) may be accessed by other forms if communication between the form that originally declares the object and the form that needs to use the object has been established (as shown in Chapter 5).

The designator private at the start of a class declaration in a form means that the object may be used only within the form where the object is declared. An object that is undeclared in the class list ( neither public nor private) defaults to a private class.

The programmer never sees the bulk of the machine code or intermediate code form, and if it is printed out the result means nothing to a human being. This was true in the old days, and it remains true today. By the late 1970s most compiler manufacturers placed these necessary machine code support files at the disposal of the programmer by including their filenames in the *.h declarations files. For example, all the machine code that supported creating, reading, or writing to files was placed in one huge machine code *.h file with a name like FileSupport. By including the FileSupport file in a *.h file listing that supported one particular form, all the FileSupport machine code was placed at the disposal of the compiler at compile time. The compiler extracted all the machine code required to support that form and released the rest. The *.h files were the keepers of all class declarations.

But there was another wide use of include files: If Form1 in the project needed access to variables that were declared in Form2, the programmer could make the Form2 variables available to Form1 simply by including Form2 s *.h file in the Form1 include list. This concept worked because the *.h files contained all the information on classes and kept a list of where each variable was located in memory. So the exchange of *.h declaration files between forms in a project was a convenient method for giving all forms access to all variables in the project (if the programmer wanted this to happen). However, this widespread practice was a total disregard of the principles of object-oriented programming (OOP), and some compiler architects called for an end to this proliferation of *.h declaration files.

Microsoft Visual C# shut down the easy data exchanges between forms by demanding that their compilers conform to all the OOP standards, namely, that if Form2 needed access to a variable or procedure in Form1, then Form1 had to create a handle to itself (a key to unlock the path between Form1 and Form2), hand the key to Form2, and now Form2 could access the variables and procedures in Form1. This is the way Visual C# conducts business. This method of data exchange was demonstrated in Chapter 5.

The Visual C# compiler shows you two views of a window s construct: a code display (source code) and a window template display. The older compilers showed you three displays: a code display, a *.h declarations file display, and a window template display. In Visual C# the *.h declarations have been moved to the *.Designer.cs file. The definitions for all controls on a window template are split ” part of the code appears in the source file *.cs and part appears in the *.Designer.cs file, which is a file closed to the programmer (only the IDE writes to this file, except under unusual circumstances).

In the Visual C# world the machine code files are no longer included; they are brought to the compilation with the using statements at the top of the source code file.

Previous page

Table of content

Next page

---

Unlocking Microsoft C# V 2.0 Programming Secrets (Wordware Applications Library)

ISBN: 1556220979
EAN: 2147483647

Year: 2005
Pages: 129

Authors: Richard Braden

BUY ON AMAZON