Discussion :

[sinople]

Hello

J'ai remarqué quelque chose d'étrange avec le contrôle MonthCalendar. En effet lors d'un click sur les 2 boutons de défilement des mois, l'evenement Datechanged est lancé deux fois.

Ceci est en soit ne me cause pas trop de problème, mais si je peux éviter de lancer des routines de calculs à double, les performances ne peuvent que s'améliorer! Connaissez-vous donc une technique pour éviter ce comportement?

Au passage l'évenement DateSelected n'est pas lancé ce qui rend l'utilisation de cet evenement foireux pour vérifier un changement de date Et je ne recommande pas l'utilisation d'un MessageBox dans l'evenement (utilisez console.writeline....) sous peine d'un gros bug.

Si l'on ajoute le fait que j'ai aussi des bugs d'affichage graphique (la moitié du contrôle reste blanc lors d'un changement de mois jusqu'à un clique sur l'emplacement supposé d'un jour) je me demande si ce truc n'as pas un problème...

[Pol63]

le rendu doit être différent selon l'os, donc le bug d'affichage aussi
l'event raised 2x, faudrait aussi vérifier sur un autre os à tout hasard

quand à la perte de performance, tant que tu ne fais pas de calcul de météo à 10 ans dans ta sub, ca ne dérange pas spécialement
pour un ordre d'idée, une dizaine de lignes de code simples prennent en général entre quelques nanosecondes et quelques millisecondes

[sinople]

Je suis sous XP et avec le .NET 3.5 pour info.

Sinon effectivement c'est bien ça le problème c'est que le traitement du au changement de date n'est pas tout léger (un calcul financier pas tout léger et la mise à jour d'un chart). Ca ne prend pas 1 minutes (ce qui justifierait un click supplémentaire sur un bouton calculer par ex), mais entre 1 à 5 secondes, ce qui à double coupe plus que sérieusement la "fluidité" de l'application.

Bien entendu je pourais "encapsuler" le changement de date avec une propriété supplémentaire et lancer les calculs en cas de changement effectif de cette dernière (le calendrier lance 2 fois la mise à jour de la variable mais cette dernière ne changeant pas réellement de valeur la deuxième fois on peut bloquer l'évenement), mais je trouve un peu triste de devoir commencer des magouilles du genre avec un contrôle de base... (Et surtout d'avoir perdu une demi journée à cause du bug de la messagebox infinie...).

Bon je vais lancer des thread pour les nouveau calculs.

[Pol63]

xp je l'aurais parié, le problème ne doit pas être présent sur vista/7
si l'event est lancé 2x avec 2x la même date, ca ne pose pas vraiment de soucis
de plus sur un traitement long, il faut à mon avis un thread
auquel cas sur le changement de date, tu lances le thread, si la date rechange, tu annules le thread et tu le relances
comme ca les calculs sont dans tous les cas fait à temps

[sinople]

xp je l'aurais parié, le problème ne doit pas être présent sur vista/7

Le jour où j'ai enfin mon abonnement MSDN au boulot je me fait une machine virtuelle juste pour tester ça...

si l'event est lancé 2x avec 2x la même date, ca ne pose pas vraiment de soucis

En principe oui, néanmoins il faut voir le traitement qu'il y a derrière. L'exemple de la messageBox qui affiche la nouvelle date est flagrant, on se retrouve avec une ouverture en boucle de boite de dialogue à l'infini (2X j'aurais compris...).

de plus sur un traitement long, il faut à mon avis un thread
auquel cas sur le changement de date, tu lances le thread, si la date rechange, tu annules le thread et tu le relances
comme ca les calculs sont dans tous les cas fait à temps

Idéalement c'est plus la nature (parallélisme) du traitement que sa longueur qui justifie l'utilisation du multithreadisme.

Après je ne suis pas un champion de la gestion des stack de thread, même si je pense que vérifier que le paramètre d'entrée est toujours d'actualité à la fin du calcul (on vérifie à la fin du calcul parallèle que les entrées n'ont pas changé d'état) et plus propre que des .abort lançant des exceptions rendant le debbugage encore plus compliqué.

[Pol63]

Le jour où j'ai enfin mon abonnement MSDN au boulot je me fait une machine virtuelle juste pour tester ça...

on a constaté plusieurs différences visuelles entre xp et vista, et certains bugs sur xp
et surtout une grosse différence de performance, 40% de ressources processeur sur xp contre 5% sur vista

Idéalement c'est plus la nature (parallélisme) du traitement que sa longueur qui justifie l'utilisation du multithreadisme.

idéalement peut etre mais sur .net une longueur de plus d'une seconde justifie l'utilisation d'un thread, l'exécution de code sur le thread principal freeze l'interface
donc au delà d'une seconde je considère que c'est génant pour l'utilisateur ; qui au bout d'un moment pourrait être tenté de cliquer sur "fin de tache" quand on va lui dire que l'appli ne répond pas

Après je ne suis pas un champion de la gestion des stack de thread, même si je pense que vérifier que le paramètre d'entrée est toujours d'actualité à la fin du calcul (on vérifie à la fin du calcul parallèle que les entrées n'ont pas changé d'état) et plus propre que des .abort lançant des exceptions rendant le debbugage encore plus compliqué.

je ne parle pas forcément d'un .abort, il y a des moyens propres de sortir d'un thread via un booléen

[sinople]

Si tu as quelque ressources sur cette gestion du multithread, je les consulte avec grand plaisir!

En tout cas merci bien pour les retours d'expérience Vista/XP (je sens que je vais pas être content quand on va migrer...)

[Pol63]

pourquoi pas content de migrer ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
private _th as thread
private _stopthread as boolean 
 
sub date_changed(new_date as date)
  if _th isnot nothing andalso _th.isalive then
    _stopthread = true
    _th.join 'attendre ici la fin du thread
  end if
 
  _th = new thread(addressof lasub)
  _th.start
end sub

et dans ton thread tu testes le booléen assez souvent (facile dans une boucle), quand tu le vois true tu peux annuler certains trucs si nécessaire et faire exit sub, l'exit sub arrete le thread, débloquant le .join
pour les paranos, on fait .join(temps d'attente) puis .abort(temps d'attente) puis .interrupt

sinon en effet abort génère une exception reconnaissable en théorie, mais en pratique quand l'exception est déclenchée pendant un traitement dans des classes du framework ca peut foutre le bordel et on pourait légitimement penser que ca peut causer des "dégats"


sinon il y a le backgroundworker qui fournit une implémentation du cancel et du progress
en pratique il y a un booléen à setter à true si tu dis que le thread gère le cancel, un autre pour dire que le thread gère le reportprogress
ensuite le booléen d'arret est contenu dans la classe et tu peux le tester de la même manière
par contre l'avantage c'est que dans le thread tu peux faire .reportprogress(parametre as object) et ca raise un event avec le paramètre, mais sur le thread principal, permettant de mettre à jour l'interface (un progressbar ou l'ajout des données à l'écran) (car je le rappelle un thread ne peut pas modifier un controle qu'il n'a pas instancié)

[Bluedeep]

Hello

J'ai remarqué quelque chose d'étrange avec le contrôle MonthCalendar. En effet lors d'un click sur les 2 boutons de défilement des mois, l'evenement Datechanged est lancé deux fois.

Je reproduis exactement ton problème (plateforme XP SP3 & Fw 3.5 Sp1). Accessoirement, il se produit aussi si on change l'année.

Ceci dit il est assez facile à contourner.

Tu rajoutes un membre de style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
private DateRangeEventArgs _oldEventArgs;

et, si oldEventArgs est non nul, tu testes dans ton handler l'égalité des membres "Start" et "End" avec ceux de l'argument courant avant d'exécuter le code.

Sinon, le dateSelected ne semble être appelé qu'en cas de clic physique sur une des dates (donc pas en scrolling).

[sinople]

Un grand merci pour vos réponses, je crois qu'on en a assez pour le tag résolu!

je vais tenter de mettre ça en pratique, début l'année prochaine (et oui vive les échéance de noël...)

Sinon je sais déjà comment passer d'un thread à l'autre avec les delegate & Cie, mais disons que je suis ouvert à tout technique, documentation (même si c'est conceptuel) pour faire le truc le moins moche possible...

Concernant la joie du passage xp - seven c'est a propos du changement design du calendrier qui ne va pas manquer de casser le design (bien chargé) de mes formulaires.