Цитата(Earnest @ 10.2.2009, 16:43  ) | | Это дело, к сожалению, звучит соблазнительно, но работает так себе |
да нет, нормально работает, о замечаниях к TrackMouseEvent я уже писал, правда давно, но, тем не менее, работает она до тех пор, пока очередь сообщений потока, владеющего окном, не пуста
это ключевой момент
ладно, добью таки до конца уже начатое, чтобы было понятно, когда необходимо дополнить любые сенсорные проверки на мышь
кстати, это касается не только TrackMouseEvent, так же, любые проверки на WM_NCHITTEST или просто на WM_MOUSEMOVE, в общем - на любые проверки, которые производятся в ответ на оконные сообщения, зависимые от внешних устройств
вот, к примеру, главный цикл окна:
| Код |
while (GetMessage(&msg, NULL, 0, 0))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
|
что он делает? GetMessage - это "ядерная" функция, которая "спит" до тех пор, пока очередь пустая, т.е. этот вариант для TrackMouseEvent неудобен, поскольку нужное нам время GetMessage отдает другим процессам
ок, теперь другой вариант:
| Код |
do{
fPeek = ::PeekMessage(&m_Msg,0,0,0,PM_REMOVE);
if(fPeek == TRUE){
if(!::TranslateAccelerator(m_TranslateWindow,m_Accel,&m_Msg)){
::TranslateMessage(&m_Msg);
::DispatchMessage(&m_Msg);
}
}else if(fPeek == FALSE){
// время Idle
::WaitMessage();
}else{
// обработать ошибку
}
}while(m_Msg.message != WM_QUIT);
|
PeekMessage - это более гибкий вариант GetMessage, который не отдает автоматом время другим процессам, вместо этого, она возвращает TRUE, если сообщение было успешно извлечено из очереди, и FALSE - когда извлекать из очереди просто нечего, она пустая
при успешном возврате из PeekMessage, мы делаем то же самое, что и в примере выше, т.е. это обычная обработка сообщения, а вот в случае, когда PeekMessage возвращает FALSE, как раз и наступает время простоя(Idle), которое мы теперь можем использовать по своему
есть 2 варианта
1. самим отдать время простоя в систему, т.е. дать возможность поработать другим задачам в этот период
2. сделать не слишком долгосрочную обработку чего-либо, пока сообщения в очереди вновь не появятся
WaitMessage - первый вариант, эта функция будет просто "спать", пока очередь не активируется
второй вариант - как раз то, что нам и нужно, т.е. мы сами можем здесь поставить необходимую нам обработку (допустим проверку текущих координат курсора на предмет присутствия его в нужной нам области и, в случае отсутствия - снять какие-либо флаги состояния, или напрямую вывести компонент в неактивный режим, вобщем, это уже непосредственно модель простоя, которую программист может реализовывать по своему вкусу и предубеждениям), после чего, если более время Idle нам не нужно, вызвать WaitMessage
если не вызывать WaitMessage, или нагружать слишком много проверок в этот момент, то нагрузка на процессор будет 100% на протяжении всей работы приложения, так что не стоит этим злоупотреблять, поскольку обычная работа приложений уже будет нарушена + начнут вылезать различные артефакты, которым не было места при нормальной работе
ну вот, теперь, похоже добил ) |
