Byeong-Sik Jeon wrote:
Bill Medland wrote:
On Thu, 2007-05-04 at 06:17 +0900, Byeong-Sik Jeon wrote:
Without UNICODE, sizeof(TCHAR) == 1. This is no effect. CJK multibyte character is 2 byte size.
Yes, but you are getting confused by the term 'character'. It is being used in two different senses. You are using the wrong method to solve the problem. You are fixing it where it is not broken; it is (probably) broken somewhere else.
AFAIK The value returned by RegQueryInfoKey is (supposed to be) the number of TCHARS required to hold the name. MSDN means TCHARS when it says 'character' for this function. It does not matter that it actually requires two (char) TCHARS to hold a (language) character. After all in UTF-8 it could require even more than two.
example: string "새 값 #1" has 6 characters. It is max_val_name_len. w/ UNICODE, this string is 6 * sizeof(WCHAR) bytes. w/o UNICODE, this string is 8 bytes. 8 == space(1) * 2 + #(1) + 1(1) + 새(2) + 값(2)
Currently regedit compiled without UNICODE. RegQueryInfoKey result: max_val_name_len ===> 6; max_val_name_len++ ===> 7 max_val_name_len * sizeof(TCHAR) ==> 7 * 1 This is bad result. we need 9 or more.
So what you have to investigate is why RegQueryInfoKey is returning a number that is too small. It should return the number of TCHARS, not the number of language characters (I believe)
- MSDN means TCHARS when it says 'character' for this function. ==> No.
- why RegQueryInfoKey is returning a number that is too small ==> No. Currently RegQueryInfoKey returns the right values.
I'm sorry. I'm not yet test the MS-Windows's RegQueryInfoKey function.
I'm sorry again. Thank you.