Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Если это критично, то читаем маны: To avoid this problem, use the GetTickCount64 function. 21.12.11 13:29 Число просмотров: 4096
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
<programming>
|
AtlWaitWithMessageLoop 16.12.11 22:43
Автор: void <Grebnev Valery> Статус: Elderman Отредактировано 20.01.12 20:20 Количество правок: 1
|
Предлагается изиенить AtlWaitWithMessageLoop, чтобы выходить по таймауту (для еветна)
Какие идеи? Может так:
BOOL AtlWaitWithMessageLoop_WithTimeOut(HANDLE hEvent, DWORD timeOut = INFINITE)
{
DWORD dwRet;
MSG msg;
// здесь ...
DWORD start = ::GetTickCount();
DWORD duration = 0;
while(1)
{
dwRet = MsgWaitForMultipleObjects(1, &hEvent, FALSE, timeOut, QS_ALLINPUT);
if (dwRet == WAIT_OBJECT_0)
return TRUE; // The event was signaled
if (dwRet != WAIT_OBJECT_0 + 1)
break; // Something else happened
// There is one or more window message available. Dispatch them
while(PeekMessage(&msg,NULL,NULL,NULL,PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
if (WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0)
return TRUE; // Event is now signaled.
// и здесь ...
duration = ::GetTickCount() - start;
if( duration > timeOut ) {
return FALSE;
}
}
}
return FALSE;
}
---
Fixed a bug if( duration > timeOut ) { return TRUE; } should be f( duration > timeOut ) { return FALSE; }
|
|
ты должен учитывать что GetTickCount() всего на ~49дней, 21.12.11 05:10
Автор: + <Mikhail> Статус: Elderman
|
|
| |
Если это критично, то читаем маны: To avoid this problem, use the GetTickCount64 function. 21.12.11 13:29
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
| | |
не все на 64 битах сидят и ты должен это учитывать. 21.12.11 20:55
Автор: + <Mikhail> Статус: Elderman
|
не все на 64 битах сидят и ты должен это учитывать.
P.S. зачем я это говорю, это же очевидно
|
| | | |
Это-то при чём. Функция висит в том числе и на 32-х битных ос. Только что проверил на своей семёрке. Или мало примеров функций, возвращающих данные длиннее, чем разрядность системы? 22.12.11 12:50
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
| | | | |
ну хотя бы потому что: 28.12.11 00:45
Автор: + <Mikhail> Статус: Elderman
|
ну хотя бы потому что:
GetTickCount64()
Minimum supported client: Windows Vista
Minimum supported server: Windows Server 2008
|
| | | |
Истчо есть NtQuerySystemTime(). 21.12.11 21:11
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
| | | | | |
Ну волков бояться... M$ достаточно параноидально относится к совместимости, а эта функция успела обрести популярность. 22.12.11 00:43
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
| | | | | | |
про волков это зря, у нас такое не пройдёт, и правильно 22.12.11 02:57
Автор: + <Mikhail> Статус: Elderman Отредактировано 05.01.12 20:47 Количество правок: 1
|
из-за такого подхода спутники и падают
|
|
А смысл? Предотвратить зависание окон? 17.12.11 05:06
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
| |
Смысл, в том, что нередко необходимо ждать handle-а не... 18.12.11 02:11
Автор: void <Grebnev Valery> Статус: Elderman
|
Смысл, в том, что нередко необходимо ждать HANDLE-а не INFINITE, но выходить по таймауту. Обрати внимание, что все API Waitxxx функции имеют таймаут в качестве одного из аргументов.
Но при этом оконное приложение (тред на котором выподняется оконная процедура) не должет быть блокирован на Wait функции. По этой причине выполняется прокачка сообщений вместе с ожиданием HANDLE-а. Microsoft версия такой функции не имеет таймаута.
|
| | |
Дык handle-а-то таким способом не получишь! 18.12.11 06:23
Автор: Zef <Alloo Zef> Статус: Elderman
|
Или сгенерить собственный евент, типа "не дождетесь!".
|
|
|