Utilisation de System.ComponentModel.Component

Bonjour,

J'ai une application qui se connecte à des automates et qui attend des notifications de sa part. Ces notifications se font via la connexion à l'automate, puis ce dernier remonte des événements.

Tout fonctionne, mais seulement dans une application WinForms. J'aimerais passer cela en service Windows, mais les événements ne remontent pas. Idem pour une application console.

J'ai fait quelques recherches et j'ai l'impression qu'il faut que je fasse hériter mon point d'entrée de l'application (main) de System.ComponentModel.Component. Le problème est que je ne sais pas comment l'utiliser, et je nage un peu...

Quelqu'un peut m'aider? Je ne suis peut-être pas sur la bonne voie...

Merci d'avance !

ton automate est connecté comment au PC? port Serie, port //, TCP ????

TCP, via un protocole propriétaire du fabriquant (Beckhoff). Mais je ne pense pas que le problème vienne de là car mon code est exactement le même dans mon application graphique, console et service windows...

Désolé, je ne peu aidé :roll:

salut

si les événements ne remonte pas dans une application console, il y a fort à parier que ton application travaille avec les boucles d'événements windows. Et donc, forcement, en appli console ou Service, ca va pas le faire (vu que la pompe à message n'existe pas dans une appli console (pour un service, je ne sais pas...)

Dans ton application, tu as des timers, des choses comme cela ?

Si tu as des mécanismes genre Timer (issue de Windows.Forms.Timer), il est logique que cela ne puisse fonctionner puisque ces timers s'appuient sur la pompe à message pour notifier que le temps s'est écouler...
(il vaut mieux alors utiliser les timer multimédia qui en .Net sont sous Windows.Thread.timers si ma mémoire n'est pas complètement défaillante))

Après, j'aurais tendance à dire que si ton appli marche ne console, elle tournera aussi en service...

Après, qu'est ce qui ne marche pas ? les notifications ?
comment gères tu les notifications ? par pooling ? par "exceptions" ?

The Monz, Toulouse

Salut theMonz,

merci de ta réponse ! Peux-tu m'en dire un peu plus sur cette "pompe à message" ou me filer un lien? De quoi s'agit-il?

Citation:

---

Envoyé par theMonz31

Dans ton application, tu as des timers, des choses comme cela ?

---

Non, je n'ai pas de timer. Je n'utilise à aucun endroit des fonctionnalités de System.Windows.Forms.

Citation:

---

Envoyé par theMonz31

Après, j'aurais tendance à dire que si ton appli marche ne console, elle tournera aussi en service...

---

Je pense aussi

Citation:

---

Envoyé par theMonz31

Après, qu'est ce qui ne marche pas ? les notifications ?
comment gères tu les notifications ? par pooling ? par "exceptions" ?

---

Mon application fonctionne de la manière suivante (en ne prennant que les points relatifs à mon problème) :

1. Connexion à l'automate
2. Mise en surveillance de certaines variables (En résumé, consiste à catcher un événement levé par la dll du fabriquant de l'automate)
3. Démarrage de l'application terminée

Ensuite, dès que la valeur d'une variable mise en surveillance est modifiée, un événement (notification) est levé par la dll du fabriquant de l'automate. Il y a plusieurs types de surveillance de modification de variable : OnChange, Pooling. Pour ma part, j'utilise OnChange, qui fonctionne sous WinForms.

Dans le cas d'une application windows, l'événement remonte correctement. Par contre, dans le cas d'application console ou service windows, l'événement ne remonte pas. C'est un peu comme si l'événement n'était pas catché, alors que le code est le même dans tous mes types d'appli. Je pense qu'il faut que je cherche dans le sens de cette "pompe à message". Il faut que je l'implémente, si cela est possible...

Merci d'avance !

salut

En gros, la pompe a message qui est présente dans une application Windows et pas dans une application console est une callback qui va être appelé par l'OS pour notifier l'application qu'un événement lui arrive.

Cette méthode, que l'on peut overrider en .Net avec WndProc était "simulé" dans les application Win32 avec une boucle While() qui faisait un "peek message"
pour savoir si quelque chose avait été envoyé à la fenêtre. C'est une notion plutot propre aux applications fenêtrées.

Je pense que tu peux chercher de la doc sur la "gestion d'une pompe" à message pour un service.. Mais dans la mesure ou un service n'est pas dépendant d'une fenêtre, je pense que cela n'est pas initialement prévu lorsque tu crées un service.

Maintenant, il me semble tout à fait possible qu'un service puisse réagir à des notifications venant de "matériel"..

Il te faudrait peut-etre investiguer d'avantage du coté de la DLL qui te fournit les notifications pour savoir quel moyen elle utilise pour le faire. Il y a fort à parier, vu le comportement que tu n'as pas en console, que cette DLL envoie un message Windows (SendMessage) à son parent.. Et évidemment, si c'est cette situation la qui a lieu, il sera logique qu'une application console ne "reçoive" pas cet événement.

Après, quelles solutions de contournement... Je dirais, si tu fais le barbare, que ton application Console pourrait embarquée une fenêtre non visible qui "catchera" les notifications... (c'est du barbare, mais çà de permettrait rapidement de valider que la source du non fonctionnement est bien lié à ce comportement de pompe à message)...

The Monz, Toulouse