About the edit control focused state, call the keyboard you wrote

First, involved in writing their own keyboard

It does not include full-width or Chinese characters, because it uses only simple letters, such as alphabets and numbers. So just use the same keyboard as your phone's input password keyboard.

Problems encountered: 1, using the method of keybd_event () to send messages, regardless of the sending case letters are displayed lowercase letters

2, the keyboard can not have the focus state, otherwise the use of keybd_event will not be able to send the word character edit box. Using a state with focus causes the edit control to be too coupled with the keyboard I wrote myself.

3, due to the use of Duilib tilelayout and all keyboard keys appear normal alignment.

Solution:

1, using keybd_event () is to simulate our common keyboard on the various key operation. To appear with uppercase letters or other characters such as "@#$%", you need to simulate the character of the keyboard's input shift+ the corresponding position. (Here I use look-up table, the way to do the operation.) When you need to press SHIFT + other keys to implement the same group, and the other shift keys are not placed in the same order in the other group. (Here's a trick to get the key value for each character: write a small software that gets the key value, and then get the key value for each key.) And through the table just used to match the character in the first place, thereby sending the key value of the key)

2, the keyboard can not have the focus state, you need to create this keyboard dialog when you set the Glw_exstyle field Ws_ex_noactivate

3, after research tilelayout and horizontallayout source found Tilelayout layout method and Horizontallayout layout calculation method is not the same (SetPos function), This results in a way of using the tilelayout layout in ways that are not normal. (This calculation should be the result of a problem with the Tilelayout calculation method). At last, we use the simple layout of horizontalalyout to operate.

Second, how to get the edit control to the focus, call my keyboard

My software uses the Duilib interface library, and when Ceditui gets to the focus, it creates Ceditwnd, which is the creation of the original ecological edit. The Ceditwnd class is destroyed when the Ceditui loses focus, thereby destroying the temporarily created original ecological edit. So the simple idea is to call my keyboard in the constructor and destroy my keyboard inside the destructor.

And in the constructor there is no corresponding ceditui the window corresponding to the dialog handle, so modified the Ceditwnd source

from void Init (ceditui* powner) The Powner parameter refers to the constructor Ceditwnd (ceditui* Powner)

So that the keyboard can be easily implemented and the use of the keyboard.

Third, because I am using the WinCE mobile device, resulting in a phenomenon is: when the edit in the bottom of the screen, the keyboard will block the edit

The first way to solve this problem is to have the user manually move the keyboard so that you can see the corresponding edit control. But this kind of user experience is not good.

So another way is used: when the keyboard is blocking the edit, the software automatically moves up to prevent the edit from being blocked. (Here encountered up the time, just start debugging when there is a direct loss of focus phenomenon, the specific reason is what, how to solve, suddenly forget ...) ）。

Four, sometimes the user obtains the keyboard, the input completes, does not want to let the keyboard lose the focus, only wants to let the keyboard disappear. Then I made a button on the keyboard that lost the click to hide the keyboard and then made the keyboard disappear. But the focus is on the edit.

What needs to be resolved is that when you click the Hide button, the edit will also lose focus (because the software has lost focus during the move down, for specific reasons forget/qiao), and when the move is complete, edit will regain focus and recall the keyboard. So I did a little clever trick here: Place a global count. When you click the Hide button is an exception so set the count is less than 0, when the program comes in again to invoke the keyboard button, set back the initial state of the variable, and then return directly to the keyboard instead of showing.

PS: Because the source code in the company can not be copied out, so only to write out the corresponding related ideas. And the previous period of time rather busy without recording corresponding problems, and the emergence of fragments ... , so some of the reasons for the problem have been forgotten.

However, it is still possible to make a keyboard call with this final idea. and keyboard making.

About the edit control focused state, call the keyboard you wrote