On Wed, 26 Feb 2025 18:28:28 GMT, Oliver Schmidtmer <oschmidt...@openjdk.org>
wrote:
>> Windows programs may reuse a clipboard buffer that is larger than the new
>> content. In this case de NUL terminator is not at the end of the buffer, but
>> within it.
>> The current implementation copys the whole buffer into a text field,
>> including the NUL terminator and the remaining chars.
>>
>> The JIRA ticket contains a JNA based sample program, which prefills the
>> buffer for demonstrating this issue.
>> If this should be added as a unit test, I'm open for advice how to do that.
>
> Oliver Schmidtmer has updated the pull request incrementally with one
> additional commit since the last revision:
>
> cleanup
modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 406:
> 404: cdata = 0;
> 405: }
> 406: } else if(CF_TEXT == cf || CF_UNICODETEXT == cf){
Instead of doing that, consider always requesting `CF_UNICODETEXT` from the
clipboard. Windows will then convert both `CF_TEXT` and `CF_OEMTEXT` to unicode
(see [Synthesized Clipboard
Formats](https://learn.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats)).
modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 409:
> 407: for(int i = 0; i < cdata - 1; i+=2){
> 408: jbyte *pos = me.getMem() + offset + i;
> 409: if(*(pos) == 0 && *(pos + 1) == 0){
1. `offset` is always 0 here.
2. Minor: add spacing around operators and after keywords (`for`, `if`).
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1972777624
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1972778132
