Буфер обмена (стр. 1 из 2)
БУФЕР ОБМЕНА
Введение
Одна из задач программиста Windows-приложений состоит в создании продуктов, которые настолько подобны другим программам Windows, что пользователь сможет легко переключаться между ними, не ощущая различий в их поведении и внешнем виде. В идеале пользователь должен воспринимать однородную среду и не замечать разграничений между программами. В такой среде сама собой напрашивается возможность переноса данных между приложениями.
Буфер обмена (clipboard) Windows обеспечивает простой обмен данными между приложениями.
Содержимое буфера обмена в любой момент времени представляет собой набор объектов в памяти, созданных программой, которая поместила данные в буфер обмена. Функции API и сообщения, реализующие буфер обмена, управляют его содержимым. Буфер обмена служит единственным протоколом доступа к хранимым данным.
1. Форматы буфера обмена
Приложения могут обрабатывать одни и те же данные по-разному. Например, текст может представлять собой простые символы, сгенерированные эмулятором терминала, либо результат применения современного полнофункционального текстового процессора. Данные, импортируемые любой программой из буфера обмена, необходимо представлять в наилучшем из возможных форматов. С этой целью приложения, попадающие данные в буфер обмена, экспортируют их как можно большим числом способов.
В результате при считывании из буфера обмена клиенту предоставляется набор опций. Различные способы представления данных в буфере обмена называются форматами буфера обмена.
Когда приложение использует функцию SetClipboardData() для помещения данных в буфер обмена в определенном формате, принято говорить, что приложение воспроизводит этот формат. Вообще говоря, чем больше форматов буфера обмена поддерживается приложением, тем точнее оно осуществляется обмен данными с другими Windows-приложениями. Поэтому имеет смысл воспроизводить как можно большее число форматов буфера обмена.
Приложение, которое очищает буфер обмена через функцию EmptyClipboard(), а затем помещает в него данные любого формата с использованием функции SetClipboardData(), называется владельцем буфера обмена (clipboardowner). (Термин не совсем точен, поскольку после помещения данных в буфер обмена они более не принадлежат владельцу. Эти данные принадлежат среде Windows.)
Другие приложения, извлекающие данные, называются клиентами буфера обмена (clipboardreaders). Извлечение данных из буфера обмена не делает клиента его владельцем.
Программа Windows, единственной целью которой является просмотр содержимого буфера обмена, называется окном просмотра буфера обмена (clipboardviewer).
Для каждого формата буфера обмена, поддерживаемого приложением, должен выполняться отдельный вызов функции SetClipboardData(). Данные, записываемые в буфер обмена в результате каждого вызова, только замещают данные, хранимые в буфере обмена для данного формата. По этой причине перед помещением новых данных в буфер обмена, программа должна вызвать функцию EmptyClipboard(), чтобы очистить все хранимые форматы от неподходящих данных. В противном случае эти данные могу быть ошибочно сохранены. Вызов функции EmptyClipboard() также позволяет старому владельцу буфера обмена очистить все области памяти, выделенные определенным форматам, путем обработки сообщения WM_DESTROYCLIPBOARD.
 |
На рис.1 показано взаимодействие между владельцем и клиентом буфера обмена. Обратите внимание, что клиент выбрал просмотр данных в формате CF_TEXT, хотя владелец воспроизводит не менее трех текстовых форматов, включая GF_TEXT, CF_OEMTEXT и CF_UNICODETEXT.
Клиент буфера обмена может поддерживать и другие форматы, но для вставки данных ему более всего подходит формат CF_TEXT.
В табл.1 перечислены некоторые предопределенные форматы и описаны данные, а также тип дескриптора, передаваемого функции SetClipBoardData() для каждого типа. Наиболее распространенным типом записей буфера обмена является глобальный блок памяти, выделенный с опцией GMEM_DDESHARE. Для него в таблице применяется простое обозначение HANDLE. Постоянные значения форматов буфера обмена описаны в файле заголовков winuser.h вместе с прототипами функций API, которые определяют интерфейс буфера обмена.
Таблица 1
Предопределенные форматы буфера обмена
| Формат буфера обмена | Тип дескриптора | Описание данных |
| CF_BITMAP | HBITMAP | Данные представляют собой набор битов. |
| CF_DSPENHMETAFILE | HENHMETAFILE | Расширенный метафайл, приватный для приложения. |
| CF_DSPMETAFILEPICT | HANDLE | Объект памяти, содержащий структуру METAFILEPICT, которая является приватной для приложения. |
| CF_DSPTEXT | HANDLE | Приватный для приложения текст. |
| CF_DSPBITMAP | НВIТМАР | Растровое изображение, которое является приватным для приложения. Этот формат может использоваться, например, для передачи данных между различными экземплярами одного и того же приложения. Для определения владельца буфера обмена следует использовать функцию GetClipboardOwner(). |
| CF_ENHMETAFILE | HENHMETAFILE | Расширенный метафайл. |
| CF_GDIOBJFIRST | HGDIOBJ | Описанные приложением форматы сквозного буфера обмена (throughclipboard), представленные объектами GDI (GraphicDeviceInterface — интерфейсом графических устройств). При вызове функции EmptyClipboard() для уничтожения данных этого формата используется функция DeleteObject(). |
| CF_METFILEPICT | HANDLE | Объект памяти, содержащий структуру METAFILEPICT. |
| CF_OEMTEXT | HANDLE | Объект памяти, который содержит завершаемую нулем строку символов набора OEM. Строки разделяются последовательностью символов возврата каретки и перевода строки (CR/LF). |
| CF_OWNERDISPLAY | NULL | Указывает, что владелец буфера обмена будет отвечать за отображение данных, а также обновляет окна просмотре буфер обмена. Окно просмотра буфера обмена отправляет владельцу сообщения WM_ASKCBFORMATNAME, WM_PAINTCLIPBOARD, WM_HSCROLLCLIPBOARD, WM_SIZECLIPBOARD и WM_VSCROLLCLIPBOARD. |
| от CF_PRIVATEFIRST до CF_PRIVATELAST | Этот диапазон обозначает приватные форматы буфера обмена. Windows не управляет этими форматами. Владелец буфера обмена должен управлять ресурсам» через сообщение WM_DESTROYCLBOARD. | |
| CF_RBIFF | HANDLE | Сложная поддержка звуковых данных. Превосходит по сложности поддержку CF_WAVE. |
| CF_TEXT | HANDLE | Объект памяти, содержащий строку символов, завершаемую нулем. Строки разграничиваются последовательностью символов возврата каретки и перевода строки (CR/LF). |
| CF_TIFF | HANDLE | Формат дескриптора файла изображения. |
| CF_UNCODETEXT | HANDLE | Объект памяти, содержащий завершаемую нулем строку в формате многобайтного глобального кода символов Unicode. |
| CF_WAVE | HANDLE | Стандартная поддержка Wave-файлов. |
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 предоставляет свою клиентскую область владельцу данных буфера обмена, который, конечно же, способен отображать содержимое так же, как и в исходном документе. Единственное отличие для владельца буфера обмена составляет окно, где должны выводиться данные. Однако это не вносит изменений в логику программы.