There is a bug in Part #9b!

by Michael S. Kaplan, published on 2006/04/18 17:40 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/04/18/578557.aspx


There was indeed a bug in the code I posted in Getting all you can out of a keyboard layout, Part #9b. It does not exist in any prior versions....

It was first pointed out by Joku, in this comment.

Here is the diff for those of you who are following along at home!

Thanks, Joku!

The crossedd out gray lines below should be replaced with the green lines underneath them.

                            for(int caps = 0; caps <= 1; caps++) {
                                ClearKeyboardBuffer((uint)KeysEx.VK_DECIMAL, rgKey[(uint)KeysEx.VK_DECIMAL].SC, hkl);
                                FillKeyState(lpKeyState, ss, (caps != 0));
                                FillKeyState(lpKeyState, ss, (caps == 0));
                                sbBuffer = new StringBuilder(10);
                                int rc = ToUnicodeEx((uint)rgKey[iKey].VK, rgKey[iKey].SC, lpKeyState, sbBuffer, sbBuffer.Capacity, 0, hkl);
                                if(rc > 0) {
                                    if(sbBuffer.Length == 0) {
                                        // Someone defined NULL on the keyboard; let's coddle them
                                        rgKey[iKey].SetShiftState(ss, "\u0000", false, (caps != 0));
                                        rgKey[iKey].SetShiftState(ss, "\u0000", false, (caps == 0));
                                    }
                                    else {
                                        if((rc == 1) &&
                                            (ss == ShiftState.Ctrl || ss == ShiftState.ShftCtrl) &&
                                            ((int)rgKey[iKey].VK == ((uint)sbBuffer[0] + 0x40))) {
                                            // ToUnicodeEx has an internal knowledge about those
                                            // VK_A ~ VK_Z keys to produce the control characters,
                                            // when the conversion rule is not provided in keyboard
                                            // layout files
                                            continue;
                                        }
                                        rgKey[iKey].SetShiftState(ss, sbBuffer.ToString().Substring(0, rc), false, (caps != 0));
                                        rgKey[iKey].SetShiftState(ss, sbBuffer.ToString().Substring(0, rc), false, (caps == 0));
                                    }
                                }
                                else if(rc < 0) {
                                    rgKey[iKey].SetShiftState(ss, sbBuffer.ToString().Substring(0, 1), true, (caps != 0));
                                    rgKey[iKey].SetShiftState(ss, sbBuffer.ToString().Substring(0, 1), true, (caps == 0));

Again, sorry about that!

 

This post brought to you by "Ôž«" (U+29ee, a.k.a. ERROR-BARRED WHITE SQUARE)


# Michael S. Kaplan on 18 Apr 2006 5:55 PM:

Ok, the bug is fixed now in #9b as well.... hopefully no one else will run into problems. :-)

Robbe B on 26 Jul 2010 5:48 PM:

Hi,

You've got me somewhat confused :-)

Is the code in #9b correct (as in, I don't need to make the changes you mentioned above in the post)?

If not, could you explain what the problem actually is?

I understand most of the code, but I don't see why the 4 grey lines in you post are wrong.

Also, is it intentional that in following pasted code, your comment says that 'if the character and the combining are equal, AND it's a CTR or CTRL+SHIFT state, AND a control character is returned', while the actual condition states '(if the character and the combining is equal) OR ((it's a CTR or CTRL+SHIFT state) AND a control character is returned)'?

if ((((ss == ShiftState.Ctrl) || (ss == ShiftState.ShftCtrl)) && (char.IsControl(basechar)))

  || (basechar.Equals(combchar))) {

   // ToUnicodeEx has an internal knowledge about those VK_A ~ VK_Z keys to produce the control characters,

   // when the conversion rule is not provided in keyboard layout files

   // Additionally, dead key state is lost for some of these character combinations, for unknown reasons.

   // Therefore, if the base character and combining are equal, and its a CTRL or CTRL+SHIFT state,

   // and a control character is returned, then we do not add this "dead key" (which is not really a dead key).

   continue;

}

Thanks for the help!

Michael S. Kaplan on 26 Jul 2010 7:53 PM:

The original code was fixed; this blog post points out the changes that were made.


go to newer or older post, or back to index or month or day