информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Tailscale окончательно забанила... 
 Прекращение работы антивируса Касперского... 
 Microsoft Authenticator теряет... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Если это критично, то читаем маны: 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; }
about 49.7 days... 22.12.11 17:36  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
"... When using GetTickCount, subtraction is safe, even if the rollover occurred, and subtraction always yields the correct difference and the number of clock ticks passed between two tick values... ", see http://msdn.microsoft.com/en-us/library/aa915056.aspx. Also see useful reading, http://blogs.msdn.com/b/ce_base/archive/2005/06/08/426762.aspx

Thanks
ты должен учитывать что 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
<"чистая" ссылка>
NtQuerySystemTime may be altered or unavailable in future versions of Windows. 22.12.11 00:22  
Автор: + <Mikhail> Статус: Elderman
<"чистая" ссылка>
NtQuerySystemTime may be altered or unavailable in future versions of Windows.
а если серьёзно, то проблема решаема, только не так как она была предложена

http://msdn.microsoft.com/en-us/library/windows/desktop/ms724512(v=vs.85).aspx
Ну волков бояться... 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
<"чистая" ссылка>
Или сгенерить собственный евент, типа "не дождетесь!".
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach