Обмен данными в Windows
Просмотр, запись и чтение данных буфера обмена. Динамический обмен данными (DDE), способы его организации. Атомы в Windows, их понятие и функции. Особенности задания параметра lParam сообщений DDE. Обмен и передача данных между клиентом и сервером.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | лекция |
| Язык | русский |
| Дата добавления | 24.06.2009 |
| Размер файла | 303,7 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Поле cfFormat указывает на формат данных, которые клиент ожидает от сервера. Вы можете для одного вида данных в пределах одного DDE-разговора подписаться на получение данных разного типа одновременно, посылая WM_DDE_ADVISE столько раз, сколько форматов данных Вы хотите получать. Однако такая возможность разрешена только для горячей связи. Согласно документации подписка на одни и те-же данные в разных форматах для теплой связи запрещена.
Сервер, при получении сообщения WM_DDE_ADVISE, проверяет возможность осуществить подписку на эти данные, создает необходимые ему структуры данных и отвечает клиенту сообщением WM_DDE_ACK -- положительным или отрицательным. Это сообщение в данном случае используется так-же, как и при ответе на WM_DDE_DATA.
Если подписка осуществлена успешно, то далее сервер начинает извещать клиента об обновлении данных, осуществляя каждый раз пересылку этих данных клиенту с помощью уже рассмотренного сообщения WM_DDE_DATA. Единственное отличие от получения данных в ответ на WM_DDE_REQUEST заключается в том, что бит fResponse структуры DDEDATA равен 0, тогда как при отправке данных по запросу он устанавливается в 1. Это позволяет определить причину получения данных при обработке сообщения.
Заканчивается такой обмен посылкой WM_DDE_UNADVISE серверу. В этом сообщении указывается, от подписки на какие данные клиент отказывается (так как теоретически один клиент может подписаться сразу на несколько видов данных).
WM_DDE_UNADVISE hWnd aItem & cfFormat
Младшее слово параметра lParam описывает формат данных, а старшее слово -- атом, описывающий данные на которые осуществляется подписка. В случае платформы Win32 параметр lParam используется также, как и в случае Windows 3.x. Если параметр cfFormat равен 0, то отменяется подписка на указанные данные для всех тех форматов, для которых была осуществлена подписка. Если параметр aItem равен NULL, то отменяется подписка на все виды данных в пределах данного DDE-разговора. Сервер, обработав это сообщение, должен послать в ответ подтверждение WM_DDE_ACK, положительное или отрицательное; при этом если одна операция отменяет подписку на данные в разных форматах, то посылается только одно подтверждение.
Сообщение WM_DDE_UNADVISE не эквивалентено WM_DDE_TERMINATE, после его обработки отменяется только подписка, а сам DDE-разговор продолжается, так что клиент может установить затем новый вид связи с сервером. Сервер обязан ответить на сообщение WM_DDE_ADVISE положительным или отрицательным подтверждением.
“Теплая” связь -- warm link
Протокол при теплой связи. После инициации обмена клиент посылает запрос WM_DDE_ADVISE, указывая желаемые данные. Сервер отвечает о возможности теплой связи, и, обычно, сразу же посылает WM_DDE_DATA, извещая клиента о возможности немедленного получения данных. Позже сервер посылает WM_DDE_DATA клиенту, когда данные обновляются. Сообщения WM_DDE_DATA в данном случае не передают самих данных, а только извещают клиента о их наличии у сервера. Протоколы связи и используемые сообщения при теплой связи практически полностью совпадают с протоколами и сообщениями горячи связи, поэтому мы просто рассмотрим те немногие отличия, которые есть между двумя этими видами связи.
Как и горячая связь, теплая устанавливается с помощью сообщения WM_DDE_ADVISE с единственным исключением -- бит fDeferUpd структуры DDEADVISE равен 1, а не 0.
Далее сервер начинает информировать клиента об обновлении (или наличии) у него нужных данных. Для этого используется обычное сообщение WM_DDE_DATA, которое в данном случае не передает никаких данных. Для этого параметр hData (младшее слово lParam или, в случае Win32, младшая компонента, извлекаемая с помощью UnpackDDElParam) устанавливается равным 0. Клиент, получая такое сообщение без данных, может немедленно запросить нужные данные или просто запомнить, что данные изменились и позже, при необходимости, получить их.
Заметьте, что в случае горячей связи вы можете подписаться сразу на получение информации об изменении одних и тех-же данных в разных форматах, а в случае теплой связи это запрещено. Такой запрет объясняется тем, что при поддержке таких видов связи для разных данных или одних и тех-же данных, но в разных форматах, клиент должен вести список данных и форматов на которые осуществлена подписка. При получении WM_DDE_DATA, информирующего об изменении данных имя данных задается параметром aItem (упакован в lParam), а формат данных -- полем cfFormat структуры DDEDATA. Однако в случае теплой связи сообщение WM_DDE_DATA не содержит данных и, следовательно, информация о формате данных недоступна, при этом однозначно найти запись в спике не представляется возможным, если только не наложить ограничение -- при теплой связи подписываться можно на данные только в одном формате, тогда запись списка будет однознано определена именем данных.
Для того, что бы получить нужные данные, клиент просто посылает отдельный запрос WM_DDE_REQUEST, как в случае холодной связи. Таким образом теплая связь является “гибридом” двух других видов связи -- холодной и горячей.
Отмена подписки в случае теплой связи ничем не отличается от такого-же действия для горячей связи -- клиент посылает сообщение WM_DDE_UNADVISE серверу, который отвечает на это подтверждением.
Работа с DDE в случае теплой или горячей связи обычно не вызывает значительных сложностей; однако надо обратить внимание на возможность использования нескольких видов связи одновременно. Обычно, при написании приложений используются предположения типа “В ответ на посланное WM_DDE_REQUEST должно прийти либо WM_DDE_DATA, либо WM_DDE_ACK”. Однако в жизни ситуация может оказаться существенно сложнее -- если одно окно использует несколько соединений, то в ответ на посланный WM_DDE_REQUEST сначала может прийти сообщение WM_DDE_DATA, информирующее о получении данных (в случае теплой или горячей связи) и только потом настоящий ответ на WM_DDE_REQUEST. Для того, что бы уменьшить вероятность таких ситуаций, для каждого DDE-разговора создают специальное скрытое окно, взаимодействующее с сервером (или клиентом). Однако при разработке собственных приложений такую возможность все-равно надо учитывать, так как в процедурах обработки сообщений придется проверять, в связи с каким событием получено то или иное сообщение; а при разработке DDE-клиентов надо постараться разделить разные виды обмена данными либо по разным DDE-разговорам, либо по времени.
Передача данных от клиента к серверу
При обмене данными между клиентом и сервером возможно не только получение клиентом данных, содержащихся на сервере, но и возможность передачи некоторых данных от клиента к серверу. Для этого предусмотрено специальное сообщение WM_DDE_POKE, которое посылается клиентом серверу для записи данных.
WM_DDE_POKE hWnd aItem & hData (Packed Win32)
Сообщение WM_DDE_POKE посылается клиентом для передачи данных серверу. В случае платформы Windows 3.x младший компонент параметра lParam содержит хендл передаваемого блока данных, а старший -- атом имени передаваемых данных. Передаваемый блок данных должен быть глобальным и разделяемым и должен начинаться со структуры DDEPOKE. При посылке сообщения WM_DDE_POKE используется следующая стратегия освобождения блока данных: он уничтожается пославшим приложением (клиентом), если:
в заголовке блока бит fRelease равен 0
клиент вернул отрицательный ответ
посылка данных не состоялась
Получившее данные приложение (сервер) будет уничтожать этот блок только если бит fRelease равен 1 и сервер возвращает положительное подтверждение.
typedef struct { WORD unused:13, fRelease:1, // 1 - блок освобождается клиентом fReserved:2; short cfFormat; // формат данных (см. форматы буфера обмена) BYTE Value[1]; // передаваемые данные } DDEPOKE;
Сервер, получивший это сообщение должен сохранить полученные данные и сообщить клиенту о результате выполнения этой операции посылкой сообщения WM_DDE_ACK, положительного или отрицательного. В этом сообщении может быть передан полученный атом имени данных, либо полученный может быть удален, а для посылки подтверждения создан заново.
Выполнение команд DDE
Помимо механизма обмена данными между клиентом и сервером DDE предусматривает еще один способ взаимодействия приложений -- выполнение сервером команд клиента. Для того, что бы указать серверу на необходимость выполнения команды, клиент должен послать специальное сообщение WM_DDE_EXECUTE, в ответ на которое сервер пытается выполнить команду и сообщает клиенту о результате ее выполнения, посылая в ответ сообщение WM_DDE_ACK (положительное или отрицательное).
WM_DDE_EXECUTE hWnd hCmd & 0 (Windows 3.x)
WM_DDE_EXECUTE hWnd hCmd (Win32)
Параметр lParam описывает команду, передаваемую серверу. Для этого строка, содержащая команду, помещается в блок данных, выделяемый с помощью функции GlobalAlloc с флагом GMEM_DDESHARE. В случае платформы Windows 3.x старшее слово параметра lParam содержит хендл этого блока, а младшее -- просто 0; А в случае платформы Win32 параметр lParam непосредственно содержит этот хендл. Освобождение ресурсов: блок данных, содержащий команду, должен быть освобожден клиентом при получении подтверждения от сервера. Вместе с этим подтверждением возвращается хендл этого блока, так что клиент свободно может его освободить.
В случае платформы Win32 строка, содержащая команду может быть представлена UNICODE-строкой, но только в том случае, если оба участвующие в DDE-разговоре окна поддерживают UNICODE, то есть оба возвращают TRUE при вызове функции IsWindowUnicode( hWnd ).
В ответ на сообщение WM_DDE_EXECUTE сервер посылает сообщение WM_DDE_ACK, информирующее о выполнении команды (положительное) или о неудаче (отрицательное). В этом сообщении возвращается хендл блока, содержащего команду, так что сервер может этот блок удалить, а также в параметре wStatus -- в младшем байте -- может быть возвращен дополнительный код, уточняющий результат или причину ошибки (см. описание структуры DDEACK, представляющей параметр wStatus в разделе, посвященном холодной связи).
WM_DDE_ACK hWnd hCmd & wStatus (Packed Win32)
Младший компонент lParam содержит информацию о посылаемом подтверждении. Младший байт этого слова содержит код, возвращаемый приложением, старший байт содержит два значащих бита 0x80 и 0x40. Часто этот параметр представляется в виде структуры DDEACK. Старший компонент lParam представляет собой хендл блока, содержащего команду. Согласно документации этот блок обязательно должен быть освобожден при обработке этого сообщения. В случае платформы Win32 параметр lParam используется для передачи хендла “упакованных” данных.
При разработке собственных DDE-серверов, исполняющих какие-либо команды, надо обратить внимание на формат записи этих команд. Разработчики Microsoft предполагают совершенно определенный формат записи команд, который, к сожалению, часто не поддерживается сторонними разработчиками. Конечно, с точки зрения совместимости, желательно придерживаться этого формата.
В соответствии с документацией Microsoft команда должна представлять собой строку, оканчивающуюся нулевым символом и содержащую одну или несколько команд. Каждая команда должна быть заключена в квадратные скобки […]. Каждая команда состоит из двух частей -- имени команды и, возможно, списка параметров. При этом список параметров заключается в круглые скобки, а параметры в списке разделяются запятыми. Имя команды не может содержать пробелов, скобок, запятых и кавычек; параметры могут содержать эти символы, но в таком случае такой параметр должен быть заключен в кавычки, а символ кавычек в тексте параметра представляется как повторяющаяся кавычка. В прежних версиях DDE -- для Windows 3.x -- требовалось, что бы символы ( ) [ ], встречаемые в тексте параметра (в кавычках) дублировались; в то время как в Win32 это уже не требуется. Проблема, однако, существует -- в среде Win32 могут быть запущены как 16-ти разрядные приложения, так и 32-х разрядные, при этом возможно взаимодействие таких приложений посредством DDE. В такой ситуации серверы должны распознавать оба варианта представления скобок -- как повторяющиеся, так и не повторящиеся.
Примеры для Win32:
[команда] [команда1][команда2][команда_с_параметрами(параметр1,параметр2)][командаN] [команда(параметр1,”параметр2 с пробелами, скобками []() и “” кавычками”)]
В случае Windows 3.x последний пример будет выглядеть так:
[команда(параметр1,”параметр2 с пробелами, скобками [[]](()) и “” кавычками”)]
Если строка содержит несколько заключенных в квадратные скобки команд, то сервер должен разобрать эту строку по командам и обработать их последовательно. Вариант с передачей нескольких команд в одной строке имеет одно неудобство -- возвращается результат выполнения всей последовательности команд, причем понять где возникла ошибка (скажем, синтаксис команды или недостаток свободных ресурсов) будет практически невозможно.
Тема DDE-разговора “System”
Согласно документации Microsoft всем вновь разрабатываемым DDE-серверам рекомендуется поддерживать в каждом сервисе специальную служебную тему DDE-разговора “System”. Эта тема предназначена для получения основной информации о сервере. В пределах этой темы определено несколько стандартных имен данных, к которым можно обратиться для получения требуемой информации.
К сожалению сами разработчики Microsoft не очень строго соблюдают это правило. Так, например, Microsoft Word и Microsoft Excel поддерживают эту тему, а Program Manager, Explorer, Internet Explorer -- не поддерживают. Однако документация остается документацией, поэтому при разработке собственных DDE-серверов стоит придерживаться предлагаемых правил.
При обмене данными с серверами, поддерживающими тему “System” надо придерживаться следующих правил:
для получения данных используется холодная связь
данные предоставляются только в формате CF_TEXT
по многим запрашиваемым данным возвращается список значений. Этот список представлен в виде строки, оканчивающейся нулевым символом, отдельные пункты которой отделяются символом табуляции (код -- 9).
При использовании DDEML имя темы “System” определено в файле DDEML.H как SZDDESYS_TOPIC.
Помимо темы “System” предусмотрен специальное название данных, которые должны поддерживаться во всех остальных темах, с помощью которого можно получить информацию о всех поддерживаемых именах данных в данной теме.
При разработке собственного сервера не обязательно поддерживать все приведенные данные, равно как не обязательно вообще поддерживать тему “System” (хотя это желательно). Если Вы поддерживаете только некоторые данные этой темы, обратите внимание на данные “SysItems”, которые позволяют клиенту узнать, какие именно данные можно запрашивать.
|
Название темы для DDE Название темы для DDEML |
Описание |
|
|
Formats SZDDESYS_ITEM_FORMATS |
Возвращает список поддерживаемых сервером форматов данных. Обычно названия совпадают с названиями форматов буфера обмена, но первые три символа “CF_” опущены. То есть формат CF_BITMAP будет представлен как BITMAP. Рекомендуется так упорядочивать названия форматов в списке, что бы форматы передающие больше информации были первыми. То есть, например, формат DIB должен быть расположен до формата BITMAP. |
|
|
Help SZDDESYS_ITEM_HELP |
Пояснения к использованию данного DDE сервера. Достаточно произвольный текст, желательно поясняющий, какие данные могут быть получены, какие команды могут быть выполнены какие данные могут быть переданы серверу и т.д. |
|
|
ReturnMessage SZDDESYS_ITEM_RTNMSG |
Информация о последнем отправленом подтверждении WM_DDE_ACK. С помощью этого типа данных можно передавать дополнительные данные, уточняющие результат выполнения последней транзакции. |
|
|
Status SZDDESYS_ITEM_STATUS |
В ответ на этот запрос сервер должен отправить строку “Busy” или “Ready”, информирующую о состоянии сервера. Заметьте, что эту строку сервер должен посылать, даже если он занят и не может обрабатывать иные запросы. |
|
|
SysItems SZDDESYS_ITEM_SYSITEMS |
Возвращает список имен данных, которые представлены в теме “System”. Этот список может использоваться клиентом, что бы узнать, какие данные он может запрашивать в рамках темы “System”. |
|
|
Topics SZDDESYS_ITEM_TOPICS |
Возвращает список тем, поддерживаемых сервером в данный момент времени. В процессе работы сервера этот список может изменяться, так, например, Microsoft Word открывает отдельную тему для работы с каждым загруженным документом. |
|
|
TopicItemList SZDDE_ITEM_ITEMLIST |
Аналогично SysItems, возвращает список данных, поддерживаемых для данной темы. Этот запрос может применяться к темам, не являющимися темой “System”. Этот список может изменяться в процессе работы сервера. |
Program Manager в качестве DDE-сервера
Program Manager является специализированным DDE-сервером. Он позволяет запущенным приложениям управлять конфигурацией групп приложений, изменять их атрибуты и т.д. Обычно программы установки приложений используют DDE с Program Manager для создания необходимой группы и наполнения ее элементами. В случае Windows-94 или Windows NT v4.0 и выше Program Manager обычно не используется, но работающий при этом Explorer поддерживает те-же самые сервис, тему и команды, что и Program Manager. При этом вместо групп создаются подменю в меню Пуск|Программы (Start|Programs).
В принципе Windows может быть сконфигурирован так, что вместо Program Manager используется совершенно иная оболочка, которая может не поддерживать описываемый DDE. Возможным выходом из этой ситуации является попытка запуска Program Manager (PROGMAN.EXE), если с первого раза не удается установить DDE-разговор.
Для взаимодействия с Program Manager необходимо установить DDE-разговор с сервером, поддерживающим сервис и тему с одинаковым именем “PROGMAN”, а затем можно передавать необходимые команды (сообщение WM_DDE_EXECUTE). Команды, которые поддерживает Program Manager, позволяют приложению создавать, отображать, удалять и перезагружать группы, добавлять, изменять или удалять элементы групп и завершать работу Program Manager. Для этого предназначены следующие команды:
CreateGroup -- создать группу программ
ShowGroup -- показать группу в указанном состоянии
Reload -- перезагрузить группу из файла
DeleteGroup -- удалить группу
AddItem -- добавить элемент
ReplaceItem -- изменить элемент
DeleteItem -- удалить элемент
ExitProgman -- выйти из Program Manager
Program Manager обрабатывает команды в формате, рекомендованном Microsoft. То есть каждая команда заключается в квадратные скобки, а если она имеет дополнительные параметры, то список параметров заключается в круглые скобки, причем параметры в списке разделены запятыми. В одном запросе к серверу можно указать несколько команд сразу, например:
[ShowGroup(“Accessories”,1)][AddItem(myapp.exe,”My app”,myapp.exe,5)]
Этот пример добавляет элемент “My app” в группу “Accessories”.
Помимо выполнения этих команд Program Manager может выполнять обмен данными с клиентом, благодаря чему возможно получение информации об имеющихся группах и элементах этих групп. Для этого используются те же имена сервиса и темы “PROGMAN”, что и для выполнения команд, но при этом серверу передаются запросы на получение данных по холодной связи в формате CF_TEXT.
Для того, что бы получить список групп, клиент должен прочитать данные с именем “Group”. В ответ Program Manager вернет список групп, разделенный символами перевода строки.
Приложение может запросить у Program Manager информацию о группе. Для этого оно должно прочитать данные с именем, соответствующем имени группы. Возвращается текст из нескольких строк, каждая строка состоит из нескольких компонент, разделяемых запятыми. Первая строка определяет информацию о самой группе, а все последующие -- об элементах группы.
Информация о группе состоит из:
имени группы, заключенного в кавычки
пути к файлу группы (.grp)
число элементов в группе
Информация об элементе группы:
команда, заключенная в кавычки
название каталога
пути к файлу, содержащему пиктограмму
индексу пиктограммы в файле
“горячей клавише” (в числовой форме)
флагу минимизированного состояния при запуске приложения
Примечание: в документации утверждается, что на количество элементов в группе наложено ограничение -- не более 50 элементов на одну группу. Однако существует иное, гораздо более жесткое ограничение -- размер grp-файла под Windows 3.x не может быть больше 64K. Этот размер может быть легко превышен, если используются видео-режимы с большим количеством цветов (Hi-Color или TrueColor), например 16, 24 или 32 бита на пиксел. Дело в том, что grp-файл содержит в себе изображения всех пиктограмм, размер которых увеличивается с увеличением числа цветов. При этом предельный размер grp-файла может быть достигнут после десятка элементов (для TrueColor -- примерно 13 элементов).
Далее более подробно описываются команды, обрабатываемые Program Manager. При этом мы будем придерживаться следующего синтаксиса -- описание самой команды в квадратные скобки не заключается, а необязательные параметры выделяются с их помощью. Для лучшей читаемости параметры разделяются дополнительным пробелом (при передачи команды этих пробелов быть не должно).
Рекомендуется дополнительно просмотреть раздел “Выполнение команд DDE” для получения справок о синтаксисе записи команд и параметров.
CreateGroup( GroupName [,CommonGroupFlag] ) CreateGroup( GroupName [,GroupFile] )
Команда CreateGroup создает указанную группу, либо делает активной уже существующую.
Параметры:
GroupName строка, задающая имя группы.
CommonGroupFlag параметр указывает, какая группа создается. Если он равен 1, то создается общая группа, а если 0, то персональная. Если работающий пользователь не имеет административных привилегий, то попытка создать общую группу не удастся. По умолчанию используется 1 для пользователей, располагающих привилегиями администратора, и 0 для остальных пользователей.
GroupFile в Windows 3.1 этот параметр задавал имя grp-файла. В старших версиях Windows в качестве второго параметра рассматриваются только 0 и 1, иначе этот параметр игнорируется.
ShowGroup( GroupName, ShowCommand [,CommonGroupFlag] )
Команда ShowGroup позволяет показать группу в нормальном, максимизированном или минимизированном виде.
Параметры:
GroupName строка, задающая имя группы.
ShowCommand целое число, указывающее, в каком виде надо отобразить окно группы.
1 -- отобразить активным в нормальном состоянии
2 -- отобразить активным в минимизированном состоянии
3 -- отобразить активным в максимизированном состоянии
4 -- отобразить окно группы в нормальном состоянии; активное окно останется активным
5 -- делает окно группы активным, не изменяя ее размера и положения
6 -- минимизирует окно группы
7 -- минимизирует окно группы; активное окно останется активным
8 -- отображает в текущем состоянии
CommonGroupFlag параметр указывает, какая группа создается. Если он равен 1, то создается общая группа, а если 0, то персональная. Если работающий пользователь не имеет административных привилегий, то попытка создать общую группу не удастся. По умолчанию используется 1 для пользователей, располагающих привилегиями администратора, и 0 для остальных пользователей.
Reload( GroupName [,CommonGroupFlag] )
Эта команда заставляет Program Manager удалить описание группы из памяти и загрузить grp-файл снова. Такая возможность может применяться, если программа модифицирует непосредственно grp-файл, а затем хочет отобразить сделанные изменения.
Параметры:
GroupName строка, задающая имя группы.
CommonGroupFlag параметр указывает, какая группа создается. Если он равен 1, то создается общая группа, а если 0, то персональная. Если работающий пользователь не имеет административных привилегий, то попытка создать общую группу не удастся. По умолчанию используется 1 для пользователей, располагающих привилегиями администратора, и 0 для остальных пользователей.
DeleteGroup( GroupName [,CommonGroupFlag] ) DeleteGroup( GroupName [,GroupFile] )
Команда DeleteGroup удаляет указанную группу.
Параметры:
GroupName строка, задающая имя группы.
CommonGroupFlag параметр указывает, какая группа создается. Если он равен 1, то создается общая группа, а если 0, то персональная. Если работающий пользователь не имеет административных привилегий, то попытка создать общую группу не удастся. По умолчанию используется 1 для пользователей, располагающих привилегиями администратора, и 0 для остальных пользователей.
GroupFile в Windows 3.1 этот параметр задавал имя grp-файла. В старших версиях Windows в качестве второго параметра рассматриваются только 0 и 1, иначе этот параметр игнорируется.
AddItem( CmdLine [,Name [,IconPath [,IconIndex [,xPos, yPos [,DefDir [,HotKey [,fMinimize [fSeparateMemSpace] ] ] ] ] ] ] )
Команда AddItem позволяет добавить в активную группу программный элемент.
Параметры:
CmdLine строка, задающая команду, осуществляющую запуск приложения. Эта строка должна содержать имя приложения, а также может содержать полный путь к приложению и другие необходимые параметры.
Name задает имя элемента в группе. Если этот параметр опущен, то используется имя приложения.
IconPath задает полное имя файла, содержащего ресурс пиктограммы, которая будет отображаться в окне группы. Это может быть выполняемый файл Windows (.exe, .dll) или отдельная пиктограмма (.ico). Если этот параметр опущен, то пиктограмма ищется в файле приложения, причем, если указанный файл не является приложеним, то используется пиктограмма ассоциированного с данным типом файлов приложения (ассоциации задаются с помощью реестра Windows); а если и это не удается, то используется пиктограмма по умолчанию.
IconIndex задает индекс пиктограммы в файле, определенном параметром IconPath.
xPos, yPos задают положение пиктограммы в окне группы. Эти параметры представлены целыми числами. Если позиция не задана, то Program Manager находит первое неиспользуемое место.
DefDir задает имя рабочего каталога приложения.
HotKey задает “горячую” клавишу, используемую для вызова приложения.
fMinimize указывает, надо-ли отображать окно приложения при запуске в виде пиктограммы.
fSeparateMemSpace указывает, надо-ли запускать 16-ти разрядное приложение в самостоятельном адресном пространстве (используется на некоторых платформах Win32).
ReplaceItem( ItemName )
Команда ReplaceItem используется для замены одного элемента другим. При выполнении этой команды указанный элемент удаляется, а его позиция запоминается. Последующий вызов AddItem создаст новый элемент в этом месте.
Параметры:
ItemName строка, задающая имя удаляемого элемента. На его месте будет размещен следующий создаваемый элемент.
DeleteItem( ItemName )
Команда DeleteItem осуществляет удаление указанного программного элемента.
Параметры:
ItemName строка, задающая имя удаляемого элемента.
ExitProgman( bSaveGroups )
Эта команда завершает работу Program Manager.
Параметры:
bSaveGroups величина, указывающая надо или нет сохранять текущее состояние групп перед завершением работы Program Manager. При значении 0 сохранения групп не происходит.
Подобные документы
Назначение буфера обмена, управление его данными в среде Windows. Взаимодействие между владельцем и клиентом буфера. Данные и тип дескриптора, для каждого типа предопределенных форматов. Воспроизведение данных буфера обмена с задержкой, окна просмотра.
реферат [58,9 K], добавлен 04.10.2010Характеристика буфера обмена как области памяти, резервируемой системой Windows для организации обмена данными между приложениями. Копирование и перемещение файлов как функции буфера обмена. Изучение абсолютной и относительной адресации ячеек MS Excel.
контрольная работа [13,9 K], добавлен 11.09.2011Изучение процесса обмена данными между приложениями в среде MS Office, используя при этом разные форматы хранения и представления информации. Создание файла исходных данных формата CSV по шаблону. Выполнение тестов, расчетов с исходным набором данных.
курсовая работа [3,4 M], добавлен 27.01.2015Обмен данными между различными программами. Способы передачи сообщений и обработки ошибок в сети. Обмен данными между маршрутизаторами. Основное преимущество LonWorks. Практика применения протоколов BAC-NET, LONWORKS и KNX в странах Европы и России.
курсовая работа [76,7 K], добавлен 07.05.2013Прикладные решения для российских организаций на платформе "1С:Предприятие 8". Особенности обмена данными с помощью XML-файлов между "1С" и "ST-Мобильная Торговля". Создание плана обмена, предназначенного для регистрации измененной цены в номенклатуре.
дипломная работа [1,9 M], добавлен 27.03.2015Архитектуры удаленных баз данных. Локальная вычислительная сеть - это группа компьютеров, которые соединены между собой при помощи специальной аппаратуры, обеспечивающей обмен данными. Разделение и передача файлов. Разделение прикладных программ.
лекция [404,1 K], добавлен 30.03.2009Определение буфера обмена, его расположение, правила работы, форматы хранимых данных. WIN API функции, используемые в данном проекте. Модульная структура программы, краткое описание подпрограмм и их назначение, причины использования многопоточности.
курсовая работа [872,5 K], добавлен 24.06.2011Разработка структуры базы данных. Этапы разработки информационной системы. Моделирование сигналов в MatLab. Обмен данными в SQL-сервером. Генерация схемы базы данных для целевой СУБД. Редактирование параметров таблицы. Установка параметров генерации.
курсовая работа [5,3 M], добавлен 01.02.2013Службы и компоненты SQL Server 2000, архитектура его вычислительной среды, системы безопасности, средства репликации и администрирования, сетевые библиотеки. Обмен данными между клиентом и сервером. Реляционное ядро, физическая и логическая структура БД.
презентация [103,3 K], добавлен 10.11.2013Обмен данными между приложениями Word и Excel в MS Office как основа их интеграции. Основные способы обмена данными между программами в MS Office. Связывание и внедрение объектов. Сравнительный анализ основных способов. Простое (статическое) копирование.
методичка [599,5 K], добавлен 10.11.2013
