Как определить что компьютер простаивает? Т.е. определенное время не двигается мышь и не нажимаются клавиши?
Если ли стандартные решения или функции API. Как винда это делает когда включает скринсейвер?

поставить хук на клаву и мышу. при срабатывании запоминать время. по таймеру сравнивать последнее запомненное и текущее.

Ставить хуки занятие неблагодарное и чреватое проблемами.
Может быть существуют альтернативные решения?

фига се... а в микрософте то и не знают!
хотя Snowy гораздо более простое решение привел)

Но я то знаю правду, что оценка постов это фигня, а настоящий плюс душу греет... Snowy +1   


Я сегодня добрый.   

Это сообщение отредактировал(а) Ch0bits - 7.8.2007, 14:47

спасиба конечно)

но про хуки ты зря так ;)

он прав. а на мелкософте так делают потому что имеют причины делать обоснованные предположения о месте их хука в системной очереди хуков

доказательства?
ниразу не сталкивался с проблемами при использовании хуков)

"Комп" - ка существо агрессивное не простаивает никогда - он всегда действует 
А вот определить, что сейчас приложение не занимается обработкой сообщений, можно по срабатыванию OnIdle...

Заводим Интегер-переменную MsgCount. В WM_CREATE запустить таймер с интервалом скажем 200. Потом в цикле обработки сообщений 

// <- Я имею в виду здесь
case uMsg of
  WM_CREATE:
    begin
      ...
    end;

  WM_ACTIVATEAPP:
    begin
      ...
    end;

  WM_PAINT:
    begin
      ...
    end;

  WM_TIMER:
    begin
      ...
    end;

  ...

  WM_DESTROY:
    begin
      ...
    end;
end;

проставляем: if (uMsg<>WM_TIMER)and(и ещё <> какие-нибудь регулярные мессаги) then MsgCount:=0;

а при каждом срабатывании таймера увеличиваем эту вариаблу на 1.
Если она достигла определённой величины, то резюмируем - юзверь отошёл по делам...
Способ не претендует на замену всем остальным, просто ещё одно соображение в тему.

DBZ, таймер будет работать независимо от того, есть юзер за компом или нет.
Вопрос вообще про определение активности юзера - клава/мыша.
Причём активности в системе, а не приложении.

мне кажется ответ на вопрос, заданный автором темы, уже дан Snowy  

Добавлено через 54 секунды
но мне всетаки хочется услышать весомые аргументы против использования хуков, как таковых....

Лень  Когда есть более элегантное решение предложеное Showy     

в данном случае да...

но мне интересно, почему

я так понимаю имелось ввиду использование хуков вообще.
новую тему чтоли завести

MetalFan, 
Кстати интересно будет  

P.S. Я кстати с удовольствием бы послушал бы отзывы людей которые часто используют хуки в своих приложениях. Я их использовал, на клаву вроде и все... ну небыло ситуаций у меня когда без них никак. Хотя сейчас в текущей моей задаче наверное придется ставить на zwTerninateProcess...

P.S.S. Просто интересно на какие грабли ножно наступить, а если наступить, то не очень сильно удариться 

Добавлено через 12 минут и 10 секунд
Кстати "по моему скромному мнению" было бы не плохо если кто-нибудь, кто шарит хорошо в этом написал бы статейку. Ну чтоб с бегемотами и т.д.  Будет куда направлять новичков, а то многие начитаются статей ms-rem-а, а с проблемами и не пониманием идут сюда...

хм) была как-то статейка "Хуки. Аспекты реализации" чтоли называлась) на DelphiWorld точно была,а может счас и в DRKB перенесли

MetalFan, что ты так завёлся про хуки? Они отрицательно влияют на быстродействие. Не надо быть гением, чтобы понять это, просто надо представлять себе как это всё работает. 

Сами по себе хуки - это связный список. Вот как описывает схему работы Рихтер:



Время выполнения 7го этапа напрямую зависит от быстродействия и объёма кода, который содержит твоя HookProc. Потеря быстродействия может быть и незаметна, а может прилично тормозить систему или вообще повешает её. В любом случае, глобальные хуки стоит использовать только при крайней необходимости, когда нет других решений. 

Это сообщение отредактировал(а) W4FhLF - 8.8.2007, 11:33

в том то и дело, что если грамотно ее написать, то никаких проблем быть НЕ ДОЛЖНО.

в том то и дело, что для отсутствия проблем нужно чтобы грамотно были написаны все хуки в системе, а не только твои. Ты никогда не знаешь будет ли у твоегог хука шанс среагировать на событие (не будет ли оно "обработано" более ранним хуком)