Буфер обмена

БУФЕР ОБМЕНА

Введение

Одна из задач программиста Windows-приложений состоит в создании продуктов, которые настолько подобны другим программам Windows, что пользователь сможет легко переключаться между ними, не ощущая различий в их поведении и внешнем виде. В идеале пользователь должен воспринимать однородную среду и не замечать разграничений между программами. В такой среде сама собой напрашивается возможность переноса данных между приложениями.

Буфер обмена (clipboard) Windows обеспечивает простой обмен данными между приложениями.

Содержимое буфера обмена в любой момент времени представляет собой набор объектов в памяти, созданных программой, которая поместила данные в буфер обмена. Функции API и сообщения, реализующие буфер обмена, управляют его содержимым. Буфер обмена служит единственным протоколом доступа к хранимым данным.

1. Форматы буфера обмена

Приложения могут обрабатывать одни и те же данные по-разному. Например, текст может представлять собой простые символы, сгенерированные эмулятором терминала, либо результат применения современного полнофункционального текстового процессора. Данные, импортируемые любой программой из буфера обмена, необходимо представлять в наилучшем из возможных форматов. С этой целью приложения, попадающие данные в буфер обмена, экспортируют их как можно большим числом способов.

В результате при считывании из буфера обмена клиенту предоставляется набор опций. Различные способы представления данных в буфере обмена называются форматами буфера обмена.

Когда приложение использует функцию SetClipboardData() для помещения данных в буфер обмена в определенном формате, принято говорить, что приложение воспроизводит этот формат. Вообще говоря, чем больше форматов буфера обмена поддерживается приложением, тем точнее оно осуществляется обмен данными с другими Windows-приложениями. Поэтому имеет смысл воспроизводить как можно большее число форматов буфера обмена.

Приложение, которое очищает буфер обмена через функцию EmptyClipboard(), а затем помещает в него данные любого формата с использованием функции SetClipboardData(), называется владельцем буфера обмена (clipboardowner). (Термин не совсем точен, поскольку после помещения данных в буфер обмена они более не принадлежат владельцу. Эти данные принадлежат среде Windows.)

Другие приложения, извлекающие данные, называются клиентами буфера обмена (clipboardreaders). Извлечение данных из буфера обмена не делает клиента его владельцем.

Программа Windows, единственной целью которой является просмотр содержимого буфера обмена, называется окном просмотра буфера обмена (clipboardviewer).

Для каждого формата буфера обмена, поддерживаемого приложением, должен выполняться отдельный вызов функции SetClipboardData(). Данные, записываемые в буфер обмена в результате каждого вызова, только замещают данные, хранимые в буфере обмена для данного формата. По этой причине перед помещением новых данных в буфер обмена, программа должна вызвать функцию EmptyClipboard(), чтобы очистить все хранимые форматы от неподходящих данных. В противном случае эти данные могу быть ошибочно сохранены. Вызов функции EmptyClipboard() также позволяет старому владельцу буфера обмена очистить все области памяти, выделенные определенным форматам, путем обработки сообщения WM_DESTROYCLIPBOARD.

Клиент буфера обмена может поддерживать и другие форматы, но для вставки данных ему более всего подходит формат CF_TEXT.

В табл.1 перечислены некоторые предопределенные форматы и описаны данные, а также тип дескриптора, передаваемого функции SetClipBoardData() для каждого типа. Наиболее распространенным типом записей буфера обмена является глобальный блок памяти, выделенный с опцией GMEM_DDESHARE. Для него в таблице применяется простое обозначение HANDLE. Постоянные значения форматов буфера обмена описаны в файле заголовков winuser.h вместе с прототипами функций API, которые определяют интерфейс буфера обмена.

Таблица 1

Предопределенные форматы буфера обмена

2. Управление данными буфера обмена в среде Windows

Система Windows управляет содержимым и форматами буфера обмена. Windows сохраняет данные для каждого формата отдельно таким образом, что помещение данных в один формат не затрагивает данные, записанные в другом формате. Кроме того Windows управляет удалением данных, помещенных в буфер обмена. Данные, хранимые в буфере обмена для данного формата, должны удаляться при сохранении в формате новых данных, а также при вызове функции EmptyClipboard() для очистки всего содержимого буфера обмена.

Windows удаляет элементы данных буфера обмена путем вызова специальной функции удаления. Выбор функции зависит от типа данных, хранимых в формате буфера обмена.

Например, для объектов GDIWindows использует функцию DeleteObject(), для объектов памяти применяется функция GlobalFree() и т.д.

Исключением из этих правил служат приватные форматы буфера обмена. Как будет показано, Windows не управляет данными, хранимыми в упомянутых форматах буфера обмена. Фактически, управлять .хранимыми в приватных форматах данными должны программы, которые эти форматы создают.

3. Воспроизведение данных буфера обмена с задержкой

Обработка большого количества форматов данных буфера обмена сопряжена с затратами времени, в особенности, если приложение поддерживает графические форматы, такие как bitmap-изображения или метафайлы. Управление GDI-объектами требует больших затрат времени и памяти. Не имеет смысла обрабатывать или хранить данные, если их формат вообще не используется.

К счастью, API-интерфейсы Win32 предоставляют простой метод задержки помещения данных в буфер обмена, пока не будет сгенерирован запрос на извлечение данных в определенном формате. Это называется воспроизведением с задержкой (delayedrendering). Для его задействования достаточно передать значение NULL в качестве дескриптора типа HANDLEна данные буфера обмена при установке данных с помощью функции SetClipboardData(). Если приложение требует воспроизведения формата, отправляется сообщение WM_RENDERFORMATс переменной wParam, чтобы указать запрашиваемый формат.

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

Тем не менее, обычно воспроизведение с задержкой считается наилучшим подходом в случае поддержки большого количества форматов, либо та отсутствии времени на помещение данных в буфер обмена. Помните, часто бывает, что данные вырезаются или копируются, но не вставляются.

Примером воспроизведения с задержкой служат функции ClipboardFormatAvailable() и GetPriorityClipboardFormat().

Формат CF_OWNERDISPLAY

Уникальный формат буфера обмена CF_OWNERDISPLAYвозлагает функции отображения данных буфера обмена на его владельца. Владелец буфера обмене принимает набор сообщений, описывающих изменения клиентской области в окне просмотра буфера обмена. Эти сообщения сведены в табл.2.

Одним из наглядных примеров формата CF_OWNERDISPLAYслужит утилита Clipbook — окно просмотра буфера обмена Windows, которое распознает, казалось бы неограниченное количество форматов. На самом деле Clipbook предоставляет свою клиентскую область владельцу данных буфера обмена, который, конечно же, способен отображать содержимое так же, как и в исходном документе. Единственное отличие для владельца буфера обмена составляет окно, где должны выводиться данные. Однако это не вносит изменений в логику программы.

Таблица 2

Сообщения, принимаемые владельцем буфера обмена для отображения данных

Формат буфера обмена CF_OWNERDISPLAYобеспечивает наивысшую степень разнообразия всех форматов поскольку за их отображение отвечает источник данных. Если приложение поддерживает необычный формат буфера обмена (например, приватный или зарегистрированный), существует только две возможности отображения данных вне приложения:

- отображение владельцем;

- написание окна просмотра буфера обмена.

4. Окна просмотра буфера обмена

Окно просмотра буфера обмена представляет собой программу, предназначенную для просмотра содержимого буфера обмена. Обычно окна просмотра поддерживают множество форматов, но не могут правильно интерпретировать приватные зарегистрированные форматы. В этой связи может потребоваться создать окно просмотра буфера обмена самостоятельно.

Следует учитывать, что окно просмотра буфера обмена не владеет данными, которыми управляет. Требования к окну просмотра:

1. Окно просмотра ни в коем случае не должно выполнять запись в содержимое буфера обмена.

2. Окно просмотра никогда не должно оставлять какой-либо элемент содержимого буфера обмена заблокированным.

3. Поскольку в любой момент времени могут выполняться несколько окон просмотра и сообщения передаются между ними посредством связанного списка окон просмотра, создаваемая программа должна отвечать следующим соглашениям:

- Сохранять значение возврата функции SetClipboardViewer(), которое указывает на следующее окно просмотра буфера обмена в цепочке. Windows помещает новые окно просмотра перед уже установленными.

- Передавать сообщения WM_DRAWCLIPBOARD следующему окну просмотра в цепочке. В противном случае остальные окна просмотра не будут обновляться.

- Передавать сообщения WM_CHANGECBCHAINследующему окну просмотра в цепочке. В противном случае цепочка окон просмотра будет прервана.

- Отслеживать сообщения WM_CHANGECBCHAINдля удаления следующего окна цепочки. Параметр IParamсодержит новый дескриптор следующего окна в случае удаления следующего, окна просмотра.

- Для удаления окна просмотра из цепочки следует вызвать функцию ChangeClipboardChain() с использованием сохраненного значения следующего окна.