Delegate asynchrone - Mise à jour progress bar

Le
teetof
Bonjour je dcouvre depuis peu l'interet des delegates et leur
fontctionnement en asynchrone
En rsum : j'ai une solution sous VS2008 avec 2 projets
distincts ; un projet grant l'UI et l'autre la couche DAL .
Dans UI jai une form et sur cette derniere lorsque l'utilisateur
clique sur un bouton, il dclenche une succession de scripts SQL
(stocks dans un fichier) . Je laisse grer l'execution de ces scripts
par la DAL (qui ne refrence pas du tout mon projet UI). Schma :

UI
onclick : ExecuteTraitementBDD () --> le traitement peut
etre long

DAL:
ExecuteTraitementBDD :
traitement 1
traitement 2
et..(la boucle sur les scripts..)
pour chaque scriptsql faire :
ExecSQL(scripti)
FinExecuteTraitementBDD

Je souhaiterai que dans ma form UI ,faire progresser ma "progressbar"
aprs chaque ExecSQL(script). J'ai donc commenc coder un dlg=
u
cot UI en asynchrone (avec une fonction de callback qui mettait
jour ma progress bar). Le dlgu dclenchait donc
ExecuteTraitementBDD. Mais cela ne fonctionne pas puisque le callback
est uniquement appel la fin de ExecuteTraitementBDD (ce qui est
logique).
- Comment faire pour maj ma progressbar chaque itration de la
boucle , l'interieur de ExecuteTraitementBDD ?
Je prcise que je ne peux bien sur pas "dporter" tout le code de
ExecuteTraitement dans l'UI pour dclencher le dlgu uniquement s=
ur
ExecSQL (vous me suivez ?) car traitement1 et traitement2 font
aussi appel d'autre code de la DAL.
Bref ..je tourne un peu en rond.
Si qqun peu m'aiguiller j'en serai reconnaissant

Merci
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jérémy Jeanson
Le #19200711
Bonjour Teetof,

Je pense que le BackGroundWorker peut être très pratique dans ton cas.
Voici le lien vers la doc :
http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker_methods.aspx

Tu pourrais très bien envisager de la passer comme argument de ta
méthode d'appel de ta DAL et le piloter via celle-ci. Le
BackGroundWorker étant très facile à mettre en place je pense que tu y
gagneras pas mal de temps et ceux sans alourdir ta couche d'accès au
données.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
teetof
Le #19209051
On 27 avr, 08:21, Jérémy Jeanson
Bonjour Teetof,

Je pense que le BackGroundWorker peut être très pratique dans ton cas .
Voici le lien vers la doc :http://msdn.microsoft.com/en-us/library/system .componentmodel.backgro...

Tu pourrais très bien envisager de la passer comme argument de ta
méthode d'appel de taDALet le piloter via celle-ci. Le
BackGroundWorker étant très facile à mettre en place je pense que t u y
gagneras pas mal de temps et ceux sans alourdir ta couche d'accès au
données.
--
Jérémy JEANSON
MCPhttp://www.jjeanson.fr



Bonjour ,
merçi bcp pour cet "aiguillage", je ne connaissais pas cette classe
trés pratique !
J'ai résolu mon soucis.
Encore une fois, avant de coder, bien regarder dans le framework ;)
Cdt;
Richard Clark
Le #19215701
Je te conseille de jeter un coup d'oeil sur les webcasts d'Eric Vernier. Le
backgroundworker est expliqué mais aussi plein d'autres choses tres
intéressantes :
http://msdn.microsoft.com/fr-fr/vcsharp/dd582579.aspx

Richard Clark
http://www.c2i.fr
Le 1er site .NET Francophone

news:
On 27 avr, 08:21, Jérémy Jeanson
Bonjour Teetof,

Je pense que le BackGroundWorker peut être très pratique dans ton cas.
Voici le lien vers la doc
:http://msdn.microsoft.com/en-us/library/system.componentmodel.backgro...

Tu pourrais très bien envisager de la passer comme argument de ta
méthode d'appel de taDALet le piloter via celle-ci. Le
BackGroundWorker étant très facile à mettre en place je pense que tu y
gagneras pas mal de temps et ceux sans alourdir ta couche d'accès au
données.
--
Jérémy JEANSON
MCPhttp://www.jjeanson.fr



Bonjour ,
merçi bcp pour cet "aiguillage", je ne connaissais pas cette classe
trés pratique !
J'ai résolu mon soucis.
Encore une fois, avant de coder, bien regarder dans le framework ;)
Cdt;
Publicité
Poster une réponse
Anonyme