Apache OpenOffice (AOO) Bugzilla – Issue 1651
Cut-&-Paste CJK Characters causing soffice unrecoverable error
Last modified: 2013-08-07 15:00:23 UTC
To simulate: 1. Run the Chinese version 2. Select the Chinese name in the "My Computer" icon 3. Cut the Chinese name by pressing Ctrl-C 4. Paste in a OO writer text document by press Ctrl-v. 5. Repeatly doing a Ctrl-V for a few times and an error message saying "soffice causing unrecoverable error in kernel32.dll" appeared.
DL->JP: The bug appears in Writer.
The same problem happens in Calc. It seems something related to clipboard handling.
If it happen in both applications, then I think this may be a platform depended problem from Windows ME; so it is a problem of OBR.
Seems to be a windows only problem. Please have a look at it.
Has this been resolved with the most recent clipboard changes?
Not yet.
Hi, which Operating System do you use Win95/98/ME or Windows NT/2000/XP? Does the problem still exist with the newest OO version? Best Regards, Tino
Hi Wolfram, maybe you want to verify this and close the bug. Best Regards, Tino
Back to you, Tino.
Changed platform, assuming PC is right.
Still happens (unfortunately).
Hi *, I fixed a problem in the Windows clipboard bridge but a problem still remains in the application code (DVO will further investigate it). But be aware of the following problem: If someone copies text into the Windows clipboard he may additionally copy a format CF_LOCALE for specifying the code page of this text. When someone closes the clipboard, if it contains CF_TEXT data but no CF_LOCALE data, the system automatically sets the CF_LOCALE format to the current input language(!). For the current scenario this means, if the input language is english and somebody copies the chinese text of the "My Computer" icon into the clipboard, the system adds the format CF_LOCALE with an english locale to the clipboard. The default code page for this locale is 1252. The Windows clipboard bridge converts the text on the clipboard into unicode text based on the code page 1252. So what will be seen after pasting this text into an OO application is garbage. This problem is not fixable by OO. The Windows desktop simply neglect to provide an appropriate locale when copying text into the clipboard and the Windows clipboard bridge cannot determine that locale and text are not compatible.
If the clipboard data does not include CF_LOCALE informatoin, is it more reasonable to assume the CF_TEXT in the clipboard (for Me/9x) has a locale equivalent to GetOEMCP()? Because using a CJK locale to convert English characters to Unicode will generate less problem. All characters in DBCS code page requires the ASCII value of lead byte greater than 127. Of course, using such an approach will have problem if the CF_TEXT contains some Roman characters with ASCII value > 127. However, the confusing suitation is a instinsic problem of the WinMe/9x platform.
Fixed.
JA: re-prioritized according to new priority guide lines
Have to wait for integration of hdu01 and vcl05 to verify the fix. Regards, Tino
Tino, if you fixed the bug, which is great, I guess you could update the status to resolved fixed, even if you couldn't verify it yet. It's annoying for me to read through many bugs to find out that they are already fixed. Thanks.
Hi Michael, of course can I do this but then I have to reopen the bug later to change the ower etc. or am I wrong?. Nevertheless I will change the state to fixed. Kind Regards, Tino
Reopen
Hi Erik, the issue is fixed. Please be aware that the problem did only occur if the current input language was english instead of chinese. Kind Regards, Tino
Ok in 644m13
closed