通过

Fit N Finish for Qwerty Keyboards

  • 项目

This FitNFinish document describes a number of best practices for creating Windows Mobile devices with QWERTY keyboards.  Although there are a lot of suggestions for placement of keys, my main purpose for writing this was to describe the best way to handle shift, shift lock, alt, and alt lock.  This subject is surprisingly complex, and I’ve seen a number of QWERTY devices handle these functions incorrectly.  See section 3 of the attached document for a detailed description of the correct operation of these keys.

The attachment contains the FitNFinish document, “QWERTY Suggestions”  in both Word 2007 and PDF formats.  The content is the same in both, so use whichever file works best for you.  There is also a KeybdFnF.exe.  This is a Windows Mobile application that will run on both touch screen (PocketPC) and non touch screen (Smartphone) devices.  The application allows you to test that your shift and alt functionality work correctly.  It asks you to type certain key combinations on your device, shows what your keyboard sent, and compares that to what it should have sent.  The program will verify that your shift and alt keys match the suggestions in section 3 of the document.

The program was written with the Windows Mobile SDK.  Please let me know if you have any trouble running it on your devices.

Mike Calligaro

 

FnF Qwerty.zip

Comments

  • Anonymous
    June 14, 2007
    Hi Mike, I tried the application but found some testing is not correct.  For example:
  1. Press the shift key.
  2. Press the shift key again.
  3. Press the "a" key, then the "b" key, then the "c" key.
  4. Press the shift key.
  5. Press the "d" key, then the "e" key The expected result of above testing is "ABCde" but I think the expected result should be "ABCdE". In step 3, it is still in "Caps Lock" mode. In step 4, it is in "Caps Lock"'s Sticky mode.  That means the next letter is lower case but the next 2 letters should become back to "Caps Lock" (upper case). Below is another example:
  6. Hold the Alt/Fcn key.
  7. Press the "1" key.
  8. Release the Alt key.
  9. Press the "1" key again. The expected result is "11" but I think the expected result should be "1u" (if "u" and "1" are at the same button). The next test is also strange:
  10. Press (don't hold) the Alt/Fcn key.
  11. Press the "1" key.
  12. Press the "1" key again. The expected result is "11" but I think the expected result should be "1u" (if "u" and "1" are at the same button). The final test of Alt/Fcn key is the same as my 1st example, the expected result is "11111" but I think it should be "111u1". David

  • Anonymous
    June 15, 2007
    Thanks for the comment, David. There are two parts to this, ABCdE vs ABCde and 11 vs 1u.   ABCdE: When you're in Caps Lock, there are two possible designs for getting out.  I'm suggesting that you follow a design where pressing shift once turns off caps lock.  I believe that you're describing a situation where you need to press shift TWICE to disable caps lock.  Pressing shift once in this scheme would only turn off caps lock for one character.   The latter scheme is more similar to the desktop (caps lock + shift = lower case) but it's also confusing to the user.  We've found that users get stuck in caps lock and have difficulty figuring out how to get back to normal.  The single shift to leave caps lock scheme has much less confusion.  The downside is that you lose the ability to easilly type a single lower case in the middle of a bunch of upper case characters, but that's a rare thing to do. 11: I had to play around to figure out what was going on here.  You've exposed a bug in my program by doing something I didn't expect.  You're absolutely right that it should have expected "1u" in your case.  The trouble is, on the screen where it asked you to type in the character that is the non-alt of "1" you typed in "1" where I was expecting you to type in "u".  If you run the test again and type in "u" on that screen, the "11" problem will go away.   I need to think of a way to make that section more clear.  Maybe I'll disallow typing in 1 there, since I know that's not the right character. Thanks! Mike

  • Anonymous
    August 28, 2007
    Hi David : If I implement a Option/shift lock function, but I hope to clear it when the user uses up/down keys to move the cursor from one filed to another. How could I know the cursor change? I tried use the "GetForegroundkeyboardTarget", which can get the window handle with keyboard target. If the handle chnages, then I know the field changes. In most cases, it works well, but it always gets the same handle in "contacts". I think it is caused because the contacts is designed by listview. I also tried "GetFocus", "ListView" function. But they can't also work. Do you have any idea that I can know that user changes the cursor. My OS is Windows Mobile 6 Professional. Thanks

  • Anonymous
    March 05, 2009
    <a href= http://index2.4-suki.ru >������� ��������� qip pda</a> <a href= http://index3.4-suki.ru >������� �������</a> <a href= http://index4.4-suki.ru >��� �� ����</a> <a href= http://index5.4-suki.ru >������ qip 8070</a> <a href= http://index1.4-suki.ru >jimm ������� ���������</a>