?? article.htm
字號:
<html>
<body>
<b>Table Of Contents</b>
<dl>
<dd><a href="#Introduction">Introduction</a></dd>
<dd><a href="#MinReq">Minimum Requirements</a></dd>
<dl>
<dd><a href="#Req1">Requirements: What I Need</a></dd>
<dd><a href="#Req2">Requirements: What I Don't Need</a></dd>
</dl>
<dd><a href="#ProtoDesign">The Prototype Design</a></dd>
<dl>
<dd><a href="#Proto1A">The GUI Components</a></dd>
<dd><a href="#Proto1B">The Object Model</a></dd>
</dl>
<dd><a href="#ProtoImp">The Prototype Implementation</a></dd>
<dl>
<dd><a href="#ProtoImp1">The Objects</a></dd>
<dl>
<dd><a href="#OutlookBar">OutlookBar</a></dd>
<dd><a href="#IconPanel">IconPanel</a></dd>
</dl>
<dd><a href="#EyeCandy">Eye Candy</a></dd>
</dl>
<dd><a href="#Conclusion">Conclusion</a></dd>
</dl>
<h2><a name="#Introduction">Introduction</a></h2>
This is yet another Outlook Bar implementation. While Carlos xxx has written an excellent implementation in C#, I wanted an implementation that wasn't heavily dependent
upon <code>gdi32</code>, <code>user32</code>, and <code>comctl32</code> DLL's, and wasn't deeply entwined in someone's framework. Ironic, isn't it! Because I need an
implementation that is better suited for the Application Automation Layer (AAL) framework, and Carlos' implementation, while very thorough, isn't well suited for the
AAL vision of things. I guess this is why the wheel keeps getting re-invented--because you need different wheels for different jobs.<p>
I'm also going to do something I don't see too often in Code Project articles. Most articles are written "after the fact". That is, the component or program is already
implemented, and the article describes its design, usage, and interesting implementation details. In this article, I'm going to expose the development process so that the
reader sees the steps that I took in implementing the control. It's certainly fun to write an article in this manner, and I hope it's just as fun to read it!
<h2><a name="#MinReq">Minimum Requirements</a></h2>
I'll start with requirements. This is about the only formal design process step to which I conform, and even that is problematic, as requirements are a continually evolving
thing in my world. In order to limit the amount of time I spend on something, I have to identify what my minimum requirements are. I depend heavily on working the concept that
the architecture that I develop will accommodate additional requirements as time goes on.<p>
I find it useful to identify in the requirements both what I need and what I don't need. The "don't need" list is a good resource for keeping track of future expansion and helps
to design a good architecture to support those future requirements. One general requirement though--while I'm eventually going to
incorporate the control into the AAL, I'd like to
develop it outside of the framework, so that others can more easily modify it and
incorporate it into their own applications.
<h3><a name="#Min1">Requirements: What I Need</a></h3>
<ul>
<li>The control has a specifiable but fixed width</li>
<li>The control has a specifiable but fixed height</li>
<li>The control contains an number of "bands"</li>
<li>A band consists of two things: a button-like control at the top of the band and a collection of items</li>
<li>Each item in the band has an icon associated with it</li>
<li>Left clicking on the item in the band fires an event</li>
<li>Stay within the confines of the .NET environment. (No DllImport
stuff)</li>
<li>XML defined--band text, icon bitmaps, event names</li>
<li>Owner drawn stuff should be minimized and the control should look good
when a manifest is being used.</li>
</ul>
<h3><a name="#Min2">Requirements: What I Don't Need</a></h3>
<ul>
<li>Resizing the control and the issues that are involved</li>
<li>Large and small icon support</li>
<li>Those cute little band scrolling buttons. I like scroll bars better, anyways.</li>
<li>Popup context menus</li>
<li>Animation (the band "opens" in an animated fashion)</li>
<li>A form designer compatible control. Don't use it, don't need it.</li>
<li>Other kinds of controls in the band other than icons.</li>
<li>Bands cannot be re-ordered by the user (dragging them to change their
order).</li>
</ul>
<p>That's sufficient to begin with. As I start developing the control,
this list will probably change. (It's interesting writing this,
because I haven't begun work on the control yet, so I don't really know if
this is true, but experience has shown that it <u>always</u> is true!</p>
<p>
<h2><a name="#ProtoDesign">The Prototype Design</a></h2>
<h3><a name="#Proto1A">The GUI Components</a></h3>
<p>This step involves getting a basic architecture to support the requirements.
Since one of the goals is to stay within the .NET framework of available tools,
the primary device for implementing an Outlook bar will be panels. One of
the nice things about panels is that they provide an automatic scrolling feature
for their contents. And fortunately, this auto-scroll capability can also
be turned off. I am a firm believer (having it drilled into me by my
boss/neighbor when I was a kid) that concepts should be communicated in words as
well as in pictures. By being able to clearly communicate a design in
words, a dictionary of terms is established which promotes a common
understanding of design concepts and is a stepping stone for determining
implementation issues.</p>
<p>With that in mind, the basic architecture that I have in mind is this:</p>
<ol>
<li>The entire bar will be implemented as a panel (we'll call it the "bar
panel") with auto-scrolling disabled</li>
<li>Each bar will consist of a child "band panel" that contains the band
caption represented as a button. This panel will also have
auto-scrolling disabled. The panel will be sized to the height of the
button when the band is unselected, and will be expanded vertically to the
size of the parent panel when expanded</li>
<li>An "icon panel" will be used as a child to the above panel. It will
be physically positioned so that it starts just below the button in the parent
panel. This panel <u>will</u> have auto-scrolling enabled, as it will
contain the icons that may expand beyond the vertical confines of the entire
band.</li>
<li>From a design point of view, this icon panel needs to be abstracted
sufficiently to support other kinds of panels, such as "tree view panel" or
"list view panel" (see Carlos' implementation).</li>
<li>While I'm not going to bother with small and large icon support in this
version, implementing an image list is a good idea, if for no other reason
than because it supports background color definition.</li>
</ol>
<p>Here's a picture of what I have in mind:</p>
<img src="CSOutlookBar\design.jpg" width="193" height="481">
<p>The horizontal and vertical extents of each panel are for illustrative
purposes only and won't necessarily match the actual implementation.</p>
<h3><a name="#Proto1B">The Object Model</a></h3>
<p>Now that the layout of the GUI components as been developed, the next step is
to design an object model that supports this structure. There is a rule of
thumb that I use when working with any pre-existing classes, as is the case here
(buttons and panels). Always provide a specialization for the class (as
in, a derived class) or a wrapper for the object. While I do violate this
rule more than I'd like to admit, it is a good one to follow, because it allows
for the expansion of the object model at a later time. If the pre-existing
class is used directly, it is almost always certain that later on in the design
some specialization will be required. Adding specialization later, in the
midst of implementation, can result in lots of class renaming and re-testing.
Refactoring, whenever it is done, is a great idea, but it can be really
expensive.</p>
<p>The question then becomes whether to implement a specialized class or a
wrapper class. There are some old terms for this that are still useful but
not too often heard anymore--"is a kind of" and "has a". These represent
specialization and wrapping, respectively. In many cases, it's pretty
difficult to figure out which to use, as is the case here. To help with
that decision, I often rely on an analysis of the semantics used to describe the
problem. In this case, each object, the bar panel, the band panel, and the
icon panel, are all forms of specialization. If these objects are derived
from the Panel class, the architecture can leverage (don't you love that word)
the Panel control collection. This avoids implementing a separate
collection (contrast this to Carlos' implementation, which has a band collection
and an item collection). Hopefully, this design decision will not bite us
later on. Why do I say this? Because experience has taught me not to
rely too heavily on framework functionality. There are often unwanted
side-effects.</p>
<p>Again, by observing the semantics of the GUI component layout and the
diagram, it is clear where the "has a" relationships are:</p>
<ul>
<li>The bar panel object has a band panel</li>
<li>the band panel has a button and a icon panel</li>
<li>the icon panel has a collection of icons.</li>
</ul>
<p>Some of the "has a" relationships are in the form of containers, which brings
up the important issue of determining the m to n relationship of objects:</p>
<ul>
<li>The bar panel to band panel relationship is 1::n</li>
<li>The band panel to button relationship is 1::1</li>
<li>The band to icon panel relationship is 1::1</li>
<li>The icon panel to icon relationship is 1::n</li>
</ul>
<p>While I pretty much don't bother with object model diagrams anymore, I put
this one together:</p>
<img src="CSOutlookBar\objectModel1.jpg" width="627" height="529"><p>
I usually don't specify methods and intrinsic properties during design time when developing on my own because it's sort of a waste of time.
As a project manager, I don't enforce these definitions at design time either with the people I trust. The programmers that I don't trust to write
good code (and there's a lot of "senior software engineers" out there that fit this bill) are required to come up with a complete object model design and psuedo code.
I also enforce naming conventions, case usage, and verb-noun ordering of method names. And for the record, I think Hungarian notation is awful.
<h2><a name="#ProtoImp">The Prototype Implementation</a></h2>
<h3><a name="#ProtoImp1">The Objects</a></h3>
Using the above diagram results in the following stubs for the various objects. Because the <code>Panel.Controls</code> property is used for
containing the control lists, you will not see containers or collections implemented in the class definition.
<pre>using System;
using System.Windows.Forms;
namespace OutlookBar
{
public class OutlookBar : Panel
{
public OutlookBar()
{
}
}
internal class BandPanel : Panel
{
public BandPanel()
{
}
}
internal class BandButton : Button
{
public BandButton()
{
}
}
public abstract class ContentPanel : Panel
{
public ContentPanel()
{
}
}
public class IconPanel : ContentPanel
{
public IconPanel()
{
}
}
internal class PanelIcon : PictureBox
{
public PanelIcon()
{
}
}
}
</pre>
Note that the <code>IconPanel</code> class is public. This allows the application to instantiated the desired band types (of which, IconPanel is the only one provided in this
implementation). Now let's start fleshing out some of the details, starting with the <code>OutlookBar</code>
class.
<h3><a name="#OutlookBar">OutlookBar</a></h3>
<p>First, the <code>OutlookBar</code> needs to be instantiated so that it appears on the
form. Creating a new project, I modified the <code>Form1</code> constructor to instantiate the <code>OutlookBar</code>, and
specified a border style so that its creation and placement can be verified:
<pre>public Form1()
{
//
// Required for Windows Form Designer support
//
InitializeComponent();
//
// TODO: Add any constructor code after InitializeComponent call
//
OutlookBar outlookBar=new OutlookBar();
outlookBar.Location=new Point(0, 0);
outlookBar.Size=new Size(150, this.ClientSize.Height);
outlookBar.BorderStyle=BorderStyle.FixedSingle;
Controls.Add(outlookBar);
}
</pre>
Success!<p>
<img src="CSOutlookBar\screenShot1.jpg" width="240" height="220"><p>
<b>The First Band</b><p>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -