никто не в курсе, где у него "кнопка", отключающая idle-ность ?
мне нужно цикл крутился постоянно.

Здравствуйте, Denis Knyazev, Вы писали:

DK>никто не в курсе, где у него "кнопка", отключающая idle-ность ?
DK>мне нужно цикл крутился постоянно.

А он и так крутится постоянно

Не совсем понятно, что именно требуется?
Чтобы не вызывался OnIdle?
Переопределите эту виртуальную функцию.
Или вообще можете написать свой вариант функции CMessageLoop::Run

Привет Денис, это Григорий.
Как дела? Заинтересовался WTL?

Пиши: greg at crystall.tl.ru
Звони: 89050157928

MtG forever!

2 moderator: sorry, где как не на RSDN можно встретить старых друзей, которых давно не видел

Здравствуйте, Alexey Goncharov, Вы писали:

DK>>никто не в курсе, где у него "кнопка", отключающая idle-ность ?
DK>>мне нужно цикл крутился постоянно.

AG>А он и так крутится постоянно

ну, как я увидел, не совсем постоянно. я отнаследовал CMessageLoop и
переопределил метод Run, в который добавил нужные мне действия. и эти действия
не выполняюся если пользователь ничего не делает. но стОит только подвигать мышкой
( это типа для генерации сообщений ) как всё нормально крутится...

AG>Не совсем понятно, что именно требуется?
AG>Чтобы не вызывался OnIdle?
AG>Переопределите эту виртуальную функцию.
AG>Или вообще можете написать свой вариант функции CMessageLoop::Run

вот в нём-то и вся загвоздка. я скопировал текст из родного CMessageLoop::Run
и добавил в него что мне нужно. и оно не совсем правильно работает. то есть
если нет вообще никаких сообщений, то мой код не выполняется. ща попробую порыть
в сторону OnIdle...

Здравствуйте, GregZ, Вы писали:

GZ>Привет Денис, это Григорий.
GZ>Как дела? Заинтересовался WTL?

жизнь заставила

GZ>Пиши: greg at crystall.tl.ru
GZ>Звони: 89050157928

стукнись в аську 99806075. или после 19:00 в будни позвони мне 563770

Здравствуйте, Denis Knyazev, Вы писали:

AG>>Или вообще можете написать свой вариант функции CMessageLoop::Run
DK>вот в нём-то и вся загвоздка. я скопировал текст из родного CMessageLoop::Run
DK>и добавил в него что мне нужно. и оно не совсем правильно работает. то есть
DK>если нет вообще никаких сообщений, то мой код не выполняется. ща попробую порыть
DK>в сторону OnIdle...

покопал OnIdle. что-то совсем не понятен прицип, по которому оно срабатывает.
потому как если приложению нет -никаких- сообщений, то в CMessage::Run точно
так же ничего не происходит -- привесил на него свои CIdleHandler-ы, они вызваются,
но по такому же принципу: только когда есть хоть какие-то сообщения.

Здравствуйте, Denis Knyazev, Вы писали:

Реализация CMessageLoop::OnIdle игнорирует результат, возвращаемый из CIdleHandler::OnIdle:

    virtual BOOL OnIdle(int /*nIdleCount*/)
    {
        for(int i = 0; i < m_aIdleHandler.GetSize(); i++)
        {
            CIdleHandler* pIdleHandler = m_aIdleHandler[i];
            if(pIdleHandler != NULL)
                pIdleHandler->OnIdle();
        }
        return FALSE;   // don't continue
}

(WTL 7.5)

Нужно переопределить CMessageLoop::OnIdle в своем классе и дать WTL по башке, чтобы не игнорировала...
Тогда сможешь вернуть TRUE из своего хандлера для продолжения банкета...

Тут могут быть разные варианты логики, в случае если имеется несколько IdleHandler-ов, так что конкретные варианты не предлагаю.

Здравствуйте, rus blood, Вы писали:

RB>Реализация CMessageLoop::OnIdle игнорирует результат, возвращаемый из CIdleHandler::OnIdle:
RB>

RB>    virtual BOOL OnIdle(int /*nIdleCount*/)
RB>    {
RB>        for(int i = 0; i < m_aIdleHandler.GetSize(); i++)
RB>        {
RB>            CIdleHandler* pIdleHandler = m_aIdleHandler[i];
RB>            if(pIdleHandler != NULL)
RB>                pIdleHandler->OnIdle();
RB>        }
RB>        return FALSE;   // don't continue
RB>}
RB>

RB>(WTL 7.5)
RB>Нужно переопределить CMessageLoop::OnIdle в своем классе и дать WTL по башке, чтобы не игнорировала...
RB>Тогда сможешь вернуть TRUE из своего хандлера для продолжения банкета...
RB>Тут могут быть разные варианты логики, в случае если имеется несколько IdleHandler-ов, так что конкретные варианты не предлагаю.

то есть вместо return FALSE сказать return TRUE ? попробовал. стало немеряно жрать проц.
вариант "проверка PeekMessage, если что-то есть, то GetMessage, иначе делаем своё грязное дело"
тоже сильно жрёт проц. против такого расклада есть способы борьбы ? в общем-то, суть проблемы
в следующем: мне глобально надо проверять некоторые внутренние состояния через определённые
промежутки времени; однако этих промежутков может быть несколько для разных состояний и периоды
их так же могут меняться в процессе работы. через WM_TIMER пробовал, не устраивает его негибкость.

Здравствуйте, Denis Knyazev, Вы писали:

блин, проблема "кто-то слишком много кушать" решилась тупо и банально:

BOOL CMyMessageLoop::OnIdle(int nIdleCount)
  {
  for(int i = 0; i < m_aIdleHandler.GetSize(); i++)
    {
    CIdleHandler* pIdleHandler = m_aIdleHandler[i];
    if(pIdleHandler != NULL)
      {
      Sleep(1);
      if (pIdleHandler->OnIdle() == FALSE) break;
      }
    }
  return TRUE;
  }

внимание, вопрос: а есть ли более изящные и правильные способы решения ?

Здравствуйте, Denis Knyazev, Вы писали:

DK>то есть вместо return FALSE сказать return TRUE ? попробовал. стало немеряно жрать проц.
DK>вариант "проверка PeekMessage, если что-то есть, то GetMessage, иначе делаем своё грязное дело"
DK>тоже сильно жрёт проц. против такого расклада есть способы борьбы

Так и должно было получиться. Понятие "жрет процессор" не определено.
Когда TaskManager показывает 0% CPU — это не значит, процессор ничего не делает. Он просто крутится в таком же цикле в system idle process. После того, как ты зациклил свой OnIdle, проц стал крутится в твоем приложении. Только и всего. Как только возникают сообщения, поток должен их обработать. Для других потоков можно ставить возможность принудительного переключения — Sleep(0), как ты уже сделал.

DK>в общем-то, суть проблемы
DK>в следующем: мне глобально надо проверять некоторые внутренние состояния через определённые
DK>промежутки времени; однако этих промежутков может быть несколько для разных состояний и периоды
DK>их так же могут меняться в процессе работы. через WM_TIMER пробовал, не устраивает его негибкость.

А чем WM_TIMER не гибок в данном случае?

Здравствуйте, rus blood, Вы писали:

DK>>через WM_TIMER пробовал, не устраивает его негибкость.
RB>А чем WM_TIMER не гибок в данном случае?

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

Здравствуйте, Denis Knyazev, Вы писали:

DK>пользователь может поменять период опроса устройства в любой момент.
DK>и значение этого периода может быть от сотен милисекунд до десятков часов.

И какие проблемы с WM_TIMER в этом случае???

Здравствуйте, rus blood, Вы писали:

DK>>пользователь может поменять период опроса устройства в любой момент.
DK>>и значение этого периода может быть от сотен милисекунд до десятков часов.
RB>И какие проблемы с WM_TIMER в этом случае???

да уж больно муторно каждый раз менять значение. плюс мне нужен
не только жёстко заданный период, а ещё и возможность сделать опрос
устройства (или даже несколько опросов) чуть пораньше, чтобы иметь
возможность наполнить кеш.