⭐ 欢迎来到虫虫下载站！ | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站
📤 上传资源

📄 4app.html

📁 C ++ in action
💻 HTML
📖 第 1 页 / 共 2 页
字号:
🔍
12 
<html>
<head>

<title>Windows Techniques</title>
    <meta  name="description" content="Introduction to Windows programming">
    <meta name="keywords" content="windows, programming, window, class, message loop">
<link rel="stylesheet" href="../rs.css">
</head>
<body background="../images/margin.gif" bgcolor="#ffffe0">

<!-- Main Table -->
<table cellpadding="6">
    <tr>
    <td width="78">
    &nbsp;
    <td>

</td></tr>
<tr>
<td class=margin valign=top>
<a href="Source/WinCalc.zip">
<img src="../images/brace.gif" width=16 height=16 border=1 alt="Download!"></a>
<br>Download source
</td>
<td>
<h2>Windows Application</h2>

<p>Since I can't possibly cover Windows programming to any depth within the confines of this book, I will now switch to a bird's-eye view of how one might approach the task of writing a Windows application. As before, I will concentrate on the two main challenges of Windows programming: how the program should work and look like, and how to encapsulate and categorize various APIs. The mere number of Windows APIs is so overwhelming that some kind of classification (with C++ classes and namespaces) is a must.

<p>After reading this chapter, I strongly suggest browsing the source code and studying the details of the implementation. 

<h3>Porting the Calculator to Windows</h3>

<p>Taking a command-line application, like our symbolic calculator, and making a minimal port to Windows could be quite easy. We have to find a way, other than <var>std::cin</var>, to get user input; and to display the results in a window. Error display could be dealt with using message boxes. A single dialog box with two edit fields--one for input and one for output--would suffice.

<p>But this kind of port is not only primitive--it doesn't even cover the whole functionality of our original application. In the command-line calculator, the user was at least able to see some of his or her previous inputs--the history of the interaction. Also, in Windows, commands like <i>load</i>, <i>save</i> or <i>quit</i> are usually disengaged from text-based input and are available through menus, buttons, toolbars or accellerator keys. Finally, there are certain possibilities specific to Windows that can enhance the functionality of our program and are expected by the user. An obvious example would be the display the contents of the calculator's memory.
<p>Some of these features don't require substantial changes to the calculator engine. Disengaging commands from text input will actually make the parsing simpler--the <var>Scanner</var> will have to recognize fewer tokens and the <var>CommandParser</var> object will become unnecessary. Other features, such as the display of memory, will require deeper changes inside the <var>Calculator</var> object (which, by the way, will play the role of a Model).

<h3>User Interface</h3>

<p>Whether it's porting or designing an application from scratch, the first step is to envision the user interface. 
<p>In our case, we obviously need an input field, where the user will type the expressions to be evaluated. We also need an output field, where the results of the calculations will appear. We'd also like to have one window for the history of user input, and another to display the contents of memory.
<p>The design of the menu is a non-trivial problem. We know, more or less, what we will have there: Load, Save as well as the traditional About and Exit. We can also add one more command--Clear memory. The problem is how to organize these commands.
<p>The traditional approach, which often leads to barely usable menu systems, is to follow the historical pattern. Menu commands are grouped under File, Edit, View, Tools, Window, Help, etc. Notice that some of these words are nouns, others verbs. Tradition also dictates arbitrarily that, for instance, Exit goes under File, About under Help, Search under Edit, Options under Tools, etc...
<p>The more modern approach is to group commands under noun headings that describe objects upon which these command act. The headings are, as far as possible, ordered from general to specific. The first, most general menu item is Program. This is where you should put the commands About and Exit. The About command displays information about the Program, not the Help. Similarly, you Exit a Program, not a File. 
<p>The Program item is usually followed by such groups as Project, Document (or File); then View or Window, Edit and Search; then the elements of the particular display, such as All, Selection; and finally, Help. Even if the user is used to traditional groupings, he or she is likely to find this new arrangement more logical and easier to use.
<p>In our calculator, we'll have the Program menu followed by the Memory menu. The operations one can apply to Memory are Clear, Save and Load. A more complete version would also have the Help menu.

<p>Finally, it's nice to have a status bar at the bottom of the window to show the readiness of the calculator to accept user input, as well as little command help snippets when the user selects menu items.

<p>Instead of showing you varius sketches, I'll present the final result--the actual screenshot of the calculator's user interface. 
<p>
<img src="Images/Image4.gif" width=401 height=217 border=0 alt="WinCalc">

<h3>Child Windows</h3>

<p>The calculator's main window is tiled with various sub-windows, or child windows. Some of these children--like the title bar, the menu bar, minimize/maximize buttons, etc.--are created and managed by Windows. Others are a programmer's responsibility. 
<p>A <i>child</i> window is owned by its parent window. Since there is often some confusion between the meaning of a "child" window vs. an "owned" window, here's a short summary.

<ul>

<li>Child window: lives in the coordinate system of its parent and its clipped to its boundaries. A child cannot have a menu, but it can have an integer id (that's why the <var>menu</var> member of the <var>CREATESTRUCT</var> doubles as a child id). To create a child window, specify <var>WS_CHILD</var> as window style and initialize the <var>hwndParent</var> member of <var>CREATESTRUCT</var> to its parent's window handle.

<li>Owned window: always appears in front (on top) of its owner, is hidden when the owner is minimized, and is destroyed when the owner is destroyed. The handle to the owner window is passed in the <var>hwndParent</var> member of <var>CREATESTRUCT</var>. An owned window doesn't have to be a child window--when it's not, it doesn't use the owner's coordinate system and is not clipped to its boundaries.
</ul>
<p>You will probably want all windows in your applications to be owned by the top-level window. If, furthermore, you'd like them to be constrained to the client area of the top-level (or some other) window, you'll create them as children of their owners. (Examples of owned, but non-child, windows are dialog boxes and message boxes, about which I'll talk later.)
<p>I introduced a separate class, <var>Win::ChildMaker</var>, derived from <var>Win::Maker</var>, to encapsulate the creation of child windows. You can have a child window based on any window class, as long as you know the class' name. For our purposes, however, we'll be creating windows based on classes that are pre-defined (and pre-registered) by Windows. 
<p>There are several useful window classes corresponding to standard controls. Instead of writing and testing new window procedures, we can get a lot of standard functionality by re-using these controls. That's why I created a subclass of <var>Win::ChildMaker</var> called <var>Win::ControlMaker</var> that can be used as base for the specialized contol makers, such as <var>Win::EditMaker</var>, <var>Win::ListBoxMaker</var> and <var>Win::StatusBarMaker</var>.

<p>Before going into any more detail about controls, let's talk some more about the management of child windows. I made them part of the <var>View</var> object, whose constuctor uses various control makers to create them. There are two edit controls, one of them read-only. There are two listboxes that are particularly suited for displaying lists. Finally, there is a status bar control.

<p>The first thing our program has to take care of is the proper positioning of these child windows. This is usually done in response to the <var>WM_SIZE</var> message sent to the top-level window. The first such message arrives just before the child windows are displayed, so that's a great time to size and position them for the first time. Then, every time the user resizes the top-level window, the <var>WM_SIZE</var> message is sent again. The parameters of <var>WM_SIZE</var> are the width and the height of the client area. All we have to do is to partition that rectangle among all the children. After doing some simple arithmetic, we tell the children to move to their new positions.
<p>Next, we have to take care of the focus. Whenever the calculator is active, we would like the keyboard input to go directly to the input edit control. Since this doesn't happen automatically, we have to explicitly pass keyboard focus to this child window whenever the calculator gets focus. Fortunately, the top-level window is notified every time this happens. The <var>WM_SETFOCUS</var> message is sent to it whenever the window becomes active, including the time of its creation.
12

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -