Hello.

Putting a string to a clipboard is done in TClipboard.SetAsText():

  SetBuffer(PredefinedClipboardFormat(pcfText),s[1],length(Value)+1);

Note that there is length(Value)+1, ending zero included. This comes from the following revision:

"r7259 | vincents | 2005-06-21 13:42:35 +0200 (wto) | 2 linie

copy terminating #0 to clipboard too, windows expects it."

But some programs on Linux treat this ending zero as part of the clipboard data. I also checked how a few non-Lazarus programs copy to clipboard and they don't include ending zero. I don't think it is needed.

Can adding trailing zero be moved to the win32 widgetset only?

What programs treat terminator as part of data ?
from qt docs, #0 means eod afair (QMimeData).

clipboard and they don't include ending zero. I don't think it is needed.

We cannot remove it just because you think so. If it's removed we need to test consequences on gtk, gtk2 and qt.

Can adding trailing zero be moved to the win32 widgetset only?

theoretically yes, if it won't disturb others.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120308/648be402/attachment.html>

We cannot remove it just because you think so. If it's removed we need to test consequences on gtk, gtk2 and qt.

Why do you think that an additional #0 should be added, if not required?

DoDi

I didn't say so. I just said that it shuoldn't be removed just like that without testing all widgetsets.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120309/5f04ca66/attachment-0001.html>

2012/3/8 zeljko :

We cannot remove it just because you think so. If it's removed we need to test consequences on gtk, gtk2 and qt.

I know, I was counting on someone saying that it is needed and why.

With copying to clipboard, I found this in LCLQT in TQtClipboard.GetOwnerShip:

      if (QByteArray_length(Data) > 1) and QByteArray_endsWith(Data, #0) then
        QByteArray_chop(Data, 1);

With pasting from clipboard, there is this in LCL:

TClipboard.GetAsText:

      if (ASize>0) and (pchar(MemStream.Memory)[ASize-1]=#0) then
        Dec(ASize);

If the #0 is specifically removed then maybe it doesn't need to be added as well. As I see it, the stream (or array) size determines the length, not the #0.

I can only test by installing lots of applications and testing if copying/pasting still works after removing the #0.

Yeah, just try to copy something from openoffice under X11 and paste it into qt application (or to win32 app running under wine) and you'll see problem (and that comes from gtk2).
My wild guess is that #0 was added because of gtk2. I'll fix qt in any case ... .whatever you put at the end, but who will fix gtk2 or carbon ?

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120309/25dcebed/attachment-0001.html>

2012/3/9 zeljko :

I don't understand what you mean, because for me copying from OpenOffice to native QT app, or to Windows notepad under wine doesn't give any problems. I have GTK 2.24.10, QT 4.7.4, wine 1.1.36.

I have checked 25 programs, copying from them and pasting to Lazarus app, and copying from Lazarus app to them, and there was no difference, whether trailing #0 was added by LCL or not. I tried Lazarus app built with LCLGTK2 and then with LCLQT.

Also none of the programs I checked, except for AbiWord, added trailing zero to the text copied to clipboard. I checked directly with X using XConvertSelection.

Good, then prepare patch and that's it :) My observation about openoffice IS about OpenOffice (not LibreOffice) maybe 2yrs ago, and probably gtk2 < 2.20 or something like that.Also when i said "copy" from OO, I didn't mean copy via Ctrl + C , but via mouse selection and then middle click into eg TEdit or TMemo - that problem existed definitelly.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120309/b6127b48/attachment-0001.html>

2012/3/9 zeljko :

I'll fix qt in any case ... .whatever you put at the end, but who will fix gtk2 or carbon ?

I have never seen this final #0 problem in Carbon

ok, then gtk/gtk2 should be tested.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120310/b57e8ec0/attachment.html>

2012/3/9 zeljko :

Indeed, the problem still exists with OpenOffice and LibreOffice, but this must is a bug in OpenOffice because the selection received from X doesn't match what was selected by mouse. This only happens with PRIMARY clipboard (mouse selection), copying via CLIPBOARD selection (Ctrl+C) doesn't have this problem. The problem also exists when pasting to other non-Lazarus applications; copying from Lazarus app into OpenOffice doesn't show any problems.

I have opened an issue:
http://bugs.freepascal.org/view.php?id=21453

I basically did the same as in LCLQT - make LCLGTK2 remove the trailing zero. Also, conversion to COMPOUND_TEXT already indirectly removed trailing zero.

ok, let's back at beginning ... what problem is caused by trailing null terminator under gtk2 ?

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120310/5654e0d8/attachment.html>

2012/3/10 zeljko :

ok, let's back at beginning ... what problem is caused by trailing null terminator under gtk2 ?

When assigning
  Clipboard.AsText := '1234';

and pasting to some programs (I only experience it with jEdit though), '1234'#0 is pasted, i.e., string of length 5 instead of length 4.

It can be treated as:
a) a bug in LCL; why add #0 when '1234' was assigned, not '1234'#0. If it is required by some widgetset then add trailing zero in the widgetset;
b) a bug in LCLGTK2; regardless of what LCL does, programs in GTK2 (or rather Linux programs, since LCLQT also strips the #0) should not put trailing #0 to the clipboard;
c) a bug in the program that doesn't strip the trailing zero when pasting from clipboard (in this case jEdit).

If there's no problem when you paste it to gedit or to kwrite or to firefox then I'll vote for C). So then new question raises: Shell we fix Jedit bugs by fixing lcl ?

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120310/c66ec1ae/attachment.html>

I see it as: there's no problems when zero is not added, while there is problem when it is added.

Why LCLQT cuts the zero then if adding it causes no problems? Why can't LCLGTK2 cut it as well?

Incidentally I found that I don't need to use Clipboard.AsText, instead I can use this:

Clipboard.Clear;
Clipboard.AddFormat(PredefinedClipboardFormat(pcfText),s[1],length(s));

So, if actually no changes are done, I think that it wouldn't be a problem.

Hy

After compile a lazarus project, the software pass by a windows cmd.

How can y do for no see this window.

Thanks

Il 10/03/2012 22:18, CRAPEZ ha scritto:

Je crains que personne n'a compris votre probl?me. Si vous voulez le poser de nouveau en fran?ais, je peux le traduire en anglais pour le rendre compr?hensible ? ceux qui en connaissent la reponse.

Giuliano

merci

je demandais comment ne pas visualiser la fenetre dos avant l'execution de l'appli sous lazarus

merci
Frederic

Project > Options > Linking

enable "Win 32 Gui applicatian -WG"