the idea=20
      of several hundred K of MFC framework getting added to your =
programs, WTL=20
      is for you. However, there are a few barriers we have to =
overcome:</P>
      <UL>
        <LI>ATL-style templates look weird at first.=20
        <LI>No ClassWizard support, so writing message maps involves =
some manual=20
        labor.=20
        <LI>No documentation in MSDN, you need to find it somewhere =
else, or=20
        even look at the WTL source.=20
        <LI>No reference books you can buy and keep on your shelf.=20
        <LI>It has that "not officially supported by Microsoft" stigma=20
        <LI>ATL/WTL windowing is sufficiently different from MFC =
windowing that=20
        not all your knowledge transfers over. </LI></UL>
      <P>On the other hand, the benefits of WTL are:</P>
      <UL>
        <LI>No complex doc/view framework to learn or work around.=20
        <LI>Has some essential UI features from MFC, like DDX/DDV and =
"update=20
        command UI" functionality.=20
        <LI>Actually improves on some MFC features (e.g., more flexible =
splitter=20
        windows)=20
        <LI>Much smaller executables compared to a statically-linked MFC =
app.=20
        <LI>You can apply bug fixes to WTL yourself and not affect =
existing apps=20
        (compare this with replacing the MFC/CRT DLLs to fix a bug in =
one app,=20
        and having other apps break)=20
        <LI>If you still need MFC, MFC and ATL/WTL windows can co-exist=20
        peacefully (for a prototype at work, I ended up creating an MFC=20
        <CODE>CFrameWnd</CODE> that contained a WTL=20
        <CODE>CSplitterWindow</CODE>, which contained MFC =
<CODE>CDialog</CODE>s=20
        -- that wasn't me showing off, it was modifying existing MFC =
code but=20
        using the nicer WTL splitter). </LI></UL>
      <P>In this series, I will first introduce the ATL windowing =
classes. WTL=20
      is, after all, a set of add-on classes to ATL, so a good =
understanding of=20
      ATL windowing is essential. Once I've covered that, I'll introduce =
WTL=20
      features and show how they make GUI programming a lot easier.</P>
      <H2><A name=3Dintopart1></A>Introduction to Part I</H2>
      <P>WTL rocks. But before we get to why, we need to cover ATL =
first. WTL is=20
      a set of add-on classes to ATL, and if you've been strictly an MFC =

      programmer in the past, you may never have encountered the ATL GUI =

      classes. So please bear with me if I don't get to WTL right off =
the bat;=20
      the detour into ATL is necessary.</P>
      <P>In this first part, I will give a little background on ATL, =
cover some=20
      essential points you need to know before writing ATL code, quickly =
explain=20
      those funky ATL templates, and cover the basic ATL windowing =
classes.</P>
      <H2><A name=3Datlbackground></A>ATL Background</H2>
      <H3><A name=3Datlhistory></A>ATL and WTL history</H3>
      <P>The Active Template Library... kind of an odd name, isn't it?=20
      Old-timers might remember that it was originally the =
Active<B>X</B>=20
      Template Library, which is a more accurate name, since ATL's goal =
is to=20
      make writing COM objects and ActiveX controls easier. (ATL was =
also=20
      developed during the time that Microsoft was naming new products=20
      ActiveX-something, just as new products nowadays are called=20
      something.NET.) Since ATL is really about writing COM objects, it =
only has=20
      the most basic of GUI classes, the equivalent of MFC's =
<CODE>CWnd</CODE>=20
      and <CODE>CDialog</CODE>. Fortunately, the GUI classes are =
flexible enough=20
      to allow for something like WTL to be built on top of them.</P>
      <P>WTL is currently in its second revision. The first was version =
3.1, and=20
      the second is version 7. (The version numbers were chosen to match =
the ATL=20
      version numbers, that's why they're not 1 and 2.) Version 3.1 =
works with=20
      VC 6 and VC 7, although you need to define a couple of =
preprocessor=20
      symbols for VC 7. WTL version 7 is a drop-in replacement for =
version 3.1,=20
      and works without modification on VC 7, so there really is no =
reason to=20
      use 3.1 for new development.</P>
      <H3><A name=3Datltemplates></A>ATL-style templates</H3>
      <P>Even if you can read C++ templates without getting a headache, =
there is=20
      two things ATL does that might trip you up at first. Take this =
class for=20
      example:</P><PRE><SPAN class=3Dcpp-keyword>class</SPAN> CMyWnd : =
<SPAN class=3Dcpp-keyword>public</SPAN> CWindowImpl&lt;CMyWnd&gt;
{
...
};</PRE>
      <P>That actually is legal, because the C++ spec says that =
immediately=20
      after the <CODE><SPAN class=3Dcpp-keyword>class</SPAN> =
CMyWnd</CODE> part,=20
      the name <CODE>CMyWnd</CODE> is defined and can be used in the =
inheritance=20
      list. The reason for having the class name as a template parameter =
is so=20
      ATL can do the second tricky thing, compile-time virtual function=20
      calls.</P>
      <P>To see this in action, look at this set of =
classes:</P><PRE><SPAN class=3Dcpp-keyword>template</SPAN> &lt;<SPAN =
class=3Dcpp-keyword>class</SPAN> T&gt;
<SPAN class=3Dcpp-keyword>class</SPAN> B1
{
<SPAN class=3Dcpp-keyword>public</SPAN>:=20
    <SPAN class=3Dcpp-keyword>void</SPAN> SayHi()=20
    {
    <FONT color=3Dred>T* pT =3D <SPAN =
class=3Dcpp-keyword>static_cast</SPAN>&lt;T*&gt;(<SPAN =
class=3Dcpp-keyword>this</SPAN>);</FONT>   <SPAN class=3Dcpp-comment>// =
HUH?? I'll explain this below</SPAN>
=20
        pT-&gt;PrintClassName();
    }
<SPAN class=3Dcpp-keyword>protected</SPAN>:
    <SPAN class=3Dcpp-keyword>void</SPAN> PrintClassName() { cout =
&lt;&lt; <SPAN class=3Dcpp-string>"This is B1"</SPAN>; }
};
=20
<SPAN class=3Dcpp-keyword>class</SPAN> D1 : <SPAN =
class=3Dcpp-keyword>public</SPAN> B1&lt;D1&gt;
{
    <SPAN class=3Dcpp-comment>// No overridden functions at all</SPAN>
};
=20
<SPAN class=3Dcpp-keyword>class</SPAN> D2 : <SPAN =
class=3Dcpp-keyword>public</SPAN> B1&lt;D2&gt;
{
<SPAN class=3Dcpp-keyword>protected</SPAN>:
    <SPAN class=3Dcpp-keyword>void</SPAN> PrintClassName() { cout =
&lt;&lt; <SPAN class=3Dcpp-string>"This is D2"</SPAN>; }
};
=20
main()
{
D1 d1;
D2 d2;
=20
    d1.SayHi();    <SPAN class=3Dcpp-comment>// prints "This is =
B1"</SPAN>
    d2.SayHi();    <SPAN class=3Dcpp-comment>// prints "This is =
D2"</SPAN>
}</PRE>
      <P>The <CODE><SPAN =
class=3Dcpp-keyword>static_cast</SPAN>&lt;T*&gt;(<SPAN=20
      class=3Dcpp-keyword>this</SPAN>)</CODE> is the trick here. It =
casts=20
      <CODE><SPAN class=3Dcpp-keyword>this</SPAN></CODE>, which is of =
type=20
      <CODE>B1*</CODE>, to either <CODE>D1*</CODE> or <CODE>D2*</CODE> =
depending=20
      on which specialization is being invoked. Because template code is =

      generated at compile-time, this cast is guaranteed to be safe, as =
long as=20
      the inheritance list is written correctly. (If you =
wrote</P><PRE><SPAN class=3Dcpp-keyword>class</SPAN> D3 : <SPAN =
class=3Dcpp-keyword>public</SPAN> B1&lt;D2&gt;</PRE>
      <P>you'd be in trouble.) It's safe because the <CODE><SPAN=20
      class=3Dcpp-keyword>this</SPAN></CODE> object can <I>only</I> be =
of type=20
      <CODE>D1*</CODE> or <CODE>D2*</CODE> (as appropriate), and nothing =
else.=20
      Notice that this is almost exactly like normal C++ polymorphism, =
except=20
      that the <CODE>SayHi()</CODE> method isn't virtual.</P>
      <P>To explain how this works, let's look at each call to=20
      <CODE>SayHi()</CODE>. In the first call, the specialization=20
      <CODE>B1&lt;D1&gt;</CODE> is being used, so the =
<CODE>SayHi()</CODE> code=20
      expands to:</P><PRE><SPAN class=3Dcpp-keyword>void</SPAN> =
B1&lt;D1&gt;::SayHi()
{
D1* pT =3D <SPAN class=3Dcpp-keyword>static_cast</SPAN>&lt;D1*&gt;(<SPAN =
class=3Dcpp-keyword>this</SPAN>);
=20
    pT-&gt;PrintClassName();
}</PRE>
      <P>Since <CODE>D1</CODE> does not override =
<CODE>PrintClassName()</CODE>,=20
      <CODE>D1</CODE>'s base classes are searched. <CODE>B1</CODE> has a =

      <CODE>PrintClassName()</CODE> method, so that is the one =
called.</P>
      <P>Now, take the second call to <CODE>SayHi()</CODE>. This time, =
it's=20
      using the specialization <CODE>B1&lt;D2&gt;</CODE>, and=20
      <CODE>SayHi()</CODE> expands to:</P><PRE><SPAN =
class=3Dcpp-keyword>void</SPAN> B1&lt;D2&gt;::SayHi()
{
D2* pT =3D <SPAN class=3Dcpp-keyword>static_cast</SPAN>&lt;D2*&gt;(<SPAN =
class=3Dcpp-keyword>this</SPAN>);
=20
    pT-&gt;PrintClassName();
}</PRE>
      <P>This time, <CODE>D2</CODE> <I>does</I> contain a=20
      <CODE>PrintClassName()</CODE> method, so that is the one that gets =

      called.</P>
      <P>The benefits of this technique are:</P>
      <UL>
        <LI>It doesn't require using pointers to objects.=20
        <LI>It saves memory because there is no need for vtbls.=20
        <LI>It's impossible to call a virtual function through a null =
pointer at=20
        runtime because of an uninitialized vtbl.=20
        <LI>All function calls are resolved at compile time, so they can =
be=20
        optimized. </LI></UL>
      <P>While the saving of a vtbl doesn't seem significant in this =
example (it=20
      would only be 4 bytes), think of the case where there are 15 base =
classes,=20
      some of those containing 20 methods, and the savings adds up.</P>
      <H2><A name=3Datlwindowing></A>ATL Windowing Classes</H2>
      <P>OK, enough background! Time to dive into ATL. ATL is designed =
with a=20
      strict interface/implementation division, and that's evident in =
the=20
      windowing classes. This is similar to COM, where interface =
definitions are=20
      completely separate from an implementation (or possibly several=20
      implementations).</P>
      <P>ATL has one class that defines the "interface" for a window, =
that is,=20
      what can be done with a window. This class is called =
<CODE>CWindow</CODE>.=20
      It is nothing more than a wrapper around an <CODE>HWND</CODE>, and =
it=20
      provides almost all of the User APIs that take an =
<CODE>HWND</CODE> as the=20
      first parameter, such as <CODE>SetWindowText()</CODE> and=20
      <CODE>DestroyWindow()</CODE>. <CODE>CWindow</CODE> has a public =
member=20
      <CODE>m_hWnd</CODE> that you can access if you need the raw=20
      <CODE>HWND</CODE>. <CODE>CWindow</CODE> also has a <CODE><SPAN=20
      class=3Dcpp-keyword>operator</SPAN> HWND</CODE> method, so you can =
pass a=20
      <CODE>CWindow</CODE> object to a function that takes an =
<CODE>HWND</CODE>.=20
      There is no equivalent to <CODE>CWnd::GetSafeHwnd()</CODE>.</P>
      <P><CODE>CWindow</CODE> is very different from MFC's =
<CODE>CWnd</CODE>.=20
      <CODE>CWindow</CODE> objects are inexpensive to create, since =
there is=20
      only one data member, and there is no equivalent to the object =
maps that=20
      MFC keeps internally to map <CODE>HWND</CODE>s to =
<CODE>CWnd</CODE>=20
      objects. Also unlike <CODE>CWnd</CODE>, when a =
<CODE>CWindow</CODE> object=20
      goes out of scope, <I>the associated window is not destroyed</I>. =
This=20
      means you don't have to remember to detach any temp =
<CODE>CWindow</CODE>=20
      objects you might create.</P>
      <P>The ATL class that has the implementation of a window is=20
      <CODE>CWindowImpl</CODE>. <CODE>CWindowImpl</CODE> contains the =
code for=20
      such things as window class registration, window subclassing, =
message=20
      maps, and a basic <CODE>WindowProc()</CODE>. Again, this is unlike =
MFC=20
      where everything is in one class, <CODE>CWnd</CODE>.</P>
      <P>There are also two separate classes that contain the =
implementation of=20
      a dialog box, <CODE>CDialogImpl</CODE> and =
<CODE>CAxDialogImpl</CODE>.=20
      <CODE>CDialogImpl</CODE> is used for plain dialogs, while=20
      <CODE>CAxDialogImpl</CODE> is used for dialogs that host ActiveX=20
      controls.</P>
      <H2><A name=3Dwindowimpl></A>Defining a Window Implementation</H2>
      <P>Any non-dialog window you create will derive from=20
      <CODE>CWindowImpl</CODE>. Your new class needs to contain three=20
things:</P>
      <OL>
        <LI>A window class definition=20
        <LI>A message map=20
        <LI>The default styles to use for the window, called the =
<I>window=20
        traits</I> </LI></OL>
      <P>The window class definition is done using the=20
      <CODE>DECLARE_WND_CLASS</CODE> or =
<CODE>DECLARE_WND_CLASS_EX</CODE> macro.=20
      Both of these define an ATL struct <CODE>CWndClassInfo</CODE> that =
wraps=20
      the <CODE>WNDCLASSEX</CODE> struct. <CODE>DECLARE_WND_CLASS</CODE> =
lets=20
      you specify the new window class name and uses default values for =
the=20
      other members, while <CODE>DECLARE_WND_CLASS_EX</CODE> lets you =
also=20
      specify a class style and window background color. You can also =
use=20
      <CODE>NULL</CODE> for the class name, and ATL will generate a name =
for=20
      you.</P>
      <P>Let's start out a new class definition, and I'll keep adding to =
it as=20
      we go through this section.</P><PRE><SPAN =
class=3Dcpp-keyword>class</SPAN> CMyWindow : <SPAN =
class=3Dcpp-keyword>public</SPAN> CWindowImpl&lt;CMyWindow&gt;
{
<SPAN class=3Dcpp-keyword>public</SPAN>: