On Fri, 28 Mar 2025 15:10:46 GMT, Oliver Schmidtmer
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 tex
> 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.
On Mon, 31 Mar 2025 17:48:50 GMT, Oliver Schmidtmer
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 tex
On Mon, 31 Mar 2025 17:48:50 GMT, Oliver Schmidtmer
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 tex
On Mon, 31 Mar 2025 17:48:50 GMT, Oliver Schmidtmer
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 tex
> 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.
On Thu, 27 Mar 2025 13:14:27 GMT, Oliver Schmidtmer
wrote:
>> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line
>> 207:
>>
>>> 205: {
>>> 206: addPair(GLASS_TEXT_PLAIN, CF_UNICODETEXT);
>>> 207: addPair(GLASS_TEXT_PLAIN_LOCALE, CF_UNICODETEXT);
>>
>> Seems like
On Thu, 27 Mar 2025 10:06:02 GMT, Lukasz Kostyra wrote:
>> Oliver Schmidtmer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> readding flavors with changed mapping
>
> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp l
On Wed, 26 Mar 2025 20:20:36 GMT, Oliver Schmidtmer
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 tex
> 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.
On Tue, 25 Mar 2025 18:39:08 GMT, Oliver Schmidtmer
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 tex
> 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.
On Tue, 25 Mar 2025 09:53:10 GMT, Lukasz Kostyra wrote:
>> As @mstr2 said, I think the data is always converted to CF_UNICODETEXT. If
>> it wasn't there should have been more visible problems, as the current code
>> always assumes wide chars.
>>
>> So I just need to know how much we should cha
On Tue, 25 Mar 2025 09:36:46 GMT, Oliver Schmidtmer
wrote:
>> Could be, but in any case, the way it's impemented right now doesn't seem to
>> be right. We should only assume 2-byte characters if what's being pulled
>> from the clipboard is actually `CF_UNICODETEXT`.
>
> As @mstr2 said, I think
On Fri, 28 Feb 2025 16:48:39 GMT, Michael Strauß wrote:
>> As the existing code was already pretty optimistic about 2 byte chars, is it
>> possible that is already handled somewhere else?
>> I'm not sure whether this is done explicitly somewhere or if CF_UNICODETEXT
>> is just tried first.
>
>
On Fri, 28 Feb 2025 16:48:39 GMT, Michael Strauß wrote:
>> As the existing code was already pretty optimistic about 2 byte chars, is it
>> possible that is already handled somewhere else?
>> I'm not sure whether this is done explicitly somewhere or if CF_UNICODETEXT
>> is just tried first.
>
>
On Thu, 27 Feb 2025 09:59:04 GMT, Oliver Schmidtmer
wrote:
>> 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 doi
On Thu, 27 Feb 2025 03:40:47 GMT, Michael Strauß wrote:
>> 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:
> 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.
On Wed, 26 Feb 2025 18:28:28 GMT, Oliver Schmidtmer
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 tex
> 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.
> 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.
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Wed, 26 Feb 2025 13:22:16 GMT, Kevin Rushforth wrote:
> I can't reproduce the original bug on Windows 11.
Actually, I didn't run the test correctly earlier. I can reproduce it locally,
so I'll be able to verify the fix (once we resolve the outstanding questions).
-
PR Comment:
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Tue, 25 Feb 2025 15:21:22 GMT, Oliver Schmidtmer
wrote:
>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java
>> line 258:
>>
>>> 256: int nullTerm = data.length - 2;
>>> 257: for (int i = 0; i < data.length; i += 2) {
On Tue, 25 Feb 2025 14:36:59 GMT, Kevin Rushforth wrote:
>> Oliver Schmidtmer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> check both UTF16 bytes
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java
>
> 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.
On Tue, 25 Feb 2025 14:36:38 GMT, Kevin Rushforth 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 f
On Tue, 25 Feb 2025 13:25:07 GMT, Oliver Schmidtmer
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 fi
On Tue, 25 Feb 2025 13:25:07 GMT, Oliver Schmidtmer
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 fi
34 matches
Mail list logo
