ID: 14353 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: COM related Operating System: Windows 2000 PHP Version: 4.2.0 New Comment:
the patch that was made for 4.2.1RC is incomplete - the call to WideCharToMultiByte must have 0 as the second parameter is the codepage is CP_UTF8, but this patch sets it to MB_ERR_INVALID_CHARS instead (submitted to qa.php.net) Previous Comments: ------------------------------------------------------------------------ [2002-04-25 02:38:19] [EMAIL PROTECTED] Fixed in CVS ------------------------------------------------------------------------ [2002-04-23 11:22:25] [EMAIL PROTECTED] This is still an issue in 4.2.0. ------------------------------------------------------------------------ [2001-12-06 12:24:31] [EMAIL PROTECTED] i'll review this ------------------------------------------------------------------------ [2001-12-05 18:18:23] [EMAIL PROTECTED] A call to create a COM object can pass the codepage as the third parameter and CP_UTF8 is a valid option. If you use this, however, the object create fails. The problem is in the php_char_to_OLECHAR and php_OLECHAR_to_char functions in com\conversion.c. MSDN states that a call to WideCharToMultiByte with a codepage of CP_UTF8 must have a second parameter is 0, but these functions don't account for that. How I fixed it (there may be a better way, but it works for me): lines 764 and 760: change "MB_PRECOMPOSED | MB_ERR_INVALID_CHARS" to "codepage == CP_UTF8 ? 0 : MB_PRECOMPOSED | MB_ERR_INVALID_CHARS" lines 784 and 790: change "WC_COMPOSITECHECK" to "codepage == CP_UTF8 ? 0 : WC_COMPOSITECHECK" This fix is not well debugged, but it got me moving forward again. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=14353&edit=1
