I gently walked away, just as I gently came to the Duilib without focus window implementation, gently I went to duilib

I gently walked away, just as I gently came to the Duilib without focus window implementation, gently I went to duilib

In Windows programming, we are used to a window from creation to display and getting focus. We always feel that the focal point is taken for granted when a window is created, and the focal point must be obtained when a window is displayed. When a new window is displayed, the message WM_SETFOCUS is received, and the old window receives the message WM_KILLFOCUS. Maybe we don't care about switching the focus, because there is no impact from the visual perspective, but the keyboard-type messages are constantly switching the response window when the focus changes. We all know that when the mouse message arrives, it determines which window responds with the mouse coordinate point and where to place it. When the keyboard message arrives, who decides the response window of the message? The answer is the focus. The focus is the "stage" of the keyboard message. As long as any window is placed on the "stage" of the focus, all keyboard-type messages are naturally allocated to the window process function of the window.

But then again, under what circumstances does the window need no focus? I have summarized two situations: 1. prompt window, such as the tooltipWindow we commonly use, the prompt window on the cool dog music list, and the QQ we use every day, move the mouse over your avatar, the prompt window appears. When QQ receives a message, it points to the message list Prompt window displayed on the QQ taskbar icon. Of course, you may ask, what is the relationship between the prompt window and the focus? What is the relationship between the prompt window and the focus? In fact, the impact is not very great on the surface, but think about it carefully. This is not in line with the native Window control mechanism. The WM_MOUSEMOVE message is just a passer, and the "stage" of the keyboard message cannot be disturbed by mouse movement. For example, when we open QQ chatting, or are entering a complicated table, the mouse is shaking and the cursor is gone. Is it so bad? We have to find the original editing area again and click the entered position to re-display the cursor to continue the input. The creation and destruction of the prompt window are usually controlled by WM_MOUSEMOVE, so this type of window cannot obtain the focus. 2. in the menu window, Windows native menus do not get the focus, but you may not believe it. In fact, it is easy to test it and you can see it. You can use Visual Studio to create a Win32 project with a menu, the WM_KILLFOCUS message is captured in the window procedure function. When the menu pops up, WM_KILLFOCUS does not respond. Here, you will also ask, the menu pop-up and focus have a hair relationship, who specifies that the menu must be non-focus? Of course no one has specified this, but it is absolutely true to follow the native mechanism. First, when you use a window to simulate a menu, the focus switching is a huge obstacle. Of course, some people also use this feature to use the WM_KILLFOCUS message to control the destruction of the menu window, this can only reflect the advantages of a level-1 menu. However, when the cascade menu is made, the problem arises again. When the sub-menu comes out, the main menu will lose focus, this adds a lot of trouble. Menus at different levels are highly coupled and complex to maintain. Second, the constant switch of focus will affect the appearance of appearance. When I mention this, there will certainly be some questions. Where can I start from? The focus is invisible to the menu. How can it affect the appearance? Someone used Duilib to write a MenuDemo, which should be used by many people. The effect looks good. But I personally think there is still a problem, and we may not regard it as a problem. When you move the mouse over the main menu, the sub-menu will pop up in turn. If you happen to enable the Input Method in an edit of this window, the tool box of the input method retains the current window, the switch and display of the sub-menu will cause the tool boxes of the Input Method to flash constantly. I personally feel that it affects the appearance and I don't know what you think. The reason is that the focus switch causes the response window of the input message to switch continuously, resulting in flickering. Cool I music box should have been used by everyone. If you haven't guessed it, you can use the menu implemented by MenuDemo of Duilib. You can try it, switch to Chinese, enter a few words in the search box, right-click the pop-up menu, and slide over the main menu, so that the sub-menu appears in turn, check whether the tool box of the input method keeps flashing. In addition, all the prompt boxes in the cool music box are focused. When the menu pops up, you have to block the MouseHover events of some controls to prevent the pop-up of the prompt box from stealing the focus and causing the menu to be destroyed. I think this should be because Duilib does not currently support the non-focus window. To solve this problem, Skilla spent a lot of time on the Duilib menu, because there are too few materials on the Internet, but we have finally achieved results, we still have the opportunity to share with you.

In fact, it is relatively simple to create a non-Focal Point window. 1. when the window is displayed, use ShowWindow (SW_SHOWNOACTIVE). In this way, no focus is obtained when the window is displayed, but you cannot click it. After you click it, the focus is still obtained. 2. the WM_MOUSEACTIVATE message is intercepted during the Window Process and the MA_NOACTIVE message is returned. This is perfect. In this case, you can right-click the left mouse button in the customer area and the window will not get the focus, however, you cannot click the title bar. In Duilib, our window generally does not contain the native title bar. In this case, remove the title bar, as long as you do not take the initiative to SetFocus, windows are never focused.

If only Win32 or MFC is used for programming, the above two steps are enough, but we also use the Duilib framework. The control of window focus is not only involved in c0000wwnd, but also in CPaintManagerUI:: SetFocus operation. If the window is not processed, the focus will still be obtained. At this time, we need to make a small modification to the source code. 1. add a Boolean attribute bool m_bUnfocusPaintWindow to CPaintManagerUI to identify whether the drawn window is a non-focus window, initialize it to false during construction, and add the Get and Set methods, allow external access. 2. Search for all the: SetFocus operations in the cpp file of CPaintManagerUI (note the previous two points) and add if (! M_bUnfocusPaintWindow. In this case, we only need to set m_bUnfocusPaintWindow to true to prevent CPaintManager from stealing the focus. This will not affect the original functions, but also achieve the desired results. 3. To facilitate the use of the 219 rows in the cpp file of CDialogBuilder, add a judgment

Else if (_ tcscmp (pstrName, _ T ("unfocus") = 0)
{
If (_ tcscmp (pstrName, _ T ("true ")))
PManager-> SetUnfocusPaintWindow (true );
}

In this way, you can set whether the Window is a non-focus Window in xml. You only need to add an unfocus = "true" attribute to the Window tag. For example

<Window size = "400,240" caption = "," roundcorner = "" unfocus = "true">

This is only the application of the non-focus window on the TipWindow. I will write a Demo to share the menu implementation with you as soon as possible.

If you have any questions or suggestions on my changes, you can leave a message or contact QQ: 848861075 (Skilla)