| |||
| БЕСПЛАТНАЯ ежедневная online лотерея! Выигрывай каждый день БЕСПЛАТНО! | |||
| |||
Synchronous and Asynchronous TransactionsA client can send either synchronous or asynchronous transactions. In a synchronous transaction, the client specifies a time-out value that indicates the maximum amount of time it will wait for the server to process the transaction. DdeClientTransaction does not return until the server processes the transaction, the transaction fails, or the time-out value expires. The client specifies the time-out value when it calls DdeClientTransaction. During a synchronous transaction, the client enters a modal loop while waiting for the transaction to be processed. The client can still process user input but cannot send another synchronous transaction until DdeClientTransaction returns. A client sends an asynchronous transaction by specifying the TIMEOUT_ASYNC flag in DdeClientTransaction. The function returns after the transaction has begun, passing a transaction identifier to the client. When the server finishes processing the asynchronous transaction, the DDEML sends an XTYP_XACT_COMPLETE transaction to the client. One of the parameters that the DDEML passes to the client during the XTYP_XACT_COMPLETE transaction is the transaction identifier. By comparing this transaction identifier with the identifier returned by DdeClientTransaction, the client identifies which asynchronous transaction the server has finished processing. A client can use the DdeSetUserHandle function as an aid in processing an asynchronous transaction. This function makes it possible for a client to associate an application-defined doubleword value with a conversation handle and a transaction identifier. The client can use the DdeQueryConvInfo function during the XTYP_XACT_COMPLETE transaction to obtain the application-defined doubleword value. Because of this function, an application need not maintain a list of active transaction identifiers. When a client successfully completes a request for data using a synchronous transaction, the DDEML has no way to tell when the client has finished using the data received. The client application must pass the data handle received to the DdeFreeDataHandle function, notifying the DDEML that the handle will no longer be used. Data handles returned by synchronous transactions are effectively owned by the client. If a server does not process an asynchronous transaction in a timely manner, the client can abandon the transaction by calling the DdeAbandonTransaction function. The DDEML releases all resources associated with the transaction and discards the results of the transaction when the server finishes processing it. A time-out during a synchronous transaction effectively cancels the transaction. The asynchronous transaction method is provided for applications that must send a high volume of DDE transactions while simultaneously performing a substantial amount of processing, such as performing calculations. The asynchronous method is also useful in applications that must stop processing DDE transactions temporarily so they can complete other tasks without interruption. In most other situations, an application should use the synchronous method. Synchronous transactions are simpler to maintain and are faster than asynchronous transactions. However, only one synchronous transaction can be performed at a time, whereas many asynchronous transactions can be performed simultaneously. With synchronous transactions, a slow server can cause a client to remain idle while it is waiting for a response. Also, synchronous transactions cause the client to enter a modal loop that could bypass message filtering in the application's own message loop. If the client has installed a hook procedure to filter messages (that is, specified the WH_MSGFILTER hook type in a call to the SetWindowsHookEx function), a synchronous transaction will not cause the system to bypass the hook procedure. When an input event occurs while the client is waiting for a synchronous transaction to end, the hook procedure receives an MSGF_DDEMGR hook code. The main danger of using a synchronous transaction modal loop is that a modal loop created by a dialog box can interfere with its operation. Asynchronous transactions should always be used when the DDEML is being used by a dynamic-link library (DLL). | |||
| Пригласи друзей и счет твоего мобильника всегда будет положительным! | |||
| |||
| Пригласи друзей и счет твоего мобильника всегда будет положительным! | |||
Синхронные и Асинхронные СделкиКлиент может послать или синхронные или асинхронные сделки. В синхронной сделке, клиент определяет величину задержки, которая указывает максимальное время, которое он подождет сервер, чтобы обрабатывать сделку. DdeClientTransaction НЕ возвращается пока сервер не обработает сделку, сделка терпит неудачу, или величина задержки истекает. Клиент определяет величину задержки когда он называет DdeClientTransaction. В течение синхронной сделки, клиент вводит модальный цикл при ожидании сделки, которое нужно обрабатываться. Клиент может все еще обработать ввод пользователя но не может послать другую синхронную сделку до возврат DdeClientTransaction. Клиент посылает асинхронную сделку определяя флаг TIMEOUT_ASYNC в DdeClientTransaction. Функция возвращается после того, как сделка начала, прохождение идентификатора сделки клиенту. Когда сервер завершает обработку асинхронной сделки, DDEML посылает сделку XTYP_XACT_COMPLETE клиенту. Один из параметров, что DDEML проходит клиенту в течение сделки XTYP_XACT_COMPLETE - идентификатор сделки. При сравнении этого идентификатора сделки с идентификатором возвращанным DdeClientTransaction, клиент идентифицирует какую асинхронную сделку, которую сервер завершил обработку. Клиент может использовать функцию DdeSetUserHandle как помощь на обработке асинхронной сделки. Эта функция делает возможным для клиента, чтобы соединять определенной прикладной величине двойного слова с ручкой разговора и идентификатор сделки. Клиент может использовать функцию DdeQueryConvInfo в течение сделки XTYP_XACT_COMPLETE, чтобы получать определенную прикладную величину двойного слова. Из-за этой функции, приложение не должно поддержать список активных идентификаторов сделки. Когда клиент успешно завершает запрос о данных, использовавших синхронную сделку, DDEML не имеет ни за что, чтобы сообщать когда клиент завершил используя данные получал. Приложение клиента должно передать ручку данных полученную в функцию DdeFreeDataHandle, уведомляющую DDEML, что ручка больше не будет использована. Ручки Данных возвращанные синхронными сделками эффективно принадлежащие клиенту. Если сервер не обрабатывает асинхронную сделку в своевременном способе, клиент может покинуть сделку вызывая функцию DdeAbandonTransaction. DDEML Выпускает все ресурсы связанные сделкой и отвергает результаты сделки когда сервер завершает обрабатывая это. Задержка в течение синхронной сделки эффективно отменяет сделку. Асинхронный метод сделки предусмотрен для приложений, которые должны послать высокий объем сделок DDE при одновременно выполнении надежной суммы обработки, как например, вычисления выполнения. Асинхронный метод также полезный в приложениях, которые должны перестать обрабатывать сделки DDE временно, так что они могут завершить другие задачи без прерывания. В большинстве других ситуациях, приложение должно использовать синхронный метод. Синхронные сделки просты, чтобы поддерживать и быстрее чем асинхронные сделки. Тем не менее, только один синхронная сделка может выполняться за один раз, поскольку много асинхронные сделки могут выполняться одновременно. С синхронными сделками, медленный сервер может заставить клиента, чтобы оставаться ожиданием тогда как оно ждет ответ. Также, синхронные сделки заставляют клиента, чтобы вводить модальный цикл, который мог бы обойти сообщение, фильтрующееся в прикладной собственный цикл сообщения. Если клиент установил бы рычажную процедуру, чтобы фильтровать сообщения (то есть, определенный захват WH_MSGFILTER заносит вызов в функцию SetWindowsHookEx), синхронная сделка не заставит систему, чтобы обходить рычажную процедуру. Когда входное событие происходит пока клиент ждет синхронную сделку, чтобы заканчиваться, рычажная процедура получает рычажный код MSGF_DDEMGR. Основная опасность использования модального цикла синхронной сделки - то, что модальный цикл создавался диалоговым блоком может создаться помехи со своей операцией. Асинхронные сделки должны всегда использованы когда DDEML используется динамической связью библиотеки (DLL). | |||
| |||
 |
