J'ai d=E9velopp=E9 un service windows qui me permet d'afficher des
messages envoy=E9s depuis un autre poste.
En gros, mon service =E9coute sur un port, d=E8s qu'il re=E7oit un
message, il l'affiche.
Au d=E9part, pour l'affichage j'utilisais un b=EAte messagebox, et =E7a
marchait sans probl=E8me.
Mais depuis, j'ai voulu am=E9liorer mon affichage. J'ai donc cr=E9=E9 une
form et c'est celle-ci que je tente d'afficher =E0 la place de mon
messagebox. Et c'est l=E0 qu'est l'os !!
Ma form ne s'affiche pas. Enfin, si, mais j'ai le contour de ma form,
mais pas son contenu. Comme si le Paint ne se faisait pas.
L=E0, je s=E8che completement. Quelqu'un aurait-il une solution, une
id=E9e, une piste ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Mehdi
On 29 Jun 2006 08:46:47 -0700, YB wrote:
J'ai développé un service windows qui me permet d'afficher des messages envoyés depuis un autre poste. En gros, mon service écoute sur un port, dès qu'il reçoit un message, il l'affiche. Au départ, pour l'affichage j'utilisais un bête messagebox, et ça marchait sans problème.
Mais depuis, j'ai voulu améliorer mon affichage. J'ai donc créé une form et c'est celle-ci que je tente d'afficher à la place de mon messagebox. Et c'est là qu'est l'os !! Ma form ne s'affiche pas. Enfin, si, mais j'ai le contour de ma form, mais pas son contenu. Comme si le Paint ne se faisait pas.
Là, je sèche completement. Quelqu'un aurait-il une solution, une idée, une piste ?
2 problemes: - un service Windows ne doit *jamais* (enfin sauf a fin de débugage et encore) avoir d'interface utilisateur. Afficher une interface utilisateur depuis un service Windows pose de nombreux problemes, y compris de tres gros problemes de sécurité.
- Services Windows mis a part, les controles utilisateurs (c'est a dire tout ce qui dérive de la classe Control, Form y compris) ne doivent etre accédés que depuis le thread de l'interface utilisateur (UI Thread), c'est a dire celui ou les controles ont été crées. Dans le cas d'une appli windows normale, il s'agit en général du thread ou s'execute la fonction Main. Tente d'acceder a un controle utilisateur depuis un autre thread et c'est freeze et crash incompréhensibles arrivant au petit bonheur la chance comme tu a pu le constater. Dans ton cas, les messages arrivant du réseau sont sans doute traités dans un thread tiré d'un Thread Pool et donc pas dans le thread de l'UI. Il te faut donc marshaller dans le thread de l'UI tous les appels aux fonctions et propriétés de controles utilisateurs en utilisant les fonctions Control.Invoke ou Control.BeginInvoke (cherche sur google control multi-threading UI thread marshalling Control.Invoke etc, tu trouvera plein d'exemples).
La maniere propre de faire ce que tu veux faire est d'avoir une seconde application, application Windows normale cette fois, qui se charge d'afficher les messages recus par ton service windows. Cette application devra démarrer automtiquement lorsqu'un utilisateur se logge sous Windows et communiquera avec ton service via .NET Remoting, une socket ou toute autre moyen que tu juges approprié.
On 29 Jun 2006 08:46:47 -0700, YB wrote:
J'ai développé un service windows qui me permet d'afficher des
messages envoyés depuis un autre poste.
En gros, mon service écoute sur un port, dès qu'il reçoit un
message, il l'affiche.
Au départ, pour l'affichage j'utilisais un bête messagebox, et ça
marchait sans problème.
Mais depuis, j'ai voulu améliorer mon affichage. J'ai donc créé une
form et c'est celle-ci que je tente d'afficher à la place de mon
messagebox. Et c'est là qu'est l'os !!
Ma form ne s'affiche pas. Enfin, si, mais j'ai le contour de ma form,
mais pas son contenu. Comme si le Paint ne se faisait pas.
Là, je sèche completement. Quelqu'un aurait-il une solution, une
idée, une piste ?
2 problemes:
- un service Windows ne doit *jamais* (enfin sauf a fin de débugage et
encore) avoir d'interface utilisateur. Afficher une interface utilisateur
depuis un service Windows pose de nombreux problemes, y compris de tres
gros problemes de sécurité.
- Services Windows mis a part, les controles utilisateurs (c'est a dire
tout ce qui dérive de la classe Control, Form y compris) ne doivent etre
accédés que depuis le thread de l'interface utilisateur (UI Thread), c'est
a dire celui ou les controles ont été crées. Dans le cas d'une appli
windows normale, il s'agit en général du thread ou s'execute la fonction
Main. Tente d'acceder a un controle utilisateur depuis un autre thread et
c'est freeze et crash incompréhensibles arrivant au petit bonheur la chance
comme tu a pu le constater. Dans ton cas, les messages arrivant du réseau
sont sans doute traités dans un thread tiré d'un Thread Pool et donc pas
dans le thread de l'UI. Il te faut donc marshaller dans le thread de l'UI
tous les appels aux fonctions et propriétés de controles utilisateurs en
utilisant les fonctions Control.Invoke ou Control.BeginInvoke (cherche sur
google control multi-threading UI thread marshalling Control.Invoke etc, tu
trouvera plein d'exemples).
La maniere propre de faire ce que tu veux faire est d'avoir une seconde
application, application Windows normale cette fois, qui se charge
d'afficher les messages recus par ton service windows. Cette application
devra démarrer automtiquement lorsqu'un utilisateur se logge sous Windows
et communiquera avec ton service via .NET Remoting, une socket ou toute
autre moyen que tu juges approprié.
J'ai développé un service windows qui me permet d'afficher des messages envoyés depuis un autre poste. En gros, mon service écoute sur un port, dès qu'il reçoit un message, il l'affiche. Au départ, pour l'affichage j'utilisais un bête messagebox, et ça marchait sans problème.
Mais depuis, j'ai voulu améliorer mon affichage. J'ai donc créé une form et c'est celle-ci que je tente d'afficher à la place de mon messagebox. Et c'est là qu'est l'os !! Ma form ne s'affiche pas. Enfin, si, mais j'ai le contour de ma form, mais pas son contenu. Comme si le Paint ne se faisait pas.
Là, je sèche completement. Quelqu'un aurait-il une solution, une idée, une piste ?
2 problemes: - un service Windows ne doit *jamais* (enfin sauf a fin de débugage et encore) avoir d'interface utilisateur. Afficher une interface utilisateur depuis un service Windows pose de nombreux problemes, y compris de tres gros problemes de sécurité.
- Services Windows mis a part, les controles utilisateurs (c'est a dire tout ce qui dérive de la classe Control, Form y compris) ne doivent etre accédés que depuis le thread de l'interface utilisateur (UI Thread), c'est a dire celui ou les controles ont été crées. Dans le cas d'une appli windows normale, il s'agit en général du thread ou s'execute la fonction Main. Tente d'acceder a un controle utilisateur depuis un autre thread et c'est freeze et crash incompréhensibles arrivant au petit bonheur la chance comme tu a pu le constater. Dans ton cas, les messages arrivant du réseau sont sans doute traités dans un thread tiré d'un Thread Pool et donc pas dans le thread de l'UI. Il te faut donc marshaller dans le thread de l'UI tous les appels aux fonctions et propriétés de controles utilisateurs en utilisant les fonctions Control.Invoke ou Control.BeginInvoke (cherche sur google control multi-threading UI thread marshalling Control.Invoke etc, tu trouvera plein d'exemples).
La maniere propre de faire ce que tu veux faire est d'avoir une seconde application, application Windows normale cette fois, qui se charge d'afficher les messages recus par ton service windows. Cette application devra démarrer automtiquement lorsqu'un utilisateur se logge sous Windows et communiquera avec ton service via .NET Remoting, une socket ou toute autre moyen que tu juges approprié.
YB
Bonjour,
Passer par un exe était ma solution de secours. Je vais donc partir là dessus. Merci beaucoup pour ta réponse.
Yann
Mehdi a écrit :
On 29 Jun 2006 08:46:47 -0700, YB wrote:
> J'ai développé un service windows qui me permet d'afficher des > messages envoyés depuis un autre poste. > En gros, mon service écoute sur un port, dès qu'il reçoit un > message, il l'affiche. > Au départ, pour l'affichage j'utilisais un bête messagebox, et ça > marchait sans problème. > > Mais depuis, j'ai voulu améliorer mon affichage. J'ai donc créé u ne > form et c'est celle-ci que je tente d'afficher à la place de mon > messagebox. Et c'est là qu'est l'os !! > Ma form ne s'affiche pas. Enfin, si, mais j'ai le contour de ma form, > mais pas son contenu. Comme si le Paint ne se faisait pas. > > Là, je sèche completement. Quelqu'un aurait-il une solution, une > idée, une piste ?
2 problemes: - un service Windows ne doit *jamais* (enfin sauf a fin de débugage et encore) avoir d'interface utilisateur. Afficher une interface utilisateur depuis un service Windows pose de nombreux problemes, y compris de tres gros problemes de sécurité.
- Services Windows mis a part, les controles utilisateurs (c'est a dire tout ce qui dérive de la classe Control, Form y compris) ne doivent etre accédés que depuis le thread de l'interface utilisateur (UI Thread), c'est a dire celui ou les controles ont été crées. Dans le cas d'une appli windows normale, il s'agit en général du thread ou s'execute la fonct ion Main. Tente d'acceder a un controle utilisateur depuis un autre thread et c'est freeze et crash incompréhensibles arrivant au petit bonheur la ch ance comme tu a pu le constater. Dans ton cas, les messages arrivant du rése au sont sans doute traités dans un thread tiré d'un Thread Pool et donc pas dans le thread de l'UI. Il te faut donc marshaller dans le thread de l'UI tous les appels aux fonctions et propriétés de controles utilisateurs en utilisant les fonctions Control.Invoke ou Control.BeginInvoke (cherche sur google control multi-threading UI thread marshalling Control.Invoke etc, tu trouvera plein d'exemples).
La maniere propre de faire ce que tu veux faire est d'avoir une seconde application, application Windows normale cette fois, qui se charge d'afficher les messages recus par ton service windows. Cette application devra démarrer automtiquement lorsqu'un utilisateur se logge sous Windo ws et communiquera avec ton service via .NET Remoting, une socket ou toute autre moyen que tu juges approprié.
Bonjour,
Passer par un exe était ma solution de secours. Je vais donc partir
là dessus.
Merci beaucoup pour ta réponse.
Yann
Mehdi a écrit :
On 29 Jun 2006 08:46:47 -0700, YB wrote:
> J'ai développé un service windows qui me permet d'afficher des
> messages envoyés depuis un autre poste.
> En gros, mon service écoute sur un port, dès qu'il reçoit un
> message, il l'affiche.
> Au départ, pour l'affichage j'utilisais un bête messagebox, et ça
> marchait sans problème.
>
> Mais depuis, j'ai voulu améliorer mon affichage. J'ai donc créé u ne
> form et c'est celle-ci que je tente d'afficher à la place de mon
> messagebox. Et c'est là qu'est l'os !!
> Ma form ne s'affiche pas. Enfin, si, mais j'ai le contour de ma form,
> mais pas son contenu. Comme si le Paint ne se faisait pas.
>
> Là, je sèche completement. Quelqu'un aurait-il une solution, une
> idée, une piste ?
2 problemes:
- un service Windows ne doit *jamais* (enfin sauf a fin de débugage et
encore) avoir d'interface utilisateur. Afficher une interface utilisateur
depuis un service Windows pose de nombreux problemes, y compris de tres
gros problemes de sécurité.
- Services Windows mis a part, les controles utilisateurs (c'est a dire
tout ce qui dérive de la classe Control, Form y compris) ne doivent etre
accédés que depuis le thread de l'interface utilisateur (UI Thread), c'est
a dire celui ou les controles ont été crées. Dans le cas d'une appli
windows normale, il s'agit en général du thread ou s'execute la fonct ion
Main. Tente d'acceder a un controle utilisateur depuis un autre thread et
c'est freeze et crash incompréhensibles arrivant au petit bonheur la ch ance
comme tu a pu le constater. Dans ton cas, les messages arrivant du rése au
sont sans doute traités dans un thread tiré d'un Thread Pool et donc pas
dans le thread de l'UI. Il te faut donc marshaller dans le thread de l'UI
tous les appels aux fonctions et propriétés de controles utilisateurs en
utilisant les fonctions Control.Invoke ou Control.BeginInvoke (cherche sur
google control multi-threading UI thread marshalling Control.Invoke etc, tu
trouvera plein d'exemples).
La maniere propre de faire ce que tu veux faire est d'avoir une seconde
application, application Windows normale cette fois, qui se charge
d'afficher les messages recus par ton service windows. Cette application
devra démarrer automtiquement lorsqu'un utilisateur se logge sous Windo ws
et communiquera avec ton service via .NET Remoting, une socket ou toute
autre moyen que tu juges approprié.
Passer par un exe était ma solution de secours. Je vais donc partir là dessus. Merci beaucoup pour ta réponse.
Yann
Mehdi a écrit :
On 29 Jun 2006 08:46:47 -0700, YB wrote:
> J'ai développé un service windows qui me permet d'afficher des > messages envoyés depuis un autre poste. > En gros, mon service écoute sur un port, dès qu'il reçoit un > message, il l'affiche. > Au départ, pour l'affichage j'utilisais un bête messagebox, et ça > marchait sans problème. > > Mais depuis, j'ai voulu améliorer mon affichage. J'ai donc créé u ne > form et c'est celle-ci que je tente d'afficher à la place de mon > messagebox. Et c'est là qu'est l'os !! > Ma form ne s'affiche pas. Enfin, si, mais j'ai le contour de ma form, > mais pas son contenu. Comme si le Paint ne se faisait pas. > > Là, je sèche completement. Quelqu'un aurait-il une solution, une > idée, une piste ?
2 problemes: - un service Windows ne doit *jamais* (enfin sauf a fin de débugage et encore) avoir d'interface utilisateur. Afficher une interface utilisateur depuis un service Windows pose de nombreux problemes, y compris de tres gros problemes de sécurité.
- Services Windows mis a part, les controles utilisateurs (c'est a dire tout ce qui dérive de la classe Control, Form y compris) ne doivent etre accédés que depuis le thread de l'interface utilisateur (UI Thread), c'est a dire celui ou les controles ont été crées. Dans le cas d'une appli windows normale, il s'agit en général du thread ou s'execute la fonct ion Main. Tente d'acceder a un controle utilisateur depuis un autre thread et c'est freeze et crash incompréhensibles arrivant au petit bonheur la ch ance comme tu a pu le constater. Dans ton cas, les messages arrivant du rése au sont sans doute traités dans un thread tiré d'un Thread Pool et donc pas dans le thread de l'UI. Il te faut donc marshaller dans le thread de l'UI tous les appels aux fonctions et propriétés de controles utilisateurs en utilisant les fonctions Control.Invoke ou Control.BeginInvoke (cherche sur google control multi-threading UI thread marshalling Control.Invoke etc, tu trouvera plein d'exemples).
La maniere propre de faire ce que tu veux faire est d'avoir une seconde application, application Windows normale cette fois, qui se charge d'afficher les messages recus par ton service windows. Cette application devra démarrer automtiquement lorsqu'un utilisateur se logge sous Windo ws et communiquera avec ton service via .NET Remoting, une socket ou toute autre moyen que tu juges approprié.
