Ce message n'est pas urgent, c'est juste que je m'interroge sur une manière
de programmer avec BeginInvoke.
Je me suis penché récement sur des traitements longs avec indication de
progression à l'utilisateur. Ma classe de traitement bloquant l'application,
je l'ai modifier pour qu'elle crée un thread pour faire son boulot bien
tranquillement. Cependant cela posait un problème car les événements de
progression sont appellés dans le même thread. Hors on ne peut modifier un
control graphique (une barre de progression par exemple) que dans le thread
qui l'a créer. Solution : BeginInvoke. Mes méthodes internes onXXXX sont
maintenant appellé par des BeginInvoke et les évenement sont donc bien
déclancher dans le thread d'origine.
Pour cela, et c'est mon petit soucis, j'ai du faire hériter ma classe de
Control (d'aprés ce que j'ai compris c'est parce que BeginInvoque à besoin
d'un handle de fenêtre).... Ce qui m'ammene à me demander si c'est
obligatoire car en fin de compte ma classe n'a rien avoir avec un control
graphique. En conséquence de quoi elle ne peut pas être utilisé dans un
context différent (sans fenêtre).
J'aimerais éviter la solution étant de la décomposer en 2 parties (execution
et control servant d'interface) car dans un environement non graphique je
pourrais vouloir être averti de la progression dans le thread principal (sans
que ce soit pour la mise à jour de controle graphique).
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
Paul Bacelar
L'article ci-dessous aborde le timer mais permet par la même occasion de voir les différentes méthodes asynchrones dont l'utilisation du pool de thread et rendre les appels de callbacks sur quelques soit le type thread qui exécute le callback.
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/default.aspx -- Paul Bacelar
"Yaume" wrote in message news:
Hello,
Ce message n'est pas urgent, c'est juste que je m'interroge sur une
manière
de programmer avec BeginInvoke.
Je me suis penché récement sur des traitements longs avec indication de progression à l'utilisateur. Ma classe de traitement bloquant
l'application,
je l'ai modifier pour qu'elle crée un thread pour faire son boulot bien tranquillement. Cependant cela posait un problème car les événements de progression sont appellés dans le même thread. Hors on ne peut modifier un control graphique (une barre de progression par exemple) que dans le
thread
qui l'a créer. Solution : BeginInvoke. Mes méthodes internes onXXXX sont maintenant appellé par des BeginInvoke et les évenement sont donc bien déclancher dans le thread d'origine.
Pour cela, et c'est mon petit soucis, j'ai du faire hériter ma classe de Control (d'aprés ce que j'ai compris c'est parce que BeginInvoque à besoin d'un handle de fenêtre).... Ce qui m'ammene à me demander si c'est obligatoire car en fin de compte ma classe n'a rien avoir avec un control graphique. En conséquence de quoi elle ne peut pas être utilisé dans un context différent (sans fenêtre).
J'aimerais éviter la solution étant de la décomposer en 2 parties
(execution
et control servant d'interface) car dans un environement non graphique je pourrais vouloir être averti de la progression dans le thread principal
(sans
que ce soit pour la mise à jour de controle graphique).
Quand pensez-vous ?
L'article ci-dessous aborde le timer mais permet par la même occasion de
voir les différentes méthodes asynchrones dont l'utilisation du pool de
thread et rendre les appels de callbacks sur quelques soit le type thread
qui exécute le callback.
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/default.aspx
--
Paul Bacelar
"Yaume" <Yaume@discussions.microsoft.com> wrote in message
news:421714CD-A13E-489A-B0F9-0B51A070C8F9@microsoft.com...
Hello,
Ce message n'est pas urgent, c'est juste que je m'interroge sur une
manière
de programmer avec BeginInvoke.
Je me suis penché récement sur des traitements longs avec indication de
progression à l'utilisateur. Ma classe de traitement bloquant
l'application,
je l'ai modifier pour qu'elle crée un thread pour faire son boulot bien
tranquillement. Cependant cela posait un problème car les événements de
progression sont appellés dans le même thread. Hors on ne peut modifier un
control graphique (une barre de progression par exemple) que dans le
thread
qui l'a créer. Solution : BeginInvoke. Mes méthodes internes onXXXX sont
maintenant appellé par des BeginInvoke et les évenement sont donc bien
déclancher dans le thread d'origine.
Pour cela, et c'est mon petit soucis, j'ai du faire hériter ma classe de
Control (d'aprés ce que j'ai compris c'est parce que BeginInvoque à besoin
d'un handle de fenêtre).... Ce qui m'ammene à me demander si c'est
obligatoire car en fin de compte ma classe n'a rien avoir avec un control
graphique. En conséquence de quoi elle ne peut pas être utilisé dans un
context différent (sans fenêtre).
J'aimerais éviter la solution étant de la décomposer en 2 parties
(execution
et control servant d'interface) car dans un environement non graphique je
pourrais vouloir être averti de la progression dans le thread principal
(sans
que ce soit pour la mise à jour de controle graphique).
L'article ci-dessous aborde le timer mais permet par la même occasion de voir les différentes méthodes asynchrones dont l'utilisation du pool de thread et rendre les appels de callbacks sur quelques soit le type thread qui exécute le callback.
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/default.aspx -- Paul Bacelar
"Yaume" wrote in message news:
Hello,
Ce message n'est pas urgent, c'est juste que je m'interroge sur une
manière
de programmer avec BeginInvoke.
Je me suis penché récement sur des traitements longs avec indication de progression à l'utilisateur. Ma classe de traitement bloquant
l'application,
je l'ai modifier pour qu'elle crée un thread pour faire son boulot bien tranquillement. Cependant cela posait un problème car les événements de progression sont appellés dans le même thread. Hors on ne peut modifier un control graphique (une barre de progression par exemple) que dans le
thread
qui l'a créer. Solution : BeginInvoke. Mes méthodes internes onXXXX sont maintenant appellé par des BeginInvoke et les évenement sont donc bien déclancher dans le thread d'origine.
Pour cela, et c'est mon petit soucis, j'ai du faire hériter ma classe de Control (d'aprés ce que j'ai compris c'est parce que BeginInvoque à besoin d'un handle de fenêtre).... Ce qui m'ammene à me demander si c'est obligatoire car en fin de compte ma classe n'a rien avoir avec un control graphique. En conséquence de quoi elle ne peut pas être utilisé dans un context différent (sans fenêtre).
J'aimerais éviter la solution étant de la décomposer en 2 parties
(execution
et control servant d'interface) car dans un environement non graphique je pourrais vouloir être averti de la progression dans le thread principal
(sans
que ce soit pour la mise à jour de controle graphique).
Quand pensez-vous ?
Yaume
Merci, C'était pas exactement ce que je voulais mais c'est trés intéressant quand même.
"Paul Bacelar" a écrit :
L'article ci-dessous aborde le timer mais permet par la même occasion de voir les différentes méthodes asynchrones dont l'utilisation du pool de thread et rendre les appels de callbacks sur quelques soit le type thread qui exécute le callback.
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/default.aspx -- Paul Bacelar
"Yaume" wrote in message news: > Hello, > > Ce message n'est pas urgent, c'est juste que je m'interroge sur une manière > de programmer avec BeginInvoke. > > Je me suis penché récement sur des traitements longs avec indication de > progression à l'utilisateur. Ma classe de traitement bloquant l'application, > je l'ai modifier pour qu'elle crée un thread pour faire son boulot bien > tranquillement. Cependant cela posait un problème car les événements de > progression sont appellés dans le même thread. Hors on ne peut modifier un > control graphique (une barre de progression par exemple) que dans le thread > qui l'a créer. Solution : BeginInvoke. Mes méthodes internes onXXXX sont > maintenant appellé par des BeginInvoke et les évenement sont donc bien > déclancher dans le thread d'origine. > > Pour cela, et c'est mon petit soucis, j'ai du faire hériter ma classe de > Control (d'aprés ce que j'ai compris c'est parce que BeginInvoque à besoin > d'un handle de fenêtre).... Ce qui m'ammene à me demander si c'est > obligatoire car en fin de compte ma classe n'a rien avoir avec un control > graphique. En conséquence de quoi elle ne peut pas être utilisé dans un > context différent (sans fenêtre). > > J'aimerais éviter la solution étant de la décomposer en 2 parties (execution > et control servant d'interface) car dans un environement non graphique je > pourrais vouloir être averti de la progression dans le thread principal (sans > que ce soit pour la mise à jour de controle graphique). > > Quand pensez-vous ?
Merci,
C'était pas exactement ce que je voulais mais c'est trés intéressant quand
même.
"Paul Bacelar" a écrit :
L'article ci-dessous aborde le timer mais permet par la même occasion de
voir les différentes méthodes asynchrones dont l'utilisation du pool de
thread et rendre les appels de callbacks sur quelques soit le type thread
qui exécute le callback.
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/default.aspx
--
Paul Bacelar
"Yaume" <Yaume@discussions.microsoft.com> wrote in message
news:421714CD-A13E-489A-B0F9-0B51A070C8F9@microsoft.com...
> Hello,
>
> Ce message n'est pas urgent, c'est juste que je m'interroge sur une
manière
> de programmer avec BeginInvoke.
>
> Je me suis penché récement sur des traitements longs avec indication de
> progression à l'utilisateur. Ma classe de traitement bloquant
l'application,
> je l'ai modifier pour qu'elle crée un thread pour faire son boulot bien
> tranquillement. Cependant cela posait un problème car les événements de
> progression sont appellés dans le même thread. Hors on ne peut modifier un
> control graphique (une barre de progression par exemple) que dans le
thread
> qui l'a créer. Solution : BeginInvoke. Mes méthodes internes onXXXX sont
> maintenant appellé par des BeginInvoke et les évenement sont donc bien
> déclancher dans le thread d'origine.
>
> Pour cela, et c'est mon petit soucis, j'ai du faire hériter ma classe de
> Control (d'aprés ce que j'ai compris c'est parce que BeginInvoque à besoin
> d'un handle de fenêtre).... Ce qui m'ammene à me demander si c'est
> obligatoire car en fin de compte ma classe n'a rien avoir avec un control
> graphique. En conséquence de quoi elle ne peut pas être utilisé dans un
> context différent (sans fenêtre).
>
> J'aimerais éviter la solution étant de la décomposer en 2 parties
(execution
> et control servant d'interface) car dans un environement non graphique je
> pourrais vouloir être averti de la progression dans le thread principal
(sans
> que ce soit pour la mise à jour de controle graphique).
>
> Quand pensez-vous ?
Merci, C'était pas exactement ce que je voulais mais c'est trés intéressant quand même.
"Paul Bacelar" a écrit :
L'article ci-dessous aborde le timer mais permet par la même occasion de voir les différentes méthodes asynchrones dont l'utilisation du pool de thread et rendre les appels de callbacks sur quelques soit le type thread qui exécute le callback.
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/default.aspx -- Paul Bacelar
"Yaume" wrote in message news: > Hello, > > Ce message n'est pas urgent, c'est juste que je m'interroge sur une manière > de programmer avec BeginInvoke. > > Je me suis penché récement sur des traitements longs avec indication de > progression à l'utilisateur. Ma classe de traitement bloquant l'application, > je l'ai modifier pour qu'elle crée un thread pour faire son boulot bien > tranquillement. Cependant cela posait un problème car les événements de > progression sont appellés dans le même thread. Hors on ne peut modifier un > control graphique (une barre de progression par exemple) que dans le thread > qui l'a créer. Solution : BeginInvoke. Mes méthodes internes onXXXX sont > maintenant appellé par des BeginInvoke et les évenement sont donc bien > déclancher dans le thread d'origine. > > Pour cela, et c'est mon petit soucis, j'ai du faire hériter ma classe de > Control (d'aprés ce que j'ai compris c'est parce que BeginInvoque à besoin > d'un handle de fenêtre).... Ce qui m'ammene à me demander si c'est > obligatoire car en fin de compte ma classe n'a rien avoir avec un control > graphique. En conséquence de quoi elle ne peut pas être utilisé dans un > context différent (sans fenêtre). > > J'aimerais éviter la solution étant de la décomposer en 2 parties (execution > et control servant d'interface) car dans un environement non graphique je > pourrais vouloir être averti de la progression dans le thread principal (sans > que ce soit pour la mise à jour de controle graphique). > > Quand pensez-vous ?
