IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

WinDev Discussion :

Bugs et erreurs de conception de WinDev


Sujet :

WinDev

  1. #161
    Membre émérite
    Homme Profil pro
    Inscrit en
    Octobre 2007
    Messages
    1 075
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 075
    Points : 2 441
    Points
    2 441
    Par défaut
    Merci frenchsting,

    Mais je m'arrête avant la création du fichier qui n'existe donc pas encore à ce moment-là.

    Comme écrit, le but initial était de ne pas utiliser HAnnuleDéclaration("CLIENT") si la description / déclaration du fichier (ou de la source de donnés etc.) n'existe pas, le comportement attendu de Windev étant de générer une erreur puisque si HDécritFichier("CLIENT") a échoué ou n'a pas été appelée suite à un test "x", la référence à "CLIENT" (qui n'existe pas) devrait générer une erreur.
    Comme, pour l'instant il n'y a pas d'erreur, il est possible d'appeler HAnnuleDéclaration("CLIENT") de manière inconditionnelle, mais il faudra tenir cela à l’œil.
    De toute manière, dans le cas qui me préoccupe, la description est utilisée au sein d'une même fenêtre et sera automatiquement annulée à la fermeture de cette dernière.
    Donc, pas vraiment de souci, sauf celui de tout contrôler plutôt que de s'abandonner aux automatismes.

    Pour la petite histoire, je n'ai pas l'intention de créer le fichier, la description d'un fichier par programmation étant en fait une voie détournée pour déclarer dynamiquement une structure.
    Apparemment, cela fonctionne impeccablement, mais cela demande encore quelques tests 'grandeur nature'.

  2. #162
    Expert éminent
    Avatar de frenchsting
    Homme Profil pro
    multitâches-multifonctions
    Inscrit en
    Juin 2003
    Messages
    5 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : multitâches-multifonctions
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 161
    Points : 9 111
    Points
    9 111
    Par défaut
    Ok, merci pour le détail. Pas bête ton système de contournement.
    Commencez toujours appuyer sur la touche F1 et puis n'hésitez à passer par un moteur de recherche...
    Le forum est fait pour répondre aux questions : pas la peine de me les envoyer par MP. Merci.

    Sur internet, tout est vrai ! Honoré de Balzac
    Make it real not fantasy... Herman Rarebell

  3. #163
    Membre expérimenté
    Inscrit en
    Août 2010
    Messages
    726
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 726
    Points : 1 645
    Points
    1 645
    Par défaut
    Encore un bug que le ST ne veut pas comprendre :
    http://forum.pcsoft.fr/fr-FR/pcsoft....alcul/read.awp

    Résumé :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    xDénominateur1 est numérique (*) = (0n1 + 0n5.5 / 0n100)
    xDénominateur2 est numérique (*) = (1 + 5.5 / 100)
    Trace(xDénominateur1)
    Trace(xDénominateur2)
    Trace(xDénominateur1 = xDénominateur2 ? "égal" SINON "différent")
    Trace(-0n1 / xDénominateur1)
    Trace(-0n1 / xDénominateur2)
    SVP, essayez de le signaler vous aussi afin de les ramener à la raison...

  4. #164
    Membre expérimenté
    Inscrit en
    Août 2010
    Messages
    726
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 726
    Points : 1 645
    Points
    1 645
    Par défaut
    Une autre erreur de conception qui est toujours là en 20 : quand un champ tiroir est replié, les champs qu'il contient sont toujours accessibles (car techniquement "visibles", même si l'utilisateur ne les voit plus grâce au clipping).
    Résultat : on peut tabuler vers ces champs, saisir des valeurs, déclencher leur code de clic... alors qu'il sont censés ne plus être là.

    Pour un utilisateur qui navigue au clavier, ça fait drôle.

  5. #165
    Membre émérite
    Homme Profil pro
    Inscrit en
    Octobre 2007
    Messages
    1 075
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 075
    Points : 2 441
    Points
    2 441
    Par défaut Le type Numérique serait "le" type adapté à une gestion sans faute(s) ...
    Bonjour

    Un peu de code à mettre dans un bouton et des commentaires.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    num1 est un numérique
    num1 = 123456789012345.67890123456789
    //Info("123456789012345.67890123456789" + CRLF + num1 + "  /  " + TypeVar(num)) 
     
    num2 est un numérique
    num2 = 1234567890123456789.0
    //Info("1234567890123456789.0" + CRLF + num2 + "  /  " + TypeVar(num2)) 
     
    num3 est un numérique
    num3 = 0n123456789012345.6789017654321
    //Info("0n123456789012345.67890123456789" + CRLF + num3 + "  /  " + TypeVar(num3)) 
     
    xTauxTVA est numérique(2,10) = 0n5.5 
    xMontant est un numérique(2,10) = 0n5
    xUn est un numérique(2,10) = 0n1
    xCent est un numérique(2,10) = 0n100
     
    xRés1 est un numérique = xTauxTVA / 100 
    xRés2 est un numérique = 1 + xTauxTVA / 100 
    xRés3 est un numérique = xMontant / (xUn + xTauxTVA / xCent)
     
    xRés4 est un numérique(2,10) = xMontant / (xUn + xTauxTVA / xCent)
    xRés5 est un numérique(2,2) = xMontant / (xUn + xTauxTVA / xCent)
    xRés6 est un numérique(2,2) = Arrondi(xMontant / (xUn + xTauxTVA / xCent),2)
     
    Info("num1 - traité comme réel" + CRLF +  "123456789012345.67890123456789" + CRLF + num1 + CRLF + CRLF +...
    "num2 - traité comme réel, mais puissance 10 conservée" + CRLF + "1234567890123456789.0" + CRLF + num2 + CRLF + CRLF +...
    "num3 - traité comme numérique avec décimales auto et sans arrondi" + CRLF + "0n123456789012345.6789016789017654321" + CRLF + num3 + CRLF + CRLF +...
    xTauxTVA + CRLF + xRés1+ CRLF + xRés2 + CRLF + "Rés3  -  6 déc.auto : " + xRés3 + CRLF +  "Rés4  -  10 déc.   : " + xRés4 + CRLF + "Rés5  -  tronqué  : " + xRés5 + CRLF + "Rés6  -  arrondi   : " +  xRés6)
    Num1
    Affectation d’un numérique par une valeur sans préfixer par 0n et sans chiffre significatif après le séparateur décimal : cette valeur est automatiquement convertie en réel par le compilateur et donc arrondie au 15e chiffre significatif

    Num2
    Affectation d’un numérique par une valeur sans préfixer par 0n et avec des chiffres significatifs après le séparateur décimal : cette valeur est automatiquement convertie en réel par le compilateur et donc arrondie au 15e chiffre significatif, mais la puissance 10 initiale est conservée en ‘boostant’ le réel obtenu par l’ajout de 4 ‘0’ (zéros) à droite et on ‘restaure’ ainsi le nombre initial de chiffres précédant le séparateur décimal !!!

    Num3
    Affectation d’un numérique par une valeur en préfixant par 0n et avec des chiffres significatifs après le séparateur décimal.
    La valeur affectée est conservée et tronquée (pas arrondie) au 6e rang, nombre automatique de décimales sauf déclaration explicite.

    Les calculs (Résultats 4, 5 et 6) permettent de constater que si TOUS les opérandes sont des numériques correctement déclarés ET affectés (càd avec le préfixe 0n), tout fonctionne comme il se doit (mais à quel prix ! et avec quelles embûches en cours de route).

    Les résultats sont tronqués et non arrondis selon le format affecté à la variable recevant le résultat.
    Restent à explorer les éventuelles variations en fonction du type d’opération, soulevées par le test de Chris dans une discussion sur le forum de PCsoft.

    Hemgé

  6. #166
    Membre expérimenté
    Inscrit en
    Août 2010
    Messages
    726
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 726
    Points : 1 645
    Points
    1 645
    Par défaut
    Bonjour Hemgé,

    Le cas 5 est intéressant : pour moi WinDev devrait arrondir, comme il le fait pour les monétaires.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    m est monétaire = 1.0000009
    n est numérique(10,6) = 1.0000009
    Trace(m) // 1.000001
    Trace(n) // 1
    Mais pour le reste, à mon avis l'explication se résume comme suit :
    - Si une opérande A est numérique et l'opérande B ne l'est pas, l'opérande B est castée en numérique (*) (pas numérique tout court qui équivaut à numérique (32,6))
    - Le type numérique (*) peut se "bloquer" sur une précision inadaptée à sa valeur. Je n'ai pas compris dans quelle situation exactement, mais 0n1 + 0n5.5 / 0n100 génère un numérique qui provoquera l'erreur s'il est utilisé comme dénominateur d'un division

  7. #167
    Membre émérite
    Homme Profil pro
    Inscrit en
    Octobre 2007
    Messages
    1 075
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 075
    Points : 2 441
    Points
    2 441
    Par défaut
    Les voies de Windev sont impénétrables comme celles du "Saigneur" (avec a !).
    Et sa voix (celle du Seigneur ce coup-ci) est inaudible même en ce temps où PCsoft nous adresse un questionnaire qualité ...

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    r est réel = 1.0000009
    m est monétaire = 1.0000009
    n est numérique = 1.0000009
    Trace(r) // 1.0000009
    Trace(m) // 1.000001
    Trace(n) // 1
    Donc, si on complète avec un réel,
    - le réel n'arrondit pas ce qui est correct puisqu'on a une cohorte de 15 chiffres qui se baladent de part et d'autre du séparateur décimal
    - le monétaire arrondit lorsqu'on dépasse la limite des 6 décimales, ce qui n'est pas spécifié dans la doc (il n' y que pour le réel que la doc spécifie l’arrondissement)
    - le numérique "tel que" ou (10,6), qu'il soit affecté avec ou sans préfixe 0n, est tronqué, alors que cette valeur est automatiquement convertie en réel par le compilateur (en gras dans la doc) lorsqu'il n'est pas préfixé par 0n ... et qu'on pourrait s'attendre à ce qu'il se comporte comme un réel (?)

    Attendons la version ... 24 ? Les grands nombres , ce n'est quand même pas très important en gestion.

  8. #168
    Membre expérimenté
    Inscrit en
    Août 2010
    Messages
    726
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 726
    Points : 1 645
    Points
    1 645
    Par défaut
    En fait, concernant le monétaire, il s'agit d'un type à virgule fixe à 6 décimales.
    Donc il n'y a pas besoin de préciser que les nombre seront arrondis à la sixième décimale. (et en fait, ça doit sûrement être évoqué ailleurs dans la doc)

    Et concernant le numérique, c'est bien un réel qui est généré par la littérale, mais on le copie dans un numérique, qui est implicitement un numérique (32,6). Donc il est normal que ça limite le nombre à 6 décimales. (mais pas en tronquant !)

  9. #169
    Membre expérimenté
    Inscrit en
    Août 2010
    Messages
    726
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 726
    Points : 1 645
    Points
    1 645
    Par défaut
    Ce qui me fait de plus en plus peur, c'est que :
    - Le support technique est capable de refuser de remonter un tel bug
    - Peu de développeurs semblent se soucier de ce genre de bug, en tout cas sur internet

    Alors que c'est extrêmement grave.

    Le type numérique est "contagieux" :
    Si on veut une analyse dans laquelle on définit le nombre de décimales après la virgule (très classique en SQL) on utilise un "numérique".
    Du coup, quand on crée des champs à partir de l'analyse, ça génère des champs de type "numérique haute précision".

    Puis, quand on utilise l'un ou l'autre directement dans des expressions arithmétiques, c'est le type numérique (*) qui est implicitement choisi.

    Du coup, de très nombreuses portions de codes dans nos projets existants peuvent provoquer un bug.


    Je ne comprends pas comment on peut s'accommoder d'une telle situation.


    C'est comme WinDev 17 en version 64 bits, dont la dernière version contient toujours un bug extrêmement grave :
    - Créez une analyse avec des rubriques de type monétaire
    - Faites une connexion en OLE DB (dans notre cas c'était SQL Server en OLE DB, mais si ça se trouve le bug concerne beaucoup plus de cas)
    - Faites un HAjoute avec les valeurs suivantes : 300, 20, 21, 300.1
    => en 32 bits, pas de souci
    => en 64 bits, vous trouverez dans la base : 3, 2, 21, 300.1
    Il bouffe tous les zéros de droite, même dans la partie entière !

    Je n'avais pas signalé le bug parce qu'il était déjà corrigé dans WD18 et on l'avait contourné en redéfinissant l'analyse avec le type numérique.
    Mais comment ont-ils pu laisser un bug aussi grave dans la dernière version de WD17 ?


    J'hésite toujours à dire ce genre de chose publiquement, car c'est scier la branche sur laquelle je suis assis.
    Mais le ST ne veut pas remonter les bugs, et rester sur cette techno risque de devenir très risqué.

  10. #170
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Hibernatus34 Voir le message
    Encore un bug que le ST ne veut pas comprendre :
    http://forum.pcsoft.fr/fr-FR/pcsoft....alcul/read.awp
    En remplaçant "numérique" par "réel", j'obtiens les bons résultats

  11. #171
    Membre émérite
    Homme Profil pro
    Inscrit en
    Octobre 2007
    Messages
    1 075
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 075
    Points : 2 441
    Points
    2 441
    Par défaut
    Citation Envoyé par romulus001 Voir le message
    En remplaçant "numérique" par "réel", j'obtiens les bons résultats
    Sans doute, peut-être, c'est possible, tant mieux.
    Mais c'est aller même à l'encontre des conseils de PCsoft ... et ne venez pas dire que vous n'avez pas été prévenus.
    Faut lire la doc ou la relire attentivement.

    Doc sur le type Réel
    Problèmes de précision avec les réels
    Les opérations avec le type "réel" ne sont pas précises du fait de la représentation informatique des réels.

    Deux réels qui sont égaux au sens mathématique ne le sont pas forcément en informatique et les opérateurs ">", "<" ou "=" peuvent renvoyer des résultats "faux" au sens mathématique.

    Pour pallier une partie de ces problèmes :
    ...

    Pour éviter tous ces problèmes, il faut utiliser le type Monétaire ou Numérique qui utilise une représentation mémoire exacte.
    Doc sur le type Monétaire
    Le type monétaire est conseillé pour éviter les erreurs d'arrondi dues au codage binaire des réels.
    Doc sur le type Numérique
    Comparaison Monétaire / Numérique
    Le type Monétaire est conservé par compatibilité. Il est plus rapide pour les calculs ne demandant pas une précision supérieure à 24 chiffres significatifs (17 maximum pour la partie entière, 6 maximum pour la partie décimale).
    Et enfin ou plutôt pour commencer dans Documentation sur Les différents types de données (Types de variables)
    Numérique : type conseillé pour des calculs réalisés sur des valeurs réelles nécessitant une précision garantie des décimales.
    Un numérique gère 38 chiffres significatifs (32 maximum pour la partie entière, 6 maximum pour la partie décimale). La précision est assurée sur 6 décimales.

    Réel : type conseillé pour des calculs simples réalisés sur des valeurs réelles.
    Un réel gère 15 chiffres significatifs, par contre la précision des décimales n'est pas garantie. La précision des décimales n'est pas assurée. Pour effectuer des calculs précis, utilisez le type "Monétaire".
    Pour des calculs avancés, le WLangage propose différents types de réels.
    Donc, in fine, stricto sensu et en étant un peu rigide, il ne resterait que les entiers et les numériques (qui malheureusement sont un peu casse-g...), les réels étant là pour faire joujou, les monétaires n'étant conservés que par compatibilité (citation textuelle).
    Pour être franc, ces lectures m'ont toujours interpellé.

  12. #172
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Hemgé Voir le message
    Sans doute, peut-être, c'est possible, tant mieux.
    Mais c'est aller même à l'encontre des conseils de PCsoft ... et ne venez pas dire que vous n'avez pas été prévenus.
    Faut lire la doc ou la relire attentivement.
    Avant de poster mon message, j'avais justement fait le test sous windev 20. Je me rappelle que quand je mettais autoformé à windev et à webdev durant mon stage de fin d'études dans une entreprise, il avait été souligné les erreurs de calculs entre 2 objets de type réel. Durant mon stage, je me souviens très bien que j'avais rencontré un bug, je ne sais plus exactement le contexte (c'était 5 ans avant et entre temps, j'ai changé de travail), c'était un truc du genre dans la partie navigateur sous webdev:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    l_monBool est un booléen=Vrai
    si l_monBool Alors
      //bizarrement, ce bout de code n'était pas exécuté
    Sinon
      //ce bout de code était justement exécuté
    Fin
    Par contre:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    l_monBool est un booléen=Vrai
    si l_monBool=Vrai Alors
      //enfin, ce bout de code est exécuté
    Sinon
      //ce bout de code n'est pas exécuté
    Fin

  13. #173
    Membre émérite
    Homme Profil pro
    Inscrit en
    Octobre 2007
    Messages
    1 075
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 075
    Points : 2 441
    Points
    2 441
    Par défaut
    Et ? ...

  14. #174
    Membre confirmé
    Homme Profil pro
    Inscrit en
    Juin 2010
    Messages
    1 355
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Juin 2010
    Messages : 1 355
    Points : 509
    Points
    509
    Par défaut J'encourage la démarche
    Je post juste pour dire que ça fait du bien de lire ça.
    J'avais poussé un gros coup de gueule contre PC Soft et je m'étais fait traité de malpropre sous prétexte que si on aime pas Windev, on le quitte.
    Et bien non, ce n'est pas aussi simple. PC Soft a des responsabilités et une gestion pour le moins hasardeuse des bug de son fleuron.
    Message à PC Soft : Pas de version 21 avec 921 nouveautés pour la fin d'année svp. Plutôt une version 20, sans chichi mais où les problèmes récurrents sont enfin traités.

    Merci à toi Hibernatus
    Les solutions les plus simples sont les plus efficaces

  15. #175
    Membre expérimenté
    Inscrit en
    Août 2010
    Messages
    726
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 726
    Points : 1 645
    Points
    1 645
    Par défaut
    Merci pour ton soutien, lololebricoleur.

    J'ai une bonne centaine de fiches de bug à mon actif depuis WD15, et j'en ai une trentaine à signaler maintenant.

    Je trouve le ST très réactif, mais malheureusement ils peuvent parfois se braquer sur certains bugs.

    Là je crois que je les ai vexés car ils m'ont donné des explications erronées que j'ai réfutées.

    Donc je compte sur vos rapports de bug (avec l'outil "Requête au Support Technique" accessible depuis WinDev, dans le menu "?") pour faire corriger ce bug des numériques.

    Merci d'avance.

  16. #176
    Membre expérimenté
    Inscrit en
    Août 2010
    Messages
    726
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 726
    Points : 1 645
    Points
    1 645
    Par défaut
    Ca y est, le bug des numériques est corrigé dans la dernière version de WD21.

    Ca valait le coup d'insister !

  17. #177
    Expert confirmé
    Homme Profil pro
    ?
    Inscrit en
    Juillet 2002
    Messages
    2 378
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : ?

    Informations forums :
    Inscription : Juillet 2002
    Messages : 2 378
    Points : 4 494
    Points
    4 494
    Par défaut
    Yes beau combat !

    J'en ai quelques uns de corrigés aussi

  18. #178
    Expert éminent
    Avatar de frenchsting
    Homme Profil pro
    multitâches-multifonctions
    Inscrit en
    Juin 2003
    Messages
    5 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : multitâches-multifonctions
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 161
    Points : 9 111
    Points
    9 111
    Par défaut
    Merci à vous 2 pour ces gros progrès !!!
    Commencez toujours appuyer sur la touche F1 et puis n'hésitez à passer par un moteur de recherche...
    Le forum est fait pour répondre aux questions : pas la peine de me les envoyer par MP. Merci.

    Sur internet, tout est vrai ! Honoré de Balzac
    Make it real not fantasy... Herman Rarebell

  19. #179
    Futur Membre du Club
    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    Janvier 2013
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aude (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2013
    Messages : 3
    Points : 5
    Points
    5
    Par défaut Yes !
    La persévérance finit toujours par payer.

    "La pierre même sera creusée si la fourmi y grimpe continuellement."
    Proverbe indien ; Maximes populaires de l'Inde (1858)


    Citation Envoyé par Hibernatus34 Voir le message
    Ca y est, le bug des numériques est corrigé dans la dernière version de WD21.

    Ca valait le coup d'insister !

Discussions similaires

  1. Trouvez une erreur de conception dans un code
    Par ultimate_manx dans le forum C
    Réponses: 11
    Dernier message: 02/05/2007, 23h37
  2. Réponses: 13
    Dernier message: 02/03/2007, 15h43
  3. bug sans erreur de syntaxe
    Par gayannee dans le forum VB 6 et antérieur
    Réponses: 3
    Dernier message: 07/12/2006, 01h35
  4. [Continuum] Bug ou erreur de configuration ?
    Par elitost dans le forum Intégration Continue
    Réponses: 2
    Dernier message: 16/08/2006, 00h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo