Как потоку получить оповещение о выходе из suspend?

← →
Чапаев © (2007-02-12 11:53) [0]

Окно создавать ОЧЕНЬ не хочется.

← →
tesseract © (2007-02-12 12:17) [1]

Из suspend потока или suspend Windows?

← →
Чапаев © (2007-02-12 12:25) [2]

> [1] tesseract © (12.02.07 12:17)
Ой... Пардон. Windows.

← →
Игорь Шевченко © (2007-02-12 12:40) [3]

Чапаев © (12.02.07 12:25) [2]

То есть, WM_POWERBROADCAST ты не хочешь ловить ?

← →
Чапаев © (2007-02-12 12:50) [4]

> [3] Игорь Шевченко © (12.02.07 12:40)
Пытаюсь. И WM_POWERBROADCAST, и WM_POWER. Не доходят. WM_HOTKEY точно таким же (PeekMessage(Msg,0,WM_*,WM_*,PM_REMOVE)) способом ловится, а WM_POWER* -- нет.

← →
clickmaker © (2007-02-12 13:12) [5]

> [4] Чапаев © (12.02.07 12:50)
> > [3] Игорь Шевченко © (12.02.07 12:40)
> Пытаюсь. И WM_POWERBROADCAST, и WM_POWER. Не доходят

а каким окном их ловишь? Подозреваю, что они приходят только top-level окнам

← →
Чапаев © (2007-02-12 13:16) [6]

> [5] clickmaker © (12.02.07 13:12)
Эх... А так хочется без окон обойтись.

← →
clickmaker © (2007-02-12 13:32) [7]

> [6] Чапаев © (12.02.07 13:16)

в Windows да без окон?

← →
Чапаев © (2007-02-12 13:54) [8]

> [7] clickmaker © (12.02.07 13:32)
В службе.

← →
Чапаев © (2007-02-12 13:55) [9]

В общем, сделал окно, которое отправляет сообщение потоку... Уродство. :"-(

← →
Игорь Шевченко © (2007-02-12 14:32) [10]

Я извиняюсь, а зачем службе знать, что она после suspend"а ? Я понимаю, драйверу устройства надо знать, чтобы железку проинициализировать, так у него на это ядерный вызов есть, чтобы получать оповещения об изменении в питании.

← →
Rouse_ © (2007-02-12 15:19) [11]

А SERVICE_CONTROL_POWEREVENT с WM_POWERBROADCAST приходящим в dwEventType уже разве отменили? :)

← →
Чапаев © (2007-02-12 21:07) [12]

> [11] Rouse_ © (12.02.07 15:19)
Буду выяснять... ;-)

← →
Чапаев © (2007-02-14 13:41) [13]

Переписал стандартный vcl"овский TService так, чтобы дополнительные управляющие сообщения обрабатывал. Спасибо, Rouse.

← →
Сергей М. © (2007-02-14 15:04) [14]

> Чапаев © (14.02.07 13:41) [13]

Ты со стула упал ?)
Не трогай генофонд).. Метод DoCustomControl() специально для кулибиных и так уже виртуален)

← →
Чапаев © (2007-02-14 15:10) [15]

> Не трогай генофонд)..
Его я и не трогаю. Создал (передрал из стандартного) свой класс с установкой HandlerEx().

> Метод DoCustomControl()
Так-то оно так, но:
1) стандартный Handler() просто не может получать расширенные управляющие события;
2) GetNTControlsAccepted() вшита в private секцию TService.

← →
Сергей М. © (2007-02-14 15:15) [16]

> 1) стандартный Handler() просто не может получать расширенные
> управляющие события;

Что за бред ?

if msg.message = CM_SERVICE_CONTROL_CODE then begin OldStatus := FService.Status; try ActionOK := True; case msg.wParam of SERVICE_CONTROL_STOP: ActionOK := FService.DoStop; SERVICE_CONTROL_PAUSE: ActionOK := FService.DoPause; SERVICE_CONTROL_CONTINUE: ActionOK := FService.DoContinue; SERVICE_CONTROL_SHUTDOWN: FService.DoShutDown; SERVICE_CONTROL_INTERROGATE: FService.DoInterrogate; else ActionOK := FService.DoCustomControl(msg.wParam); //перекрывай в своем наследнике этот самый DoCustomControl() и вытворяй в его теле все что тебе вздумается ! end;

← →
Чапаев © (2007-02-14 15:21) [17]

> Что за бред ?
Note that these control codes are not supported by the Handler function. SERVICE_CONTROL_DEVICEEVENT SERVICE_CONTROL_HARDWAREPROFILECHANGE SERVICE_CONTROL_POWEREVENT SERVICE_CONTROL_SESSIONCHANGE

Так говорил MSDN. ;-)

← →
Сергей М. © (2007-02-14 15:34) [18]

> Чапаев © (14.02.07 15:21) [17]

Ах ты вон о чем !)

Ну а чем не понравился вариант с рантайм-перехватом вызова RegisterServiceCtrlHandler с целью подмены этого вызова на вызов RegisterServiceCtrlHandlerEx ?

← →
Rouse_ © (2007-02-14 15:46) [19]

ОФФ: Вот именно по этому все такие вещи я предпочитаю писать на АПИ, тут только самому можно накосячить :)

← →
Сергей М. © (2007-02-14 16:16) [20]

> Rouse_ © (14.02.07 15:46) [19]

Да ладно тебе)
Борландовское творчество для маздайной линейки ОС не такое уж и "косячное")

← →
Rouse_ © (2007-02-14 18:09) [21]

Не такое уж - согласен... Сейчас с Жекой упарились, пока врубились что к чему.
У меня сервис на АПИ, а его модуль крутящийся в сервисе требует выноса в поток (там работа с электронными ключами длительная). Соответственно что делаем - оборачиваем егойный вызов в TThread. Дергаем по необходимости Synhronize и что получаем? Прально, получаем дулю. Т.к. Synhronize встает в ступор на вот этой строчке:
WaitForSingleObject(SyncProcPtr.Signal, INFINITE);
А главный поток у нас как известно для SCM отведен - сервис то в своем крутиться...
Пришлось как обычно через ж. делать. Содавать окно и синхронный SendMessage с указателем на необходимый метод слать...

← →
Сергей М. © (2007-02-15 13:15) [22]

Так вот правильно, с ним то как раз синхронизироваться не нужно :)
А TThread к нему лезет...

мда, столкнулся тоже некоторое время назад с необходимостью перехвата SERVICE_CONTROL_SESSIONCHANGE.

Пришлось написать SvcMgrEx.pas если кому надо - вышлю.

> [24] Eraser © (16.02.07 20:46)
Шамаааан! У меня тоже SvcMgrEx.pas! :-D

Сегодня тудыть ещё надо SERVICE_CONTROL_DEVICEEVENT впендюрить...

Ещё вопросик. Чревата ли чем-нибудь нехорошим обработка событий непосредственно в HandlerEx()? А то для обработки стандартных событий отправляется сообщение сервисному потоку...

> [26] Ketmar © (17.02.07 12:03)

ушло )

> [27] Чапаев © (18.02.07 14:12)

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

в SvcMgr так и сделано, однако для HandlerEx пришлось ивратиться, т.к. там параметров побольше будет.

> в SvcMgr так и сделано, однако для HandlerEx пришлось ивратиться,
> т.к. там параметров побольше будет.
Так о том и речь. Нормально ли будет обрабатывать прямо в HandlerEx()?

В принципе, длительные действия будут выполняться в собственных потоках.

> [29] Чапаев © (18.02.07 14:33)

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

> Чревата ли чем-нибудь нехорошим обработка событий непосредственно
> в HandlerEx

Ну если был вызван не RegisterServiceCtrlHandlerEx а RegisterServiceCtrlHandler, то чревато... Кол-во параметров, то разное...

Как потоку получить оповещение о выходе из suspend? Найти похожие ветки