Способен ли сервис получать messages ?

← →
Yuri Btr (2003-11-04 16:00) [0]

Ув. мастера, у меня есть программа сервис - для управления ею хочу попробовать сообщения, в общем из управляющей программы посылаю сервису сообщение WM_USER+4444 предварительно найдя его хендл по caption. В самом сервисе пишу
procedure WMGETSTATISTIC (var M:Integer); message WM_USER+4444;
...
procedure TService.WMGETSTATISTIC (var M:Integer);
begin
GetStatistic:=true;
end;

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

Подскажите, может ли сервис таким образом получать мои сообщения?
Заранее спасибо.

← →
zapped (2003-11-04 18:54) [1]

я как-то задавал вопрос @как взаимодействовать с сервисом@, ответили, что лучше с помощью pipes.
Ключевые слова CreateNamedPipe, CreateFile, ReadFile...

← →
Игорь Шевченко (2003-11-04 19:58) [2]

Если сервису разрешено взаимодействие с рабочим столом и сервис имеет окно, то можно и через сообщения

← →
Digitman (2003-11-05 09:26) [3]

сервис имеет свой как минимум один отдельный кододый поток
зная его Id, можно посылать сообщения этому код.потоку вызовом PostThreadMessage()

← →
Alex Konshin (2003-11-05 10:22) [4]

TService, насколько я помню, не форма. IMHO для него message не имеет смысла.
Вообще, чтобы получать сообщения в каком-то thread"е, нужно организовать цикл выборки сообщений.
Далее пишу по памяти - давно уже с ними дела не имел, могу и наврать.
Проблема еще и в том, что сервис сам по себе стартует thread и полезная работа происходит в другой нити, отличной от той, в которой создавался сервис.
Короче, там есть где запутаться.

Тебе что нужно передавать? Может, тебе будет достаточно просто именованного события? Если же данными обмениваться надо, то, один хрен, через сообщения много не передашь, не забывай о том, что адресные пространства у разных процессов - разные. Если надумаешь использовать NamedPipes, то посмотри в моем примере SQLAlert: там внутри в директории Sample есть юнит PipeControler и пример его использования.
http://home.earthlink.net/~akonshin/index.htm

← →
Yuri Btr (2003-11-05 11:16) [5]

Большое спасибо всем за ответы
to zapped ©
Попозже погляжу ваш вариант

to Игорь Шевченко ©
Взаимодействие разрешено, но окна нет.

to Digitman ©
Ваш вариант кажется наиболее приемлимым

to Alex Konshin ©
Про разные адресные пространства я уже давно догадываюсь :)
Адреса структур я не собираюсь передавать.
Передавать нужно в одну сторону всего лишь одно число, а обратно два. Т.Е. messages меня пока удовлетворяют.
Спасибо за ссылку рассмотрю обязательно этот вариант ведь у вас с zapped Одинаковые предложения.

← →
LordOfSilence (2003-11-05 11:47) [6]

Я, конечно, дико извиняюсь, что встреваю...
А что мешает использовать в "менеджере" для сервиса функцию
ControlService из модуля WinSvc? А в сервисе, в свою очередь,
сделать override методу DoCustomControl, и в нем обрабатывать
пользовательские управляющие коды?
Если я, конечно, правильно понял проблему...

← →
Digitman (2003-11-05 11:52) [7]

> LordOfSilence

ControlService() не позволяет передать произвольное число параметров произвольного размера, тем более - получить результат обработки переданного контрола

> Yuri Btr

единственное ограничение - PostThreadMessage() позволяет передать не более двух параметров, не ждет результатов обработки сообщения и, соотв-но, не возвращает результат обработки.

но это можно обойти, используя MMF

← →
Yuri Btr (2003-11-05 12:19) [8]

to Digitman ©
Я уже попробовал, меня пока всё устраивает. Возвращать рез-т мне не нужно. Но трудности в получении того самого идентификатора нити idThread. Для отладки беру его из Spy++. Перерыл MSDN - нашёл только как определить PID - GetWindowThreadProcessId, но как дальше получить idThread не могу найти ...

to LordOfSilence ©
Погляжу внимательно ваше предложение, авось на будущее сгодится.

← →
Digitman (2003-11-05 12:54) [9]

> Yuri Btr

> меня пока всё устраивает

если устраивает, то лучше поступить как советует <LordOfSilence>

ControlService() фактически позволяет передавать код.потоку сервиса сообщение с параметром-кодом размером в DWord. При этом знать Id код.потока сервиса не нужно - главное чтобы код.поток сервиса "знал" этот код и "умел" его обрабатывать, т.е., например, в перекрытом в наследнике класса TService методе DoCustomControl() была заложена логика реакции на нужный CtlCode, получаемый параметром.

← →
Yuri Btr (2003-11-05 13:35) [10]

← →
Digitman (2003-11-05 13:45) [11]

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

← →
Yuri Btr (2003-11-05 14:21) [12]

to Digitman ©
А как это делает тот же Spy++
Я посмотрел через Dependencies Scanner, никакого намёка на функцию получения идентификатора нити не имеется, всё что есть (касательно процессов и потоков) не позволяет узнать idThread.

Есть ли у кого нибудь крохотный пример использования PostThreadMessage с заранее неизвестным idThread ?

← →
Yuri Btr (2003-11-05 14:33) [13]

to Digitman ©
Извините, виноват, нужно внимательно читать SDK

GetWindowThreadProcessId
.....
Return Values
The return value is the identifier of the thread that created the window.

Спасибо всем за ответы

Способен ли сервис получать messages ? Найти похожие ветки