After the window registration, the window needs to be created. Let us proceed to the function InitInstance. This variable hWnd , is a handle to our main window. If a window parent is specified, the newly created window will become a child of the parent. Here is a closer look at this particular structure. I will not explain in depth resource files, as resources will be explained in further tutorials, but for a quick overview: An accelerator table is used to bind keyboard combinations to application commands.
By default, template applications use automatically generated accelerator tables, but keep in mind that these are not required at all. Now that the main window is created and setup, it is time to setup the main loop of our application, which will take care of processing messages and events.
Before demonstrating the code, we will take a look at the concept of sending and recieving events in an event-driven architecture. To begin with, the system checks if there are pending messages in the message queue. If such a condition is met, then the system translates and dispatches the message to the appropriate window, which is, in this case, our main window.
Each window is given a procedure. This procedure is called by with the window handle to which it is associated, the message type, and additionally, with up to two parameters, wParam , lParam.
The window procedure is responsible for doing tasks, often based on the message type. If the message type is the quit message, the function will return with negative result, causing the message loop to end.
If this message differs from quitting, then the system will return to the message queue to process the next message, or wait until it receives new notifications. In order to process messages continuously, we need to create a loop. This loop, called the message loop. Here is the code from WinMain. The GetMessage function is used to retrieve pending messages in the message queue, waiting for a particular event to occur, such as mouse clicks, window resizing, focus loss, etc.
As it recieves a message, the function TranslateAccelerator is used to determine whether this message was triggered by an accelerator handle. If this is the case, then the accelerator will handle the message itself and redirect it to the proper commands. This function, DispatchMessage , is used to dispatch messages to a window procedure. This is the window procedure, which is called when a particular event is sent this window.
To begin with, let us have a look at the function's declaration and parameters. The first parameter, hwnd , represents the current window being processed.
This is represented by hwnd in the InitWindow. The second parameter, message , is a system-defined message. This is used to determine the nature of the event,. At a first look, this function looks confusing, but it is relatively simple to understand.
As simplicity matters in these introductory tutorials, the definition of each case will be separated. This message is sent whenever a user interaction occurs, such as menu item selection, or when a parent receives a notification from a child window. Before explaining the main purpose of both macros , we must comprehend what wParam is. If targeting a 64 bits architecture, such as Windows x64, this will constitute an alias to a 64 bits integer, which is equivalent to an unsigned long long , or unsigned long long int.
Note: We must ensure to clear the upper part again, otherwise it could result in improper values. Once retrieved, this value will tell us the message ID, where prefixes such as IDM are used as naming conventions to indicate that this represents a message ID.
I will not explain how DialogBox works for simplicity purposes. This will be covered in further tutorials. This event occurs everytime a window is redrawn.
The function BeginPaint and EndPaint are used to specify both start and end of drawing process. On return, all the drawing that was done will be sent to screen. This command is called whenever the DestroyWindow function is called. For example, whenever a user clicks the close button of the window, at the upper right corner windows applications , DestroyWindow is called.
Call of PostQuitMessage is used to indicate that the window is terminating, thus causing the message loop to end. In the default case, a function named DefWindowProc is used as a default return result. This function simply calls the default window procedure to process all messages that were not caught in WndProc. For maximum efficiency in animating windows, call UpdateLayeredWindow to change the position and the size of a layered window. Please note that after SetLayeredWindowAttributes has been called, subsequent UpdateLayeredWindow calls will fail until the layering style bit is cleared and set again.
Hit testing of a layered window is based on the shape and transparency of the window. This means that the areas of the window that are color-keyed or whose alpha value is zero will let the mouse messages through. A message-only window enables you to send and receive messages. It is not visible, has no z-order, cannot be enumerated, and does not receive broadcast messages. The window simply dispatches messages. There are many ways that a window can relate to the user or another window.
A window may be an owned window, foreground window, or background window. A window also has a z-order relative to other windows. For more information, see the following topics:. Each process can have multiple threads of execution, and each thread can create windows. The thread that created the window with which the user is currently working is called the foreground thread, and the window is called the foreground window. All other threads are background threads, and the windows created by background threads are called background windows.
Each thread has a priority level that determines the amount of CPU time the thread receives. Although an application can set the priority level of its threads, normally the foreground thread has a slightly higher priority level than the background threads.
Because it has a higher priority, the foreground thread receives more CPU time than the background threads. The foreground thread has a normal base priority of 9; a background thread has a normal base priority of 7. To retrieve a handle to the foreground window, use the GetForegroundWindow function. To check if your application window is the foreground window, compare the handle returned by GetForegroundWindow to that of your application window.
An application sets the foreground window by using the SetForegroundWindow function. The system restricts which processes can set the foreground window. A process can set the foreground window only if:. It is possible for a process to be denied the right to set the foreground window even if it meets these conditions. An overlapped or pop-up window can be owned by another overlapped or pop-up window.
Being owned places several constraints on a window. Only an overlapped or pop-up window can be an owner window; a child window cannot be an owner window. The hwndParent parameter must identify an overlapped or pop-up window. If hwndParent identifies a child window, the system assigns ownership to the top-level parent window of the child window. After creating an owned window, an application cannot transfer ownership of the window to another window.
Dialog boxes and message boxes are owned windows by default. An application specifies the owner window when calling a function that creates a dialog box or message box. The z-order of a window indicates the window's position in a stack of overlapping windows. This window stack is oriented along an imaginary axis, the z-axis, extending outward from the screen.
The window at the top of the z-order overlaps all other windows. The window at the bottom of the z-order is overlapped by all other windows.
The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows. A topmost window overlaps all other non-topmost windows, regardless of whether it is the active or foreground window. All topmost windows appear in the z-order before any non-topmost windows. A child window is grouped with its parent in z-order. When an application creates a window, the system puts it at the top of the z-order for windows of the same type.
You can use the BringWindowToTop function to bring a window to the top of the z-order for windows of the same type. The user changes the z-order by activating a different window. The system positions the active window at the top of the z-order for windows of the same type. When a window comes to the top of z-order, so do its child windows.
You can use the GetTopWindow function to search all child windows of a parent window and return a handle to the child window that is highest in z-order. The GetNextWindow function retrieves a handle to the next or previous window in z-order.
At any one given time, a window may be active or inactive; hidden or visible; and minimized, maximized, or restored. These qualities are referred to collectively as the window show state. The following topics discuss the window show state:. An active window is the top-level window of the application with which the user is currently working.
To allow the user to easily identify the active window, the system places it at the top of the z-order and changes the color of its title bar and border to the system-defined active window colors.
Only a top-level window can be an active window. When the user is working with a child window, the system activates the top-level parent window associated with the child window. Only one top-level window in the system is active at a time. An application activates a top-level window by calling the SetActiveWindow function. Although an application can activate a different top-level window at any time, to avoid confusing the user, it should do so only in response to a user action.
An application uses the GetActiveWindow function to retrieve a handle to the active window. A window can be disabled. A disabled window receives no keyboard or mouse input from the user, but it can receive messages from other windows, from other applications, and from the system.
An application typically disables a window to prevent the user from using the window. For example, an application may disable a push button in a dialog box to prevent the user from choosing it. An application can enable a disabled window at any time; enabling a window restores normal input.
By default, a window is enabled when created. An application enables or disables an existing window by using the EnableWindow function. An application can determine whether a window is enabled by using the IsWindowEnabled function. When a child window is disabled, the system passes the child's mouse input messages to the parent window. The parent uses the messages to determine whether to enable the child window. For more information, see Mouse Input. Only one window at a time can receive keyboard input; that window is said to have the keyboard focus.
If an application uses the EnableWindow function to disable a keyboard-focus window, the window loses the keyboard focus in addition to being disabled. If a child window, or other descendant window, has the keyboard focus, the descendant window loses the focus when the parent window is disabled. For more information, see Keyboard Input. A window can be either visible or hidden. The system displays a visible window on the screen. It hides a hidden window by not drawing it.
If a window is visible, the user can supply input to the window and view the window's output. If a window is hidden, it is effectively disabled. A hidden window can process messages from the system or from other windows, but it cannot process input from the user or display output. An application sets a window's visibility state when creating the window.
Later, the application can change the visibility state. For example, an application may keep a new window hidden while it customizes the window's appearance. An application can determine whether a window is visible by using the IsWindowVisible function. When an owner window is minimized, the system automatically hides the associated owned windows.
Similarly, when an owner window is restored, the system automatically shows the associated owned windows. Occasionally, an application may need to hide the owned windows without having to minimize or hide the owner. In this case, the application uses the ShowOwnedPopups function. Hiding an owner window has no effect on the visibility state of the owned windows. When a parent window is visible, its associated child windows are also visible.
Similarly, when the parent window is hidden, its child windows are also hidden. Also, a visible child window is subject to the clipping rules established by its parent-child relationship.
If the window's parent window is not visible, it will also not be visible. For example, suppose your program opens a TCP connection and waits indefinitely for the server to respond. If you do that inside the window procedure, your UI will not respond until the request completes. During that time, the window cannot process mouse or keyboard input, repaint itself, or even close. Instead, you should move the work to another thread, using one of the multitasking facilities that are built into Windows:.
Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. Is this page helpful? Please rate your experience Yes No. Any additional feedback?
In this article.
0コメント