Szczawik napisał(a)
Od razu Ci powiem, ze nie jest to prawidlowa konstrukcja aplikacji, bo typowo uslugi (a zatem i pluginy uruchamiane w ich kontekscie) nie powinny komunikowac sie w zaden sposob z interfejsem uzytkownika (bo co, jesli usluga chodzi, a nikt nie jest zalogowany?).
To jest tak. Usługa sobie generalnie nic nie robi, tylko podczas uruchamiania łączy się z pluginami, no i nasłuchuje połączeń w sieci.
Dopiero klient, gdy się podłączy wysyła do usługi jakieś żądanie, nie wiem, w stylu: POBIERZ_UZYTKOWNIKOW. Usługa sobie parsuje to żądanie i wywołuje odpowiednią metodę w pluginach, ewntualnie na koniec wysyła klientowi komuikat zwrotny w stylu: UZYTKOWNICY_POBRANI.
Tak więc usługa tylko w taki sposób komunikuje się z klientami.
Prawidlowa architektura powinna byc taka, ze plugin sklada sie z dwoch czesci: plugin dla uslugi, plugin dla managera (moga byc nawet roznymi funkcjonalnosciami w jednym pliku pluginu).
Ale wtedy manager też musiałby mieć dostęp i obsługiwać pluginy :)
Aby jednak rozwiazac Twoj problem, bez przepisywania aplikacji, poczytaj o wariancie uslugi, ktory komunikuje sie z interfejsem uzytkownika (Interactive Services). Od razu zaznacze, co jest napisane w artykule, ze uzycie ich nie jest zalecane, bo nie pozwala na poprawne wykorzystanie przy systemach wielodostepnych (jak chocby Windows 2003) oraz, gdy wlaczone jest szybkie przelaczanie uzytkownikow (istniejace w XP czy Vista).
Współdziałanie z pulpitem?
Już się na tym kiedyś przejechałem, więc sobie daruję.
Ale wymyśliłem metodę nieco na około, ale może zadziała.
Otóż forma do pokazania będzie składała się z iluś przycisków.
Mógłbym zrobić tak, że wysyłam managerowi informacje, ile tych przycisków ma być itd., a manager sobie wszystko interpretuje i tworzy odpowiednie okno. Problem tylko, jak ma obsługiwać te przyciski. Musiałaby być ciągła komunikacja między pluginem, usługą i managerem, nie? I czy nie będzie to trochę przerost treści nad formą?