Une commande pour 2 comportement
Résolu
Phalalis
Messages postés
83
Date d'inscription
mardi 7 juin 2005
Statut
Membre
Dernière intervention
19 février 2012
-
19 mars 2006 à 21:45
rvblog Messages postés 792 Date d'inscription vendredi 4 mars 2005 Statut Membre Dernière intervention 12 juin 2012 - 20 mars 2006 à 12:34
rvblog Messages postés 792 Date d'inscription vendredi 4 mars 2005 Statut Membre Dernière intervention 12 juin 2012 - 20 mars 2006 à 12:34
A voir également:
- Une commande pour 2 comportement
- Commande make linux - Conseils pratiques -C / C++ / C++.NET
- Tableau de turbo 2 - Forum VB.NET
- TURBO C++ et blocks que choisir ✓ - Forum C
- Application de loto turbo 2 - Forum Visual Basic 6
- Turbo assembleur 5.0 - Forum ASM
3 réponses
Phalalis
Messages postés
83
Date d'inscription
mardi 7 juin 2005
Statut
Membre
Dernière intervention
19 février 2012
1
20 mars 2006 à 09:59
20 mars 2006 à 09:59
Tout d'abord, je vais repondre a rvblog.
Le fait que ma gamme de tes soit trop limitée est quelque chose que je ne comprend pas. Soit on effectue ses test, soit on les fait pas. Il est vrai qu'on peut toujours en oublié quelque un mais cela fait deja un mois que je suis dessus et que jle retourne dans tous les sens.
Ensuite au niveau de la methode de codage, je trouve tres presomptueux de ta part de critiquer une methode alors qu'il n'y a meme pas d'extrait de code.
Pour ce qui est de verifier qu'on passe dans la methode d'erreur qu'en cas d'erreur, je pense que le simple fait de voir un message d'erreur (contenu dans l'etiquette) est une chose assez parlante. Si on a un message vide, c'est que le code est passer dans l'etiquette sans aucune raison valable.
Maintenant je vais m'addresser a la communauté.
J'ai toujours penser qu'une etiquette d'erreur on ne pouvait y acceder que lorsque elle etait appelé. Or dans le programme, il continu de defiler le code de l'etiquette comme si c'etait des instruction propres (jsais pas si jm'exprime bien mais jme comprend).
Avec ma collegue nouys avons trouvé une explication peut rassurantes.
En effet, nous avons recréer le formulaire et juste fait un copier de tout le code. Et la l'instruction quit se comporte comme dans ma phase de creation du module additionnel.
D'ou le formulaire (ou un de ses controles) qui serait verolé et dont on ne sait pas pourquoi.
Humblement Phalalis
Le fait que ma gamme de tes soit trop limitée est quelque chose que je ne comprend pas. Soit on effectue ses test, soit on les fait pas. Il est vrai qu'on peut toujours en oublié quelque un mais cela fait deja un mois que je suis dessus et que jle retourne dans tous les sens.
Ensuite au niveau de la methode de codage, je trouve tres presomptueux de ta part de critiquer une methode alors qu'il n'y a meme pas d'extrait de code.
Pour ce qui est de verifier qu'on passe dans la methode d'erreur qu'en cas d'erreur, je pense que le simple fait de voir un message d'erreur (contenu dans l'etiquette) est une chose assez parlante. Si on a un message vide, c'est que le code est passer dans l'etiquette sans aucune raison valable.
Maintenant je vais m'addresser a la communauté.
J'ai toujours penser qu'une etiquette d'erreur on ne pouvait y acceder que lorsque elle etait appelé. Or dans le programme, il continu de defiler le code de l'etiquette comme si c'etait des instruction propres (jsais pas si jm'exprime bien mais jme comprend).
Avec ma collegue nouys avons trouvé une explication peut rassurantes.
En effet, nous avons recréer le formulaire et juste fait un copier de tout le code. Et la l'instruction quit se comporte comme dans ma phase de creation du module additionnel.
D'ou le formulaire (ou un de ses controles) qui serait verolé et dont on ne sait pas pourquoi.
Humblement Phalalis
rvblog
Messages postés
792
Date d'inscription
vendredi 4 mars 2005
Statut
Membre
Dernière intervention
12 juin 2012
7
19 mars 2006 à 23:42
19 mars 2006 à 23:42
Salut Phalalis,
ma réponse ne sera pas plus précise que ne l'est ta question! Je veux dire par là que les termes de ta question sont clairs mais ils amènent d'autres questions. Donc, hypothèses :
- 1./ Tu as suivi une bonne méthodologie de travail qui consiste à développer unitairement un module fonctionnel additionnel. Tu l'as testé unitairement, et il a remplit la gamme de tests avec succès.
- 2./ Tu es ensuite passé en phase d'intégration de ton module dans une application existante. Et, la gamme de tests d'intégration rencontre des problèmes, qui ne sont vraissemblablement pas des problèmes d'intégration! D'où ton questionnement et ta demande d'avis de la communauté.
Mon avis personnel est :
Le simple fait que tu rajoutes l'instruction Exit Sub tend à prouver (tend simplement, je peux me tromper) que tu as misé sur la terminaison immédiate de l'exécution du code après l'instruction Quit, ce qui est trop risqué pour être systématiquement vrai. L'instruction Quit demande à l'objet Application de s'arrêter proprement (ce qui peut prendre du temps, transactions implicites à traiter, cache à vider, traitement externe du système,...), mais ne demande pas directement au code (ou au moins à la procédure courante) d'arrêter son exécution. L'instruction Exit Sub le fait explicitement, elle est donc nécessaire.
Donc, en 1./, ta gamme de tests est peut-être trop limitée, tu aurais pû détecter ce manque (rassures-toi, personne n'est parfait), mais on peut aussi dire que c'est la méthode de codage qu'il faut mettre en cause (ce qui n'est aussi que mon avis).
En effet, quand on prend le soin de mettre en place un traitement d'erreur (cela a l'air d'être ton cas) dans une procédure, on peut s'assurer, pour pas cher (une instruction Exit Sub), qu'on n'y passe qu'en cas d'erreur (sans compter que même la ligne d'instruction de la méthode Quit peut générer une erreur).
Si quelqu'un a une meilleure explication, qu'il la donne, ou alors,...
qu'il se taise à jamais...
tout aussi humblement,
rvblogn
ma réponse ne sera pas plus précise que ne l'est ta question! Je veux dire par là que les termes de ta question sont clairs mais ils amènent d'autres questions. Donc, hypothèses :
- 1./ Tu as suivi une bonne méthodologie de travail qui consiste à développer unitairement un module fonctionnel additionnel. Tu l'as testé unitairement, et il a remplit la gamme de tests avec succès.
- 2./ Tu es ensuite passé en phase d'intégration de ton module dans une application existante. Et, la gamme de tests d'intégration rencontre des problèmes, qui ne sont vraissemblablement pas des problèmes d'intégration! D'où ton questionnement et ta demande d'avis de la communauté.
Mon avis personnel est :
Le simple fait que tu rajoutes l'instruction Exit Sub tend à prouver (tend simplement, je peux me tromper) que tu as misé sur la terminaison immédiate de l'exécution du code après l'instruction Quit, ce qui est trop risqué pour être systématiquement vrai. L'instruction Quit demande à l'objet Application de s'arrêter proprement (ce qui peut prendre du temps, transactions implicites à traiter, cache à vider, traitement externe du système,...), mais ne demande pas directement au code (ou au moins à la procédure courante) d'arrêter son exécution. L'instruction Exit Sub le fait explicitement, elle est donc nécessaire.
Donc, en 1./, ta gamme de tests est peut-être trop limitée, tu aurais pû détecter ce manque (rassures-toi, personne n'est parfait), mais on peut aussi dire que c'est la méthode de codage qu'il faut mettre en cause (ce qui n'est aussi que mon avis).
En effet, quand on prend le soin de mettre en place un traitement d'erreur (cela a l'air d'être ton cas) dans une procédure, on peut s'assurer, pour pas cher (une instruction Exit Sub), qu'on n'y passe qu'en cas d'erreur (sans compter que même la ligne d'instruction de la méthode Quit peut générer une erreur).
Si quelqu'un a une meilleure explication, qu'il la donne, ou alors,...
qu'il se taise à jamais...
tout aussi humblement,
rvblogn
rvblog
Messages postés
792
Date d'inscription
vendredi 4 mars 2005
Statut
Membre
Dernière intervention
12 juin 2012
7
20 mars 2006 à 12:34
20 mars 2006 à 12:34
Salut Phalalis,
je suis navré d'avoir manqué d'humilité pour te donner un avis personnel, constructif et peut-être même juste. Il est vrai que j'aie pû être très présomptueux, ne serais-ce qu'en tentant de répondre à ta question, sans que tu n'y ais mis un extrait de code (on pourrait appeler cela de l'héritage de prétention), et à un moment où d'autres dorment déjà (ah toi aussi!).
Je suis, par contre, ravi que tu aies admis, devant la communauté (dont je fais partie, ne dis pas "Non", j'ai tout entendu) que ta surprise fût grande lorsque tu constatas, avec amertume, qu'il existe une vie, en vba, après l'appel de la méthode Quit.
Je suis, toutefois, déçu que tu n'aies pas encore compris qu'une étiquette n'est pas une entité de regroupement de code, mais un simple n° de ligne, et qu'il n'y a donc aucune raison pour que ton point d'exécution ne la dépasse pas!
Ensuite, si tu voulais être plus concis, dans ton "étiquette" (ou dans ton bloc de traitement d'erreur si tu ajoutes l'instruction Exit Sub), tu questionnerais l'objet Err, ce que tu ne dois sûrement pas faire (car si tu le faisais, une nouvelle erreur se déclencherait, te notifiant le fait que tu n'as pas le droit de questionner cet objet tant qu'une première erreur ne s'est pas déclenchée, et tu comprendrais, du même coup, que tu es passé dans ton traitement d'erreur sans raison valable), et tu traiterais tes erreurs, car peut-être te l'apprends-je ici, mais traiter des erreurs, cela commence par les distinguer entre toutes, et cela finit par organiser un traitement pour chacune.
Enfin, pour la route, tu as certainement eu tort de faire perdre du temps à ta collègue pour un test que tu pouvais faire tout seul, j'ai nommé le test du "on prend les mêmes et on recommence" (reprendre le même code pour le retaiter unitairement et arriver au même résultat, ce n'est pas un test, mais une confirmation), et que la conclusion que tu en fais fâcherait même l'inspecteur Collombo quant à sa hâte, Je l'illustre ici avec une bonne blague :
Un savant fait une expérience : Il pose une puce sur la table, tape à côté d'elle avec sa main, la puce saute. Le savant note son expérience, puis en fait une autre : Il arrache les pattes de la puce, la pose sur la table, tape à nouveau à côté d'elle, et elle ne saute pas. Il en conclut : Quand on coupe les pattes d'une puce, elle devient sourde !!!
toujours aussi humblement, car l'humilté commence (ou finit) par un smiley :) ;) :p,
à bientôt,
PS: pour nos amis les défenseurs des bêtes, la puce avait une maquette en doublure, fabriquée dans les ateliers très réputés des fondeurs de puces INTEL.
rvblogn
je suis navré d'avoir manqué d'humilité pour te donner un avis personnel, constructif et peut-être même juste. Il est vrai que j'aie pû être très présomptueux, ne serais-ce qu'en tentant de répondre à ta question, sans que tu n'y ais mis un extrait de code (on pourrait appeler cela de l'héritage de prétention), et à un moment où d'autres dorment déjà (ah toi aussi!).
Je suis, par contre, ravi que tu aies admis, devant la communauté (dont je fais partie, ne dis pas "Non", j'ai tout entendu) que ta surprise fût grande lorsque tu constatas, avec amertume, qu'il existe une vie, en vba, après l'appel de la méthode Quit.
Je suis, toutefois, déçu que tu n'aies pas encore compris qu'une étiquette n'est pas une entité de regroupement de code, mais un simple n° de ligne, et qu'il n'y a donc aucune raison pour que ton point d'exécution ne la dépasse pas!
Ensuite, si tu voulais être plus concis, dans ton "étiquette" (ou dans ton bloc de traitement d'erreur si tu ajoutes l'instruction Exit Sub), tu questionnerais l'objet Err, ce que tu ne dois sûrement pas faire (car si tu le faisais, une nouvelle erreur se déclencherait, te notifiant le fait que tu n'as pas le droit de questionner cet objet tant qu'une première erreur ne s'est pas déclenchée, et tu comprendrais, du même coup, que tu es passé dans ton traitement d'erreur sans raison valable), et tu traiterais tes erreurs, car peut-être te l'apprends-je ici, mais traiter des erreurs, cela commence par les distinguer entre toutes, et cela finit par organiser un traitement pour chacune.
Enfin, pour la route, tu as certainement eu tort de faire perdre du temps à ta collègue pour un test que tu pouvais faire tout seul, j'ai nommé le test du "on prend les mêmes et on recommence" (reprendre le même code pour le retaiter unitairement et arriver au même résultat, ce n'est pas un test, mais une confirmation), et que la conclusion que tu en fais fâcherait même l'inspecteur Collombo quant à sa hâte, Je l'illustre ici avec une bonne blague :
Un savant fait une expérience : Il pose une puce sur la table, tape à côté d'elle avec sa main, la puce saute. Le savant note son expérience, puis en fait une autre : Il arrache les pattes de la puce, la pose sur la table, tape à nouveau à côté d'elle, et elle ne saute pas. Il en conclut : Quand on coupe les pattes d'une puce, elle devient sourde !!!
toujours aussi humblement, car l'humilté commence (ou finit) par un smiley :) ;) :p,
à bientôt,
PS: pour nos amis les défenseurs des bêtes, la puce avait une maquette en doublure, fabriquée dans les ateliers très réputés des fondeurs de puces INTEL.
rvblogn