в функциях
Text2Clipboard
WText2Clipboard
используется константа GMEM_DDESHARE, а должна быть GMEM_MOVEABLE

также в функциях
Clipboard2Text
Clipboard2WText
зачем то сначала вызывается OpenClipboard, а потом проверяется IsClipboardFormatAvailable
хотя по логике (и "оптимизации" кода), надо сначала проверить наличие формата, а потом уже открывать\закрывать буфер

> Clipboard2Text
> Clipboard2WText

так же
ClipboardHasText
TBitmap.PasteFromClipboard

> ClipboardHasText

в этой функции вообще не надо открывать\закрывать буфер
и она сводится к виду
function ClipboardHasText: Boolean;
begin
 Result := IsClipboardFormatAvailable( CF_TEXT );
end;
т.е. фактически вообще не нужна, если только как затычка из серии "вдруг кто-то пользовался"

> ClipboardHasText

для UNICODE_CTRLS думаю логичен такой вариант
function ClipboardHasText: Boolean;begin  Result := IsClipboardFormatAvailable( CF_UNICODETEXT );end;

при наличии любого управляющего элемента из ComCtl32.dll на форме, например ListView (а по сути после вызова функции InitCommonControls)+ включенного в ресурсы или лежащего рядом файла манифеста
любой Label на форме, при двойном клике мышью, копирует свой текст в буфер обмена!
это нормальное поведение (хотя 99.9% программистов про это не знают) Label , начиная с Windows Vista
возможно, стоит этот момент как то обыграть в KOL, например добавить свойство или директиву компиляции, блокирующую данную "фишку" (Mouse.StopHandling:=True; в обработчике MouseDblClk)

> Text2Clipboard
> WText2Clipboard

также в данных функциях некорректно использовать OpenClipboard с параметром 0 !
0 - это нормально для чтения из буфера, для записи должен быть хэндл окна, хотя бы временно созданного если нет других

вот например в TBitmap.PasteFromClipboard, почему-то стоит хэндл, хотя можно было и 0, а там где нужен хэндл - наоборот 0....

GMEM_DDESHARE позволяет не освобождать дескриптор. В остальном разницы нет.

OpenClipboard делается для того, чтобы между проверкой наличия текста и получением текста\картинки никто не успел в буфер всунуть что-нибудь другое. Если у кого-то ничего плохого не случается, то это не значит, что не случалось ничего плохого у других.

Насчет параметра 0 - читайте MSDN. Использование 0 допускается, в этом случае буфер связывается со всей программой, а не с окном.

> Насчет параметра 0 - читайте MSDN. Использование 0 допускается,
>  в этом случае буфер связывается со всей программой, а не с окном.

так ято какраз и читаю MSDN :)
If an application calls OpenClipboard with hwnd set to NULL, EmptyClipboard sets the clipboard owner to NULL; this causes SetClipboardData to fail.


> GMEM_DDESHARE позволяет не освобождать дескриптор. В остальном  разницы нет.

дык опять же читая MSDN...
The following values are obsolete, but are provided for compatibility with 16-bit Windows. They are ignored.

GMEM_DDESHARE
GMEM_DISCARDABLE
GMEM_LOWER
GMEM_NOCOMPACT
GMEM_NODISCARD
GMEM_NOT_BANKED
GMEM_NOTIFY
GMEM_SHARE


> OpenClipboard делается для того, чтобы между проверкой наличия  текста ...

ок, ток смысл это делать в той же ClipboardHasText ?
когда содержимое может измениться между ее вызовом и например Clipboard2Text :)

> так ято какраз и читаю MSDN :)If an application calls OpenClipboard
> with hwnd set to NULL, EmptyClipboard sets the clipboard
> owner to NULL; this causes SetClipboardData to fail.

Неправильный у Вас MSDN. Вот правильный: https://msdn.microsoft.com/ru-RU/library/windows/desktop/ms649048(v=vs.85).aspx




> The following values are obsolete, but are provided for
> compatibility with 16-bit Windows. They are ignored.GMEM_DDESHARE

Да, ignored. Но ведь provided. А в документации по 16-битному есть, что освобождение не требуется. Экономим код.


> смысл это делать в той же ClipboardHasText ?
Здесь смысла нет, согласен.

> Неправильный у Вас MSDN. Вот правильный

гы :) , ну так надо не только Parameters читать, но и Remarks !

> Да, ignored. Но ведь provided. А в документации по 16-битному
> есть, что освобождение не требуется. Экономим код.

для GMEM_MOVEABLE тоже не требуется :)
а все что "для совместимости", рано или поздно не сработает
и раз выложили ссылку на "правильный" MSDN, то там (именно на этой ссылке\странице) есть еще пунктик Examples, где все наглядно показано

> там (именно на этой ссылке\странице) есть еще пунктик Examples,
>  где все наглядно показано

А еще ниже сообщение от пользователя  
Michele Salvador, который утверждает, что утверждение про fail неверно.




Собственно, сколько раз пользовался Text2Clipboard, фэйлов не бьло. Bitmap2Clipboard открывает с хэндлом окна.

мистер Сальвадор упорот, ибо он не знает (не читает MSDN) что кроме тупого копирования текста в буфер, есть еще отложенный рендер данных в буфер, для которого и нужен хэндл
а посему не надо плодить говнокод по интернетам. копируя друг у друга из серии "работает и ладно"
глянь хотябы релиз в VCL метода опен класса клипборд
procedure TClipboard.Open;
begin
 if FOpenRefCount = 0 then
 begin
   FClipboardWindow := Application.Handle;
   if FClipboardWindow = 0 then
   begin
{$IFDEF MSWINDOWS}
     FClipboardWindow := Classes.AllocateHWnd(MainWndProc);<<<<<<
{$ENDIF}
{$IFDEF LINUX}
     FClipboardWindow := WinUtils.AllocateHWnd(MainWndProc);
{$ENDIF}      
     FAllocated := True;
   end;
   if not OpenClipboard(FClipboardWindow) then
     raise Exception.CreateRes(@SCannotOpenClipboard);
   FEmptied := False;
 end;
 Inc(FOpenRefCount);
end;

Давайте говорить конкретно, и без оскорблений. Где в конкретной процедуре Text2Clipboard отложенный рендеринг?

> Где в конкретной процедуре Text2Clipboard отложенный рендеринг

его и в TBitmap.CopyToClipboard нет, однако хэндл есть и GMEM_MOVEABLE там стоит, а не  GMEM_DDESHARE за который ты так упорно доказывал
сразу видно - скопипастил в  разных местах, как попало, а патом и у тебя скопипастят, так и будет круговерть....

лан забудь и так сойдет