| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как потоку получить оповещение о выходе из suspend?
Чапаев © (2007-02-12 11:53:00)Окно создавать ОЧЕНЬ не хочется.
Rouse_ (2007-02-19 09:58:00) [1]
> Чревата ли чем-нибудь нехорошим обработка событий непосредственно
> в HandlerEx
Ну если был вызван не RegisterServiceCtrlHandlerEx а RegisterServiceCtrlHandler, то чревато... Кол-во параметров, то разное...
Eraser (2007-02-18 16:11:00) [2]> [29] Чапаев © (18.02.07 14:33)
думаю что нормально, а для длительных действий можно уже надстроить свой механизм, поверх стандартного.
Чапаев (2007-02-18 14:33:00) [3]> в SvcMgr так и сделано, однако для HandlerEx пришлось ивратиться,
> т.к. там параметров побольше будет.
Так о том и речь. Нормально ли будет обрабатывать прямо в HandlerEx()?
В принципе, длительные действия будут выполняться в собственных потоках.
Eraser (2007-02-18 14:29:00) [4]> [26] Ketmar © (17.02.07 12:03)
ушло )
> [27] Чапаев © (18.02.07 14:12)
> А то для обработки стандартных событий отправляется сообщение
> сервисному потоку...
в SvcMgr так и сделано, однако для HandlerEx пришлось ивратиться, т.к. там параметров побольше будет.
Чапаев (2007-02-18 14:12:00) [5]Ещё вопросик. Чревата ли чем-нибудь нехорошим обработка событий непосредственно в HandlerEx()? А то для обработки стандартных событий отправляется сообщение сервисному потоку...
Ketmar (2007-02-17 12:03:00) [6]> Eraser © (16.02.07 20:46) [24]
зашвырни в меня. я ленивый писать. %-) ketmar-glyph-online.ua
%-)
Чапаев (2007-02-17 08:45:00) [7]> [24] Eraser © (16.02.07 20:46)
Шамаааан! У меня тоже SvcMgrEx.pas! :-D
Сегодня тудыть ещё надо SERVICE_CONTROL_DEVICEEVENT впендюрить...
Eraser (2007-02-16 20:46:00) [8]мда, столкнулся тоже некоторое время назад с необходимостью перехвата SERVICE_CONTROL_SESSIONCHANGE.
Пришлось написать SvcMgrEx.pas если кому надо - вышлю.
Rouse_ (2007-02-16 17:44:00) [9]Так вот правильно, с ним то как раз синхронизироваться не нужно :)
А TThread к нему лезет...
Сергей М. (2007-02-15 13:15:00) [10]
> Rouse_ © (14.02.07 18:09) [21]
А нафига синхронизироваться с осн.потоком сервис-процесса ?
Rouse_ (2007-02-14 18:09:00) [11]Не такое уж - согласен... Сейчас с Жекой упарились, пока врубились что к чему.
У меня сервис на АПИ, а его модуль крутящийся в сервисе требует выноса в поток (там работа с электронными ключами длительная). Соответственно что делаем - оборачиваем егойный вызов в TThread. Дергаем по необходимости Synhronize и что получаем? Прально, получаем дулю. Т.к. Synhronize встает в ступор на вот этой строчке:
WaitForSingleObject(SyncProcPtr.Signal, INFINITE);
А главный поток у нас как известно для SCM отведен - сервис то в своем крутиться...
Пришлось как обычно через ж. делать. Содавать окно и синхронный SendMessage с указателем на необходимый метод слать...
Сергей М. (2007-02-14 16:16:00) [12]
> Rouse_ © (14.02.07 15:46) [19]
Да ладно тебе)
Борландовское творчество для маздайнойлинейки ОС не такое уж и "косячное")
Rouse_ (2007-02-14 15:46:00) [13]ОФФ: Вот именно по этому все такие вещи я предпочитаю писать на АПИ, тут только самому можно накосячить :)
Сергей М. (2007-02-14 15:34:00) [14]
> Чапаев © (14.02.07 15:21) [17]
Ах ты вон о чем !)
Ну а чем не понравился вариант с рантайм-перехватом вызова RegisterServiceCtrlHandler с целью подмены этого вызова на вызов RegisterServiceCtrlHandlerEx ?
Чапаев (2007-02-14 15:21:00) [15]> Что за бред ?
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:15:00) [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:10:00) [17]> Не трогай генофонд)..
Его я и не трогаю. Создал (передрал из стандартного) свой класс с установкой HandlerEx().
> Метод DoCustomControl()
Так-то оно так, но:
1) стандартный Handler() просто не может получать расширенные управляющие события;
2) GetNTControlsAccepted() вшита в private секцию TService.
Сергей М. (2007-02-14 15:04:00) [18]
> Чапаев © (14.02.07 13:41) [13]
Ты со стула упал ?)
Не трогай генофонд).. Метод DoCustomControl() специально для кулибиных и так уже виртуален)
Чапаев (2007-02-14 13:41:00) [19]Переписал стандартный vcl'овский TService так, чтобы дополнительные управляющие сообщения обрабатывал. Спасибо, Rouse.
Чапаев (2007-02-12 21:07:00) [20]> [11] Rouse_ © (12.02.07 15:19)
Буду выяснять... ;-)
| |
Страницы: 