ch08.htm

好书《C++ Builder高级编程技术》

<P>When arranging tables on a data module, I usually follow some simple naming conventions.
If I attach a 
<TT>TTable</TT> object to a table called <TT>Customer</TT>, I will
call the <TT>TTable</TT> object <TT>CustomerTable</TT>. The data source attached
to that table will generally be called <TT>CustomerSource</TT>.

<DL>
	<DT></DT>
</DL>



<BLOCKQUOTE>
	
<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>An alternative technique, called
	Hungarian notation, would name all <TT>TTable</TT> objects <TT>tbl</TT>XXX, where
	the XXX is the name of the table you want to use: <TT>tblCustomer</TT>, 
<TT>tblBioLife</TT>,
	and so on. You could then prefix <TT>ds</TT> before the table name to designate the
	name of the data source: <TT>dsCustomer</TT>, <TT>dsBioLife</TT>, and so on. This
	was the technique I used in the past, but which I no longer 
believe to be best. <BR>
	<BR>
	The Hungarian system enables you to automatically group all the objects shown in
	the Object Inspector according to type. If all the tables begin with <TT>tbl</TT>,
	they will appear together in the Object Inspector. 
<BR>
	<BR>
	Despite this advantage, I have decided against Hungarian notation on the grounds
	that it tends to make even simple code appear a bit abstruse. Recondite code has
	a certain emotional appeal, but it is not the effect I want to strive for 
in a book
	that champions the virtues of clear, easy-to-read logic. <BR>
	<BR>
	In general, I try to avoid systems that force me to use hard to read abbreviations,
	or that clutter up the beginnings of words. In particular, I find an identifier like
	
<TT>dsCustomer</TT> unpleasant because it makes the type of the variable appear more
	important than the name of the variable. This system also makes it hard to read the
	identifier, because you have to mentally skip over the first syllable before 
getting
	to the key piece of information contained in the name. Of course, my least favorite
	naming convention abbreviates both the type and the variable name:</P>
	<PRE><FONT COLOR="#0066FF">DDSURFACEDESC       ddsd;

HBITMAP             hbm;


RGBQUAD *           prgb;</FONT></PRE>
	<P>Incredibly, these samples are taken from source code distributed by a major software
	company in order to promote a new API. I am at least tempted to believe that the
	people who came up with these variable 
names were trying to be funny, or perhaps
	just to pull someone's leg. At any rate, these are classic examples of naming conventions
	that I try to avoid. <BR>
	<BR>
	So, in this book, it will generally be <TT>CustomerTable</TT>, and not 
<TT>tblCustomer</TT>.
	If you prefer some other system, you should feel free to pursue your tastes. After
	all, many of the best programmers use Hungarian notation on a regular basis. In fact,
	in the world of C++, my tastes probably represent a 
minority opinion. 
<HR>


</BLOCKQUOTE>

<P>In simple projects that have only one data module, I will usually call the files
associated with the data module <TT>DMod1.cpp</TT> and <TT>DMod1.h</TT>. The <TT>TDataModule</TT>
object itself I usually 
rename to <TT>TDMod</TT>. In more complex projects that have
multiple data modules I might rename the data module to something more meaningful
such as <TT>TDModAddress</TT>, and I might then save the file under the name <TT>DModAddress1.cpp</TT>.</P>

<P>Please note that my convention is to name the file in which a data module or form
is stored as the same name as the data module or form, except that I append a <TT>1</TT>
to it. Thus the file in which a data module called <TT>TDMod</TT> is stored 
will
be called <TT>DMod1</TT>. This prevents name conflicts between the object name and
the filename. If I have a form called <TT>TAddress</TT>, I will save it in a file
called <TT>Address1.cpp</TT>. The one exception to the previous rule is that I 
tend
to name the main module of a project <TT>Main.cpp</TT>, and I then usually keep the
main form default name of <TT>Form1</TT>.</P>
<P>Please understand that I have included this section more as a courtesy than out
of a desire to attempt to force 
my tastes on someone else. I want you to know and
understand the conventions I use, but you should feel free to use the techniques
that you feel work best.</P>
<P>Enough on naming conventions. It's time now to move on to a related, but slightly

different matter regarding the proper use of data modules.
<H3><A NAME="Heading12"></A><FONT COLOR="#000077">Using the TQuery Object</FONT></H3>
<P>You can create a BCB SQL statement by using a <TT>TQuery</TT> component in the
following manner:

<DL>
	
<DD><B>1. </B>Drop down <TT>TQuery</TT>, <TT>TDataSource</TT>, and <TT>TDBGrid</TT>
	objects on a form and wire them together.<BR>
	<BR>
	<B>2.</B> Assign an alias to the <TT>DatabaseName</TT> property of the <TT>TQuery</TT>
	object. For instance, use 
the <TT>BCDEMOS</TT> or <TT>DBDEMOS</TT> alias. These aliases
	are created automatically by BCB and Delphi, respectively, during installation.<BR>
	<BR>
	<B>3.</B> Use the <TT>SQL</TT> property to enter a SQL statement such as <TT>Select
	* from 
Country</TT>.<BR>
	<BR>
	<B>4.</B> Set the <TT>Active</TT> property to <TT>True</TT>. If you completed each
	step correctly, and if the BDE is set up correctly, the grid should now contain the
	records from the <TT>Country</TT> table.
</DL>

<P>If 
you're working with local data, you can substitute a fully qualified subdirectory
path for an alias. When using the latter method, it's best if you don't include the
actual name of a table, but only the subdirectory in which one or more tables exist.

In my opinion, however, it is almost always better to work with an alias rather than
specify the path directly in the <TT>DatabaseName</TT> property.</P>
<P>That's all I'm going to say about <TT>TQuery</TT> for now. Later in this chapter
I discuss the 
SQL monitor tool that comes with BCB. In subsequent chapters I begin
using SQL statements more heavily. I find it easier to use <TT>TTable</TT> than <TT>TQuery</TT>
for many basic database operations. However, as I discuss matters of increasing 
complexity
throughout the database section of this book, I will rely more and more on SQL.
<H4><A NAME="Heading13"></A><FONT COLOR="#000077">The Data Module</FONT></H4>
<P>Earlier in this chapter, you placed a <TT>TTable</TT> and <TT>TDataSource</TT>

component on the same form with your visual components. When you ran the program,
the icons representing these components disappeared. However, they are visible at
design time and have a tendency to clutter up the form. Partially out of a desire
to 
eliminate this clutter, BCB features a component called a <TT>TDataModule</TT>,
which can be used to store nonvisual controls such as <TT>TTable</TT> and <TT>TDataSource</TT>.
A program on disk called <TT>SimpleTable</TT> shows how to use the 
<TT>TDataModule</TT>
component.</P>
<P>To get started working with <TT>TDataModules</TT>, first begin a new application.
Next, choose File | New and select the Data Module component from the New page of
the New Items dialog, as shown in Figure 8.5. 
You can also choose to create a data
module directly from the New Data Module option on the File menu. You should, however,
get used to using the Object Repository as it plays a big role in BCB programming.<BR>
<BR>
<A NAME="Heading14"></A><A 
HREF="08ebu05.jpg" tppabs="http://pbs.mcp.com/ebooks/0672310228/art/08/08ebu05.jpg">FIGURE 8.5.</A><FONT COLOR="#000077">
</FONT><I>Selecting the <TT>TDataModule</TT> component from the New Items dialog.</I>

<DL>
	<DT></DT>
</DL>



<BLOCKQUOTE>
	<P><BR>
	
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> 
</B>A <TT>TDataModule</TT> is not the
	same thing as a form. For instance, if you look in its ancestry you will see that
	it is a direct descendant of <TT>TComponent</TT>. When you first see a <TT>TDataModule</TT>
	object, there is a tendency to view 
it as merely a special kind of form, which is,
	to some degree, true, at least in a very nontechnical sense. However, the hierarchy
	for a <TT>TForm</TT> component looks like this:</P>
	<PRE><FONT COLOR="#0066FF">-TComponent

  -TControl

    
-TWinControl

      -TScrollingWinControl

        -TForm</FONT></PRE>
	<P>The hierarchy for a <TT>TDataModule</TT>, on the other hand, looks like this:</P>
	<PRE><FONT COLOR="#0066FF">-TComponent

  -TDataModule</FONT></PRE>
	<P>Clearly, 
<TT>TForms</TT> and <TT>TDataModules</TT> are two very different beasts,
	despite some apparent similarities between them. <BR>
	<BR>
	The header file that contains the declaration for the <TT>TDataModule</TT> class
	is <TT>FORMS.HPP</TT>. If you have 
the Pascal source to the VCL, the <TT>TDataModule</TT>
	object is found in <TT>FORMS.PAS</TT>. 
<HR>


</BLOCKQUOTE>

<P>After adding a <TT>TDataModule</TT> object to your application, take a moment
to save your code. You might save <TT>Unit1</TT> as 
<TT>MAIN.CPP</TT> and <TT>Unit2</TT>
as <TT>DMOD1.CPP</TT>. Click <TT>Form1</TT>, open the File menu, and choose the Include
Unit Header expert from the menu. In the Include Unit dialog, select <TT>DMod1</TT>
and press OK. This is a simple way of 
automatically inserting an <TT>#include</TT>
directive at the top of <TT>Unit1</TT>. In particular, the following changes are
made to your code:</P>
<PRE><FONT COLOR="#0066FF">#include &lt;vcl\vcl.h&gt;

#pragma hdrstop

#include &quot;Main.h&quot;


#include &quot;DMod1.h&quot; // This directive references the data module

#pragma resource &quot;*.dfm&quot;

</FONT></PRE>
<P>You can, of course, type in the <TT>#include</TT> directive without using the
small expert found on the File menu. There is 
no particular advantage in using the
expert other than its ease of use. Remember, however, that if you want to include
a unit in your project, it is generally not enough to simply add a header file to
a unit. You must also be sure the unit has been 
explicitly added to your project.
In the case discussed here, there is no need to explicitly add <TT>Unit2</TT> (a.k.a.
<TT>DMod1</TT>) to the project, because it was done automatically when you first
created the unit.

<DL>
	<DT></DT>
</DL>




<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>This is a time when some programmers
	may need to force themselves to abandon the old &quot;command-line&quot; attitude,
	and to instead embrace a visual tool that can help make 
you more productive. As always,
	the choice is yours, but if the visual tools are easier to use, and if they make
	you more productive, you should consider using them. Command-line programming has
	an honorable place in this world, but it is generally 
not part of the attitude that
	makes for good RAD programmers. <BR>
	<BR>
	Let me tack on one additional piece of information to this note. If you want to add
	a module to a project without using the project manager, and without editing a makefile,
	
you can use the following syntax:</P>
	<PRE><FONT COLOR="#0066FF">#pragma link &quot;dmod1.obj&quot;</FONT></PRE>
	<P>This syntax can be very useful when adding components to the component palette.
	See the <TT>FTP2.cpp</TT> module in the 
<TT>Utils</TT> directory from the CD-ROM
	that ships with this book for an example of using this approach. 
<HR>


</BLOCKQUOTE>

<P>Arrange <TT>Form1</TT> and <TT>DataModule2</TT> on the screen so you can view
them both at the same time. Drop a 
<TT>TTable</TT> and <TT>TDataSource</TT> component
on the data module, as shown in Figure 8.6.<BR>
<BR>
<A NAME="Heading17"></A><A HREF="08ebu06.jpg" tppabs="http://pbs.mcp.com/ebooks/0672310228/art/08/08ebu06.jpg">FIGURE 8.6.</A><FONT COLOR="#000077">
</FONT><TT><I>Form1</I></TT><I> and <TT>DataModule2</TT> 
arranged on the screen so
that you can easily view them both at the same time.</I>

<DL>
	<DT></DT>
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>For various reasons I snapped my
	screen shots for this book at 
640x480 resolution. Needless to say, I don't usually
	run BCB at that resolution. 1024x768 is probably a more reasonable size when working
	with an environment like this, though even higher resolutions would be better. 800x600