The window should be skilled in the window
Since the current use of Windows applications is strictly limited, what kind of function you want to implement can only use Windows to provide a function or structure. So here you only need to care about the two basic Windows structures to be used in the form geometry: Point and RECT.
In Windows, there are two coordinate spaces. One is the CLIENT AREA coordinate space, its origin (0, 0) in the upper left corner of the window (called Client Space, customer space?). When the window moves in the screen, the relative coordinates of the customer area will not change. Another coordinate space is a desktop coordinate space, which is an absolute space, and its coordinate origin is on the upper left corner of the screen (also called Screen Space).
Windows uses the POINT structure to represent the 2D coordinate system. It has two long integer structural variables, one represents a horizontal axis (X-axis), a representative vertical axis (Y-axis).
TYPEDEF STRUCT TAGPOINT {Long X; Long Y;
Since all windows are rectangular (huh, called rectangles may be more written.), Windows uses a RECT structure to express a rectangle. You will notice that the essence of this structure is two points connected to the first point, the first representative of the upper left corner of the rectangle, and the other represents the lower right corner of the rectangle.
TYPEDEF STRUCT; long toptom;}
Left of the left
Top window
Right window right (right - left side is width)
Bottom window bottom (bottom - top is height)
You can use the function getClientRect to get the client rectangle of the window. Because the left and top are always 0, the value of the right and bottom is the width and height of the window.
[color = blue]
Bool getClienceRect
HWND HWND,
LPRECT LPRECT
);
[color]
HWND Do you want to know the handle of the window about the information
LPRECT you want to use a client rectangle to fill a pointer
Since the client rectangular information of the window obtained by using getClientRect is based on customer area coordinate space, you may often need to know what coordinates should these points relative to desktop coordinate spaces. The ClientTScreen function provides you with this conversion function, its function prototype is as follows:
Bool ClientToscreen (HWND HWND, LPPOINT LPPOINT);
Handle of the window defined by the HWND client
LPPOINT client's pointer, this point (in Client Space) will be converted into points in screen space (screen space)
In order to convert the rectangles from the getClientRect function to the rectangle under the screen space, you can use the ClientToscreen function on both rectangular members of Bottom and Right (Dear Ogdev Member, please think so can do this). Although lazy is a very indecent behavior, it is indeed, huh, huh!
There is a matter to explain that the width and height of the window may make the form structure to mess. For example, you want an 800 x 600 pixel client rectangle, but the CREATEWINDOW you call is given the size of the entire window, including those that adjust the large and small columns, title bar, and menu bar. This is to say to you. Different, the client rectangle may become smaller. However, fortunately, you can use the AdjustWindower to convert the rectangle of the client rectangle to the window size you want (800 x 600). It requires each coordinates to re-adjust their values based on the window style DWStyle, and the window style must be set to work correctly as DWStyle used in CREATEWINDOW. If it is not a WS_POPUP style, the left and top coordinates of the window may be negative after adjustment. Bool AdjustwindowRect (LPRECT LPRECT, DWORD DWSTYLE, BOOL BMENU);
LPRECT points to a pointer to the RECT structure that will be adjusted
DWStyle has generated window style, it indicates how much each coordinates need to be adjusted. For example, if the window's style is WS_POPUP, it is not adjusted at all. (Dear Ogdever, you know why? Yes, because the window created by CreateWindow at this time is the client rectangle you want.)
BMenu Boolean, if the window has a menu, TRUE. As in this case, because there is no menu, you just need to pass false to this parameter.
Windows has a high-performance graphics library that performs operations on the handle of the graphics device. This library is called GDI, or Graphical Device Interface. It allows users to draw straight lines, ellipses, bitmaps, text (in the later chapters, I will give you a text drawing capabilities) and other things. One of these examples is to use it to draw "Hello, World" text on the screen. Behind this book, you will see more of GDI more features.
Important window message
Most of this book use Windows as a JUMPING-OFF POINT (critical point?) - a way to build a window to draw on the screen.
Here, I only give you a small number of subsets in a large number of window messages in Windows. Table 1.4 lists some important messages and their parameters.
Table 1.4 Some important window messages
WM_CREATE
After Windows completely creates a window's window, this message is sent to the application before you have not started. This is the first time that the application can see its window of HWnd is when it is.
WM_PAINT
This message is sent to the application when Windows wants to self-drawn itself.
Parameters: (HDC) WPARAM is a DC (Device Context) handle that can be drawn in the window.
WM_Close
This message is sent when the window is required to be closed. You can confirm before shutting down the window.
WM_SIZE
When the window is adjusted, this message is sent. When the window is adjusted, the position in the upper left corner does not change (therefore, when you start adjusting the size from the upper left corner,
WM_MOVE and WM_SIZE messages will be sent)
Parameters: WPARAM: Adjust the size of the flag. In addition to size_minimized, there are other signs. SIZE_MINIMIZED is sent when the window is minimized.
LOWORD (LPARAM) Client Area New Width (not the entire window) HiWord (LPARAM) client area new height (not the entire window)
WM_MOVE
This message is sent when the window is moved.
Parameters: (int) loword (lparam) client area new X coordinate
(INT) HiWord (LPARAM) client area new Y coordinate
Wm_quit
This is the last message that the application can get. After getting this message, the application is over. You don't have to handle this message, but it doesn't go through WndProc. However, it will be processed in WinMain's Message Pump, and the program will jump out of the loop and then end.
WM_KEYDOWN
This message is received whenever the button is pressed. Auto repeat in a specified time will also receive this message
Parameters: (int) WPARAM This is the virtual key code of the button. Before handling it, if you call TranslateMessage in the message, if it is a key ASCII code (letters, numbers, punctuation), it will be converted to the actual ASCII character.
WM_KEYUP
This message is received when the button is released.
Parameters: (int) WPARAM The virtual key of the released key.
WM_MOUSEMOVE
MouseMove is a message that often needs to be received. Each time the mouse moves at the client area of the window, the application obtains a new location of the mouse cursor for the origin of the client area.
Parameters: Loword (LPARAM) The X coordinate of the mouse, relative to the upper left corner of the client area
The y coordinate of the HiWord (LPARAM) mouse, relative to the upper left corner of the client area
WPARAM key sign. This can let you know what the status of the keyboard is, which uses special keys (for example: such as Alt-Left combination)
The logo of the key is as follows:
· MK_Control: Description Ctrl key is pressed
· MK_LBUTTON: Description the left mouse button is pressed
· MK_MBUTTON: Description mouse button is pressed
· MK_RBUTTON: Description the right mouse button is pressed
· MK_SHIFT: Description Shift button is pressed
WM_LBUTTONDOWN
This message is received when the user presses the left mouse button in the client area. You only receive a message if you have been pressed, and you will not be constantly sending a message.
Parameters: Loword (LPARAM) The X coordinate of the mouse, relative to the upper left corner of the client area
The y coordinate of the HiWord (LPARAM) mouse, relative to the upper left corner of the client area
WPARAM key sign. This can let you know what the status of the keyboard is, which uses special keys (for example: such as Alt-Left combination)
The logo of the key is as follows:
· MK_Control: Description Ctrl key is pressed
· MK_MBUTTON: Description mouse button is pressed
· MK_RBUTTON: Description the right mouse button is pressed
· MK_SHIFT: Description Shift button is pressed
WM_MBUTTONDOWN
When the user presses the tree mark in the customer area, you will receive this message. You will only receive a message when the button is pressed. If the button is always in the state, it will not constantly receive the message.
Parameters: Loword (LPARAM) The X coordinate of the mouse, relative to the upper left corner of the client area
The y coordinate of the HiWord (LPARAM) mouse, relative to the upper left corner of the client area
WPARAM key sign. This allows you to know what the status of the keyboard is what special key (for example: such as Alt-Left combination). The logo of the key is as follows:
· MK_Control: Description Ctrl key is pressed
· MK_LBUTTON: Description the left mouse button is pressed
· MK_RBUTTON: Description the right mouse button is pressed
· MK_SHIFT: Description Shift button is pressed
WM_RBUTTONDOWN
When the user presses the mouse button in the customer area, you will receive this message. You will only receive a message when the button is pressed. If the button is always in the state, it will not constantly receive the message.
Parameters: Loword (LPARAM) The X coordinate of the mouse, relative to the upper left corner of the client area
The y coordinate of the HiWord (LPARAM) mouse, relative to the upper left corner of the client area
WPARAM key sign. This allows you to know what the status of the keyboard is what special key (for example: such as Alt-Left combination).
The logo of the key is as follows:
· MK_Control: Description Ctrl key is pressed
· MK_LBUTTON: Description the left mouse button is pressed
· MK_MBUTTON: Description mouse button is pressed
· MK_SHIFT: Description Shift button is pressed
WM_LBUTTONUP
It is received when the user releases the left mouse button on the client area.
Parameters: This parameter is equivalent to parameters in WM_RBUTTONDOWN
WM_MBUTTONUP
The user is received when the user is released in the client area.
Parameters: This parameter is equivalent to parameters in WM_RBUTTONDOWN
WM_RBUTTONUP
The user is received when the user is right-click.
Parameters: This parameter is equivalent to parameters in WM_RBUTTONDOWN
WM_MOUSEWHEEL
Many new mouse rollers now have a z control axis, which can be rotated forward or back, or press. If it is pressed, it is generally a message in the mouse button. However, if it is rotated forward or back, then the following parameters will be passed.
parameter:
(Short) HiWord (WPARAM) Since the last message, the number of rollers rotates. The positive number indicates that the roller is rotated forward (away from the user), and the negative number indicates the roller backward (in the direction of the user).
(Short) Loword (LPARAM) The X coordinate of the mouse, relative to the upper left corner of the client area
(Short) HiWord (LPARAM) Mouse Y coordinate, relative to the upper left corner of the client area
The logo of the loword (wparam) button. This allows you to know what the status of the keyboard is what special key (for example: such as Alt-Left combination).
The logo of the key is as follows:
· MK_Control: Description Ctrl key is pressed
· MK_LBUTTON: Description the left mouse button is pressed
· MK_MBUTTON: Description mouse button is pressed
· MK_SHIFT: Description Shift button is pressed
MFC
You may have guessed it now, Windows application programming is actually not a very easy thing. People tend to fear the puzzles. When they have failed many times, they will be discouraged. So if the large number of code required for Windows work needs to be re-filled in each application, then it will be considered an ugly, people who are more annoying. These things should be abstract, then package, let each application can call directly, without letting programmers will rewrite themselves. At present, there are many libraries in the market to do these things, the most important of which is a set of libraries developed by Microsoft, called MFC.
MFC, or Microsoft's basic class is some system classes that are designed to encapsulate Win32 API. It allows you to create a very common Windows program task with a simple way. Your program is inherited from cwinapp, and the window is inherited from CWND, and the dialog box is inherited from cdialog, and so on. These make the program's writing easier, because the work necessary for a large number of complex Windows, MFC has been solved for you. MFC is the best tool for quickly creating existing front-end code. However, things are not as smooth as it is just beginning. First, the MFC is an application for viewing the type of view (just like writing). Its code supports floating tools, which can handle some non-modular dialogs, and work with GDI. But unfortunately, these things are not used when making 3D games.
Another problem with the MFC is the code size and running speed. The new function it gives is generated at a high price: quite large DLL unless they are loaded into memory, otherwise they will make your program load time be long.
Finally, for DirectX, MFC is not a best development partner. Their program design models and some APIs that have been designed are different. For example, the Direct3D application needs to know when the window is moved or the size is changed so that it can rehab the window. However, in the MFC, the notice of these changes to the window is not an instant event, so it cannot be notified that the window will reselect yourself in time. If the DirectX window is a document window that can be moved relative to its parent window, this inconvenience is especially prominent. However, these hinders are not to overcome, they are just a lot of pain. However, I want to tell you a good news, that is when developing 3D games, most of your programs will run in full-screen mode, which does not require the Gui Bells and whistles provided by MFC.
In this book, all the code will not use the MFC, so we will no longer explore its details. If you seriously develop 3D games, you will need some tools to manage your code. At this time, you can open a good book about MFC, enrich yourself, and you can use it right away. Here, I recommend everyone to see "Professional MFC With Visual C ", this is one of the best books on MFC, edited by Mike Blaszczak, Wrox Publishing House published.
