J'ai une application type console, que je dois faire fonctionner en=20
service, sous Windows 2000 et VC6.
Cette application a besoin d'une ic=F4ne dans le systray.
Dans cette optique, j'ai fait les op=E9rations suivantes :
- r=E9cup=E9ration d'un HMODULE que j'utilise comme HINSTANCE avec
GetModuleHandle ()
- cr=E9ation d'une fen=EAtre invisible, de mani=E8re =E0 avoir un hWnd
- d=E9finition d'un WM_xxx de mani=E8re =E0 r=E9cup=E9rer les messages
- appel de Shell_NotifyIcon.
L'appel de Shell_NotifyIcon renvoie 1, et l'ic=F4ne apparait bien dans le=
=20
systray.
Le probl=E8me que j'ai est qu'aucune action sur l'ic=F4ne ne renvoie de=20
message.
Le probl=E8me peut-il venir du fait que mon applcation est de type=20
console?
Le but de l'opération est de permettre à un système constitué de plusieurs serveurs (4 à 5), de redémarrer automatiquement après un reboot de la machine. La solution consiste à transformer ces serveurs en services.
Logique.
Ce que j'aimerais avoir, c'est une icône dans le systray, offrant un menu avec les icönes de mes services et permettant d'interréagir avec eux. Je souhaiterais avoir cette icône visible lorsqu'un utilisateur se loggue. Pour un de mes serveurs, j'aimerais pouvoir ouvrir une fenêtre de log, par exemple, en cliquant sur son icône.
Une solution parmi d'autres : le serveur se contente d'écrire dans un fichier de log et ton appli GUI fait l'équivalent d'un "tail" sur ce fichier avec FindFirstChangeNotification / FindNextChangeNotification.
Une simple DLL peut-elle suffire? Ou dois je faire un programme classique communiquant avec mes serveurs?
Un programme en mode utilisateur normal qui communique avec le serveur après avoir validé le contexte d sécurité (n'autoriser certaines manipulations qu'aux administrateurs, etc...)
Quel serait alors le meilleur protocole à utiliser? Il m'a été suggéré IPC et RPC. Je ne connais rien de IPC,
IPC = "Inter Process Communication" - un terme générique pour tous les mécanismes permettant de communiquer entre processus : RPC, COM, sockets, memory mapped files, events, ... tout ce que tu peux imaginer.
mais je connais la version ONC de RPC (pas la version Microsoft), et je sais commant écrire un protocole et générer les stubs. ONC RPC est déja utilisé par les serveurs.
Si tu connais RPC, c'est sans doute la solution qui serait la plus rapide à mettre en oeuvre. Sinon, regardes du côté de COM ou des memory mapped files et des primitives de synchronisation (mutexs, events, ....) En fait tou dépend de la complexité des échanges avec le service.
Arnaud
Alain Migeon wrote:
Le but de l'opération est de permettre à un système constitué de
plusieurs serveurs (4 à 5), de redémarrer automatiquement après un
reboot de la machine.
La solution consiste à transformer ces serveurs en services.
Logique.
Ce que j'aimerais avoir, c'est une icône dans le systray, offrant un
menu avec les icönes de mes services et permettant d'interréagir avec
eux. Je souhaiterais avoir cette icône visible lorsqu'un utilisateur
se loggue.
Pour un de mes serveurs, j'aimerais pouvoir ouvrir une fenêtre de log,
par exemple, en cliquant sur son icône.
Une solution parmi d'autres : le serveur se contente d'écrire dans un
fichier de log et ton appli GUI fait l'équivalent d'un "tail" sur ce fichier
avec FindFirstChangeNotification / FindNextChangeNotification.
Une simple DLL peut-elle suffire? Ou dois je faire un programme
classique communiquant avec mes serveurs?
Un programme en mode utilisateur normal qui communique avec le serveur après
avoir validé le contexte d sécurité (n'autoriser certaines manipulations
qu'aux administrateurs, etc...)
Quel serait alors le meilleur protocole à utiliser? Il m'a été suggéré
IPC et RPC. Je ne connais rien de IPC,
IPC = "Inter Process Communication" - un terme générique pour tous les
mécanismes permettant de communiquer entre processus : RPC, COM, sockets,
memory mapped files, events, ... tout ce que tu peux imaginer.
mais je connais la version ONC
de
RPC (pas la version Microsoft), et je sais commant écrire un protocole
et générer les stubs. ONC RPC est déja utilisé par les serveurs.
Si tu connais RPC, c'est sans doute la solution qui serait la plus rapide à
mettre en oeuvre. Sinon, regardes du côté de COM ou des memory mapped files
et des primitives de synchronisation (mutexs, events, ....) En fait tou
dépend de la complexité des échanges avec le service.
Le but de l'opération est de permettre à un système constitué de plusieurs serveurs (4 à 5), de redémarrer automatiquement après un reboot de la machine. La solution consiste à transformer ces serveurs en services.
Logique.
Ce que j'aimerais avoir, c'est une icône dans le systray, offrant un menu avec les icönes de mes services et permettant d'interréagir avec eux. Je souhaiterais avoir cette icône visible lorsqu'un utilisateur se loggue. Pour un de mes serveurs, j'aimerais pouvoir ouvrir une fenêtre de log, par exemple, en cliquant sur son icône.
Une solution parmi d'autres : le serveur se contente d'écrire dans un fichier de log et ton appli GUI fait l'équivalent d'un "tail" sur ce fichier avec FindFirstChangeNotification / FindNextChangeNotification.
Une simple DLL peut-elle suffire? Ou dois je faire un programme classique communiquant avec mes serveurs?
Un programme en mode utilisateur normal qui communique avec le serveur après avoir validé le contexte d sécurité (n'autoriser certaines manipulations qu'aux administrateurs, etc...)
Quel serait alors le meilleur protocole à utiliser? Il m'a été suggéré IPC et RPC. Je ne connais rien de IPC,
IPC = "Inter Process Communication" - un terme générique pour tous les mécanismes permettant de communiquer entre processus : RPC, COM, sockets, memory mapped files, events, ... tout ce que tu peux imaginer.
mais je connais la version ONC de RPC (pas la version Microsoft), et je sais commant écrire un protocole et générer les stubs. ONC RPC est déja utilisé par les serveurs.
Si tu connais RPC, c'est sans doute la solution qui serait la plus rapide à mettre en oeuvre. Sinon, regardes du côté de COM ou des memory mapped files et des primitives de synchronisation (mutexs, events, ....) En fait tou dépend de la complexité des échanges avec le service.
