Commentaires de cbeyls sur csharpfr

CodeS-SourceS est h�berg� par Frontier.fr

Ce site au d�marrage

AccueilCodesTutorielsForumsEmploiLivresConnexion

begin process at 2008 11 23 17:52:49

XBOX 360 : NOUVELLE INTERFACE DE LA XBOX par ROMELARD Fabrice

ADD-IN REFLECTOR : EXCEPTIONFINDER FOR REFLECTOR par coq

TUTORIAUX EF par Matthieu MEZIL

CODEPLEX : SEADRAGON AJAX INTELLISENSE HELPER par nicoboo

VS2008 ET LE MESSAGE "UNABLE TO START DEBUGGING FOR [YOUR EXE]" par jay

RE : DIRECTX OBJET TRANSPARENT ! par bubbathemaster

RE : MATH par bubbathemaster

RE : JOURNAL DES EXCEPTIONS DOTNET par coq

RE : SHUTDOWN ET WINDOWS VISTA par moi411

RE : COMMENT OUVRIR UN FICHIER DOC(WORD) par Robert33

+ de logiciels � t�l�charger

1�294�071 membres
127 nouveaux aujourd'hui
14�529 membres club

Trouver une ressource

Trouvez une ressource parmi 39�014 codes, 1�204�052 messages d'aide etc...

Recherche: dans [ Derni�res recherches ]

Filtre:Tous les codes.NET uniquementExclure .NET

Vous ne trouvez pas de r�ponse � votre probl�me ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question b�te, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, �a c'est une erreur !

8 commentaire(s) de cbeyls sur des sources sur csharpfr

Le : 21/02/2005 11:53:15
Source : S�RIALISATION DANS UN FICHIER XML

Je crois que tu oublies une remarque importante.

XmlSerializer est une classe de sérialisation légère qui permet de sérialiser un objet avec ses champs public. Mais les champs "private", utilisés par la logique interne d'un objet, ne sont pas sérialisés! De plus, on ne peut pas sérialiser les HashTable.

Pour une sérialisation XML complète, il faut utiliser la classe SoapFormatter.

Le : 10/02/2005 01:30:25
Source : CRC32 COMPATIBLE WINRAR ET WINZIP ( BAS� SUR LE CODE C++ DE CAPA6T )

> et pour éviter que l appli se freeze je mettais tout ça dans un thread , mais dans la fonction directement c'est beaucoup mieux !

En fait c'est mieux de le mettre dans un 2e Thread, mais dans les sources que j'ai téléchargées ici, tu fais tout dans le même. Et puis, quand tu crées un 2e Thread, il y a un problème: seul le Thread de l'interface graphique est capable de modifier l'interface graphique, donc dans un 2e Thread, la progressBar ne bougerais pas (même si je n'ai pas testé mais c'est toujours le même problème avec les interfaces graphiques WinForms). Quand un 2e Thread doit modifier l'interface graphique, il faut utiliser un delegate et différer son exécution mais bon, on va dire que c'est hors sujet! L'avantage majeur d'utiliser un 2e Thread c'est que, quand l'utilisateur clique sur la croix pour fermer le programme, le Thread graphique peut dire au 2e: Stop! Autrement dit, Thread.Abort()
Ici ce n'est pas le cas, tout se fait dans le même Thread, résultat, une fois que le calcul du CRC est commencé, impossible de l'arrêter comme ça. Alors pour l'arrêter, on pourrait ajouter une méthode Stop() à la classe, qui fait passer un booléen à false et qui permet de sortir de la boucle qui calcule le CRC. C'est juste une suggestion.

La progressBar pose un autre problème: vu la façon dont on l'utilise, la taille du fichier en bytes est passée à MaxValue qui est un int. Ca limite l'utilisation à des fichiers de maximum 2 exposant 31 bytes, autrement dit 2 gigabytes. Pour les fichiers plus gros, ça ne fonctionne pas avec cette méthode.

J'ai pour principe de toujours séparer l'interface graphique du reste du code, donc moi la progressBar je l'ai virée et je n'ai donc pas tous ces problèmes, même s'il est vrai que ça pourrait être bien de connaître le statut de la progression, mais alors via d'autres moyens comme par exemple enregistrer un callback sous la forme d'une fonction qui prend en paramètre une valeur qui représente un pourcentage de progression, par exemple.

Niveau performances, j'ai fait des tests avec plusieurs fichiers sur différents disques durs, et il me semble que la valeur idéale pour le buffer de lecture est de 16384 bytes. Ca ne va pas plus vite que 4096 bytes, mais ça consomme un peu moins de CPU. Au-delà, ça commence à ralentir donc je ne conseille pas.

Le : 09/02/2005 04:59:22
Source : CRC32 COMPATIBLE WINRAR ET WINZIP ( BAS� SUR LE CODE C++ DE CAPA6T )

J'ai encore oublié un petit détail :)

if( pBar != null )
{
   pBar.Minimum = 0;
   pBar.Maximum = (int)myStream.Length;
   pBar.Value = 0;
}

Faut mettre la valeur de la progressBar à zéro au début, voilà ;)
J'espère que tu as tout pigé, si jamais tu as des questions, n'hésite pas à me contacter.

Le : 09/02/2005 04:53:32
Source : CRC32 COMPATIBLE WINRAR ET WINZIP ( BAS� SUR LE CODE C++ DE CAPA6T )

Hello, c'est encore moi. J'ai vu que tu as changé ta source, c'est sympa. Mais j'ai encore quelques remarques.

En fait j'ai écrit une classe optimisée pour mon usage personnel en m'inspirant de ton code et d'une source en C (l'algorithme est le même, apparemment, c'est le plus rapide, en tous cas j'ai pas trouvé mieux), j'ai enlevé la progressBar, mis quelques commentaires en anglais et j'ai utilisé un Stream en entrée au lieu d'un nom de fichier. C'est un bout de ce code que je t'ai copié-collé.

Seulement, comme toi tu utilises une progressBar, il y a quelques petites choses que tu devrais changer:

1) Tout d'abord d'un point de vue purement esthétique et pratique, je ne vois pas l'intérêt du 2e paramètre, le booléen enableProgress. Si j'étais toi, je l'enlèverais et je demanderais à l'utilisateur d'attribuer la valeur null à l'argument pBar s'il ne souhaite pas de progressBar. Ensuite au lieu de tester
if(enableProgress)
tu testerais
if(pBar != null)

2) Je t'ai dit que tu n'aurais plus besoin de la variable offset, mais tu l'emploies toujours pour la progressBar. Il y a toujours moyen d'utiliser la progressBar sans cette variable, mais il faut un peu adapter ton code. Au début, remplace

long fileSize = myStream.Length;
if( enableProgress ) pBar.Maximum = ( int )fileSize + 2 ;

par

if( pBar != null )
{
   pBar.Minimum = 0;
   pBar.Maximum = (int)myStream.Length;
}

J'avoue aussi que je n'ai pas compris pourquoi tu faisais +2, normalement la taille du fichier devrait suffire. Ensuite, dans le code de la boucle, remplace:

if( enableProgress ) pBar.Value = offset ;

par

if( pBar != null )
{
   pBar.Value += readBytes;
   Application.DoEvents();
}

Le Application.DoEvents() c'est pour éviter que ton interface graphique ne plante complètement pendant le calcul du CRC32, et continue à réagir aux événements de la souris et à rester "vivante". Ceci parce que tu effectues le calcul du CRC32 dans le cadre du Thread qui s'occupe de l'affichage. Si tu n'appelles pas DoEvents() ton application est incapable de réagir à la souris ou au clic sur un bouton pendant tout le calcul ! Si tu veux éviter que quelqu'un clique sur un bouton pendant le calcul, grise les boutons ou change le pointeur en sablier avant le calcul et revient à la normale après, mais laisse le DoEvents(), ça évitera à Windows de croire que le programme est planté si tu t'acharnes à la souris dessus.

3) Dernière remarque, mais cela je suppose que tu le sais déjà, le calcul est plus rapide lorsque le code est compilé en mode Release par rapport au mode Debug.

Le : 04/02/2005 19:26:14
Source : CRC32 COMPATIBLE WINRAR ET WINZIP ( BAS� SUR LE CODE C++ DE CAPA6T )

petites précisions:
- j'ai donc déclaré readBytes en tant que int juste avant cette boucle.
- BUFFER_SIZE est une constante qui est la taille du buffer, dans ton exemple c'était 4096 mais personnellement je l'ai augmentée à 16384.

Le : 04/02/2005 19:18:25
Source : CRC32 COMPATIBLE WINRAR ET WINZIP ( BAS� SUR LE CODE C++ DE CAPA6T )

Pour la lecture, ceci devrait suffire et plus besoin des variables offset, ni diff, ni fileSize:

            // Read the Stream to its end and fill the buffer
            while( ( readBytes = stream.Read(buffer, 0, BUFFER_SIZE) ) != 0 )
            {
                // Compute the new CRC32 for the current buffer content
                for(int i=0; i < readBytes; ++i)
                {
                    crc32 = ( crc32 >> 8 ) ^ lookupTable[ ( crc32 & 0xFF ) ^ buffer[i] ];
                }
            }

Le : 04/02/2005 15:27:01
Source : CRC32 COMPATIBLE WINRAR ET WINZIP ( BAS� SUR LE CODE C++ DE CAPA6T )

Pour les ToString(), effectivement je n'avais pas fait attention au fait que la portion de code est commentée :)

Par contre, pour la lecture, je comprend ce que tu veux faire mais je t'explique que ce n'est pas la bonne façon de faire. Si tu demandes à lire 4096 bytes dans un Stream, tu peux très bien te retrouver par exemple avec 4090 bytes même si tu en as demandé 4096 et qu'il reste plus de 4096 bytes à lire, il faut donc toujours tester quel est le nombre de bytes que la fonction Read renvoie. Je posterai le code correct plus tard dans la journée.

Le : 04/02/2005 05:48:40
Source : CRC32 COMPATIBLE WINRAR ET WINZIP ( BAS� SUR LE CODE C++ DE CAPA6T )

Les ToString() pendant la création de la lookup table, ça me paraît totalement farfelu!

De plus, tu pourrais générer la table uniquement la première fois que la fonction est appelée et ensuite la laisser en mémoire, pour gagner un peu de temps lors des appels suivants à la méthode.

Quant à la lecture dans le fichier, tu peux la faire directement avec

int bytesLus = myStream.Read( byteArray , 0 , 4096 );

sans calculer la taille restate auparavant. La méthode Read renvoie le nombre de bytes effectivement lus. Attention, elle peut très bien en renvoyer moins que la taille du buffer même si on n'est pas à la fin du fichier! (même si c'est très improbable). C'est écrit dans la documentation du SDK:

Stream.Read: Valeur de retour: Nombre total d'octets lus dans la mémoire tampon. Cela peut être inférieur au nombre d'octets demandé si ce nombre n'est pas actuellement disponible ou égal à zéro (0) si la fin du flux a été atteinte.