D>И иеще протрассируй создалось ли окно в методе Execute

Сделал как ты написал. Окно создаеться хендл принимает значение, но месадж все равно не приходит.
Но вопрос мне кажеться еще в следующем: даже если я делал просто цикл в конце Execute, то ДЛЛ перестает работать (на ней как я уже писал есть Beep на таймере). Т.е. может быть в принципе такая идея не работоспособна?
И по ходу вопрос:
по условию задачи (но это худший вариант) я могу писать для каждого свой сервис, вместо плагина к сервису. Но... что лучше? или они одинаковы по затратам машинного времени и загрузкам процессора? или все же один сервис с десятком плагинов работающих в потоке лучше чем десяток сервисов?
З.Ы.: М-да — не выходит каменный цветок.

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

S>Здравствуйте, Danchik, Вы писали:
D>>Можно сделать ее самым банальным способом — создать в потоке окно и посылать к нему сообщения с помощью функций SendMessage (дождаться результата) и PostMessage (поставить сообщение в очередь и продолдать работать)

D>>Создать окно AllocateHWnd и уничтожить DeallocateHWnd (юнит Forms.pas)
S>Совершенно необязательно. Можно пользоваться PostThreadMessage и не думать, в какой оконной станции создается окно.

Так то оно так, только вот SendThreadMessage нету . Необходимо как то синхронизироваться.

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

D>>И иеще протрассируй создалось ли окно в методе Execute

S>Сделал как ты написал. Окно создаеться хендл принимает значение, но месадж все равно не приходит.

Странненько... Проверь попадает ли в WndProc метод.

S>Но вопрос мне кажеться еще в следующем: даже если я делал просто цикл в конце Execute, то ДЛЛ перестает работать (на ней как я уже писал есть Beep на таймере). Т.е. может быть в принципе такая идея не работоспособна?

Кажется я таки понял в чем твоя проблема. Timer — это те же Windows сообщения, соответственно их нужно обрабатывать, и причем в том же потоке где Timer был создан. Так как предложенный мною поток имеет реализацию обработки сообщений — то тебе абсолютно ничего не надо дописывать. Но одно но — создавать все Модули и стартовать плагины нужно именно в Execute. Конструктор Create потока для этих целей не подходит.

S>И по ходу вопрос:
S>по условию задачи (но это худший вариант) я могу писать для каждого свой сервис, вместо плагина к сервису. Но... что лучше? или они одинаковы по затратам машинного времени и загрузкам процессора? или все же один сервис с десятком плагинов работающих в потоке лучше чем десяток сервисов?
S>З.Ы.: М-да — не выходит каменный цветок.

Думаю что все таки один сервис лучше Не будеш же ты из-за каждого плагина регистрить новый сервис

D>Странненько... Проверь попадает ли в WndProc метод.

Да попадает.

D>Кажется я таки понял в чем твоя проблема. Timer — это те же Windows сообщения, соответственно их нужно обрабатывать, и причем в том же потоке где Timer был создан. Так как предложенный мною поток имеет реализацию обработки сообщений — то тебе абсолютно ничего не надо дописывать. Но одно но — создавать все Модули и стартовать плагины нужно именно в Execute. Конструктор Create потока для этих целей не подходит.

Т.е. мне необходимо иметь клас плагина, коий нужно экспортировать из DLL, причем незнаю как, и который создавать на Execute потока, а уже реализацию создания этого класса можно(нужно) делать в самой DLL плагина. Верно я понял? Или может лучше в этом случае плагины писать как потоки, но каждый плагин это один поток. Т.е. реализацию DLL делать как поток? А по событию останова сервиса вызывать функцию DLL, которая будет глушить этот поток.

Еще. А нужнен ли TDllThread.MyMessage2, ведь как только Execute отработает автматом будет вызван TDllThread.DoTerminate, может более коректно на нем производить остановку и выгрузку DLL, т.е. вместо

procedure TDllThread.MyMessage2(var Message: TMessage);
begin
  if HandleDLL <> 0 then StopPluggin;
  Terminate;
  FreeLibrary(HandleDLL);
end;

procedure TService1.ServiceStop(Sender: TService; var Stopped: Boolean);
begin
  if DllThread <> nil then
    SendMessage (DllThread.WndHandle, MY_MESSAGE2, 0, 0);
  Stopped := True;
end;

сделать просто

procedure TDllThread.DoTerminate;
begin
  if HandleDLL <> 0 then StopPluggin;
  FreeLibrary(HandleDLL);
end;

что скажешь?

D>Думаю что все таки один сервис лучше Не будеш же ты из-за каждого плагина регистрить новый сервис

Поэтому и хотел смотреть в сторону плагинов к сервису. А что касаеться производительности там, загрузки проца и прочее, я понимаю, что щас это не критично, но все же? Так — что называеться для в общеобразовательных целях?

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

D>>Странненько... Проверь попадает ли в WndProc метод.

S>Да попадает.

D>>Кажется я таки понял в чем твоя проблема. Timer — это те же Windows сообщения, соответственно их нужно обрабатывать, и причем в том же потоке где Timer был создан. Так как предложенный мною поток имеет реализацию обработки сообщений — то тебе абсолютно ничего не надо дописывать. Но одно но — создавать все Модули и стартовать плагины нужно именно в Execute. Конструктор Create потока для этих целей не подходит.

S>Т.е. мне необходимо иметь клас плагина, коий нужно экспортировать из DLL, причем незнаю как, и который создавать на Execute потока, а уже реализацию создания этого класса можно(нужно) делать в самой DLL плагина. Верно я понял?
Я бы тебе советовал сделать плагины COM in-proс серверами. Правда это нужно долго обьяснять
Можна также сделать конструкцию типа:

PluginHandle : Integer;
...
PluginHandle := {MyDll}CreatePlugin;
...
{MyDll}StartPlugin (PluginHandle)
..
{MyDll}StopPlugin (PluginHandle)

S>Или может лучше в этом случае плагины писать как потоки, но каждый плагин это один поток. Т.е. реализацию DLL делать как поток? А по событию останова сервиса вызывать функцию DLL, которая будет глушить этот поток.

Думаю не стоит писать полагины потоками, но тоже вариант, иногда это необходимо


S>Еще. А нужнен ли TDllThread.MyMessage2, ведь как только Execute отработает автоматом будет вызван TDllThread.DoTerminate, может более коректно на нем производить остановку и выгрузку DLL, т.е. вместо

S>

S>procedure TDllThread.MyMessage2(var Message: TMessage);
S>begin
S>  if HandleDLL <> 0 then StopPluggin;
S>  Terminate;
S>  FreeLibrary(HandleDLL);
S>end;

S>procedure TService1.ServiceStop(Sender: TService; var Stopped: Boolean);
S>begin
S>  if DllThread <> nil then
S>    SendMessage (DllThread.WndHandle, MY_MESSAGE2, 0, 0);
S>  Stopped := True;
S>end;
S>

S>сделать просто
S>

S>procedure TDllThread.DoTerminate;
S>begin
S>  if HandleDLL <> 0 then StopPluggin;
S>  FreeLibrary(HandleDLL);
S>end;
S>

S>что скажешь?

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

D>>Думаю что все таки один сервис лучше Не будеш же ты из-за каждого плагина регистрить новый сервис

S>Поэтому и хотел смотреть в сторону плагинов к сервису. А что касаеться производительности там, загрузки проца и прочее, я понимаю, что щас это не критично, но все же? Так — что называеться для в общеобразовательных целях?

Советую тебе сделать тестовую программу с двумя кнопками Start (like ServiceStart) и Stop (like ServiceStop).
На ней ты сможеш протестить как все работает в дебаге (это проще чем дебажить сервис).

А потом код перенеси на сервис. Если не будет работать можна проанализировать что у тебя с Permission и другой функциональностью, которая некорректно работает в сервисе.