Discussion :

[electroremy]

Bonsoir à tous,

Alors que j'ai beaucoup bossé sur VB5, je commence à faire ma première grosse application avec VB.NET (j'ai déjà fait quelques petits programmes).

Je me suis cassé la tête pendant des jours avec un problème très bizarre : mon programme n'allait pas au bout de la procédure "form_load", c'est à dire que les dernières instructions n'étaient pas exécutés, sans que le programme ne plante ou que le VB ne signale une erreur.

Après de nombreuses recherches j'ai quelqu'un qui a eu le même problème que moi sur un forum en anglais : les exeptions ne sont pas toutes capturées dans "form_load" ; en ajoutant un Try...Catch mon programme a trouvé une erreur.

Je suis en train de me rendre compte que VB.NET a tendance à faire ça un peu partout, c'est à dire que quand il y a un bug quelque part dans une procédure, au lieu de planter, VB fait un 'exit sub'

Ce comportement est évidemment horrible non seulement pour le débuggage, mais aussi et surtout pour le fonctionnement normal du programme, qui va continuer à s’exécuter avec des données plus ou incorrectes parce qu’un bug non détecté a fait sauter plusieurs lignes de codes... NDLR : mon logiciel va devoir piloter une machine d'usinage

Autre truc bizarre : une fonction affichait le résultat d'un calcul avec .ToString dans une zone de texte, il y a eu une erreur mais au lieu de planter le programme m'a affiché "+infini" dans la zone de texte

Je ne veux pas que mon programme marche à peu près, je préfère qu'il plante dès qu'il y a une erreur.

Donc ma question : existe t il un moyen avec VB.NET, de forcer le plantage du programme lorsqu'il y a une erreur ? En gros, dire à VB.NET "tolérance zéro" ? Je veux dire, sans que je soit obligé de mettre des Try...Catch dans chaque procédure ?

A noter que j'ai quand même réussit à récupérer pas mal de code VB5, les modifications à faire ne sont pas si compliqués que ça et c'est une bonne chose... peut être que le comportement bizarre de mon programme vient d'instructions VB5 qui ne sont pas vraiment compatibles (mais dans ce cas, pourquoi le compilateur les accepte ???)

Merci

[ACIVE_CS]

Bonjour,

VB fait un 'exit sub'

C'est pas bon ça... c'est comme un pilote de F1 qui ne sait absolument pas comment son bolide va réagir dans un virage...

Commence par éliminer le langage vb6 de ton projet et en suite met les options 'Strict' et 'Explicit' à ON tout en haut dans dans ton code, ça va t'éviter des erreurs de conversions de types etc. (comme sur l'image ci-dessous)
A savoir que une bonne partie des procédures VB5/6 que tu connaissais tu vas pouvoir les oublier, ceci-dit tu nous poseras tes questions et on va te répondre (tout le monde est passé par la)

[wallace1]

Bonsoir,

Si en mode debogage le résultat escompté n'est pas celui recherché alors c'est à toi de réfléchir à tous les scénarios pour prévoir tous les branchements possibles dans le déroulement de ton programme !
Il n'a jamais été dit qu'il fallait IMPERATIVEMENT placer des blocs Try...Catch..... dans tous les corps de méthode mais c'est bien au développeur de prévoir les multitudes d'exceptions possibles dans un scénario .....

Maintenant pourquoi ne pas utiliser tout bonnement des points d'arrêt (des espions) lors du debogage de ton appli ainsi tu pourrais te rendre compte en tps réel les erreurs retournées et surtout les corriger : Enfin comme tout debogeur d'EDI....

Il serait peut-être temps de passer à du Vb.Net en délaissant ton VB5.

[ACIVE_CS]

Re:
Tout à fait d'accord avec Wallace

Il n'a jamais été dit qu'il fallait IMPERATIVEMENT placer des blocs Try...Catch

Pour info les "Try...Cach" rappellent très vaguement les "on error resume next" sauf qu'en vb6 tu ne sais pas trop ce qui s'est passé pendant l'erreur tandis qu'avec les "Try" :

Code :

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

1
2
3
4
5
6
  Try
            'Je fais une opération
        Catch ex As Exception
            'S'il y a une erreur (exception):
            MessageBox.Show(ex.Message)
        End Try

Tu sais exactement ce qui c'est passé.

[electroremy]

Merci pour vos réponses

Je m'en suis sortit avec des try...catch

Il serait peut-être temps de passer à du Vb.Net en délaissant ton VB5.

heureusement pour moi le code VB5 que je tenais particulièrement à conserver n'avais rien de spécifique à ce langage, c'est du calcul mathématique bien chiant à débugger

A+

[mactwist69]

Bonjour,

Concernant le message d'Active_cs, il est vrai, l'option strict on, permet d'éviter des erreurs en obligeant VB à ne pas être souple sur plusieurs sujets. Par contre, enlever le namespace de VisualBasic... je vois pas trop...


Sinon, au pas à pas, bien sûr ça permet de détecter un problème, le Try Catch, de le lire...

Mais si on a pas de Try Catch, ou si on veut connaitre l'erreur AVANT que celle-ci soit "Catché", on peut aussi demandé à Visual Studio de s’arrêter sur la FirstChance Exception, donc avant que l'exception soit créer.

On peut activer cette option, mais ça ne sert à rien de la laisser en permanence, car dans les faits, il y a pleins de cas ou une first chance exception est levée, mais est tout à fait gérée et prévue et qui ne lèveront jamais de vrai exception (donc on est ennuyé souvent).

Pour ce faire il faut aller, dans Menu/Debug/exception, et cocher les cases de la colonnes "Thrown" pour les deux premières lignes.

[electroremy]

Mais si on a pas de Try Catch, ou si on veut connaitre l'erreur AVANT que celle-ci soit "Catché", on peut aussi demandé à Visual Studio de s’arrêter sur la FirstChance Exception, donc avant que l'exception soit créer.

On peut activer cette option, mais ça ne sert à rien de la laisser en permanence, car dans les faits, il y a pleins de cas ou une first chance exception est levée, mais est tout à fait gérée et prévue et qui ne lèveront jamais de vrai exception (donc on est ennuyé souvent).

Pour ce faire il faut aller, dans Menu/Debug/exception, et cocher les cases de la colonnes "Thrown" pour les deux premières lignes.

merci

je regarde...

NB : Pour avoir accès à ce menu, il faut l'ajouter : http://msdn.microsoft.com/en-us/library/d14azbfh.aspx

Ensuite, menu Deboguer -> Exceptions... ouf !

Explications en Français ici : http://msdn.microsoft.com/fr-fr/libr...v=vs.100).aspx

euh... petite question à la con :

comment faire pour que le débogueur arrête d’exécuter mon programme pour toute exception SAUF celles que je gère avec try...catch ?

en gros, retrouver le comportement normal habituel de VB5 : l’exécution s'arrête pour toutes les erreurs sauf celles gérées avec "On Error"

[mactwist69]

Dans le même menu, la deuxième colonne correspond aux "user-handled" exception, (donc celle que tu catch).

Tu peux ici décocher les exception Runtime, ça devrait le faire.

[ACIVE_CS]

Re:

mactwist69: Par contre, enlever le namespace de VisualBasic... je vois pas trop...

VB6 supporte le "late-binding" (appel d'une propriété/fonction avec son nom, sans connaitre le type de l'objet (pour les objets COM))
L'espace de nom Microsoft.VisualBasic donne une compatibilité par rapport à VB6. Il est à éviter si une solution plus performante existe, (dont VB.Net).
En décochant cette référence on va interdire l'utilisation de certaines fonctionnalités issues du VB6, devenues obsolètes, telles que par exemple:

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
VB6 => Val("23")
VB.Net => Convert.ToInt32("23")
 
VB6 => Now.Day
VB.Net => Date.Now.Day
 
VB6 => MsgBox("toto")
VB.Net => MessageBox.Show("toto")
 
VB6 => VbCrLf
VB.Net => environment.newline
 
VB6 =>
        Dim St, Str As String
        Open "c:\fichier.txt" for input as #1
        Do While Not EOF(1)
            Line Input #1, st
            Str = Str & St & vbCrLf
        Loop
        Close #1
VB.Net => 
       Dim Str() As String = System.IO.File.ReadAllLines("c:\fichier.txt")
'ou
       Dim Str As String = System.IO.File.ReadAlltext("c:\fichier.txt")
'Etc...

A propos... c'est 'acive' pas 'active'!

[Pol63]

lu en diagonale, c'est juste pour réagir aux "try catch partout"
nous on en met partout, notre appli ne doit pas s'arreter et il peut arriver des tas de choses imprévues, par contre il faut bien gérer la "sortie" impromptue

quant à enlever la référence vers microsoft.visualbasic.dll ca ne sert à rien (enfin pas à grand chose)
ce qui est dans cette dll est codé en .net et ne change en rien la compilation ...
(et les 3/4 de ce qui est dans cette dll ne renvoit que vers des choses plus communes comme convert.toxxx)

[ACIVE_CS]

Bonjour Pol63,

enlever la référence vers microsoft.visualbasic.dll ca ne sert à rien

Attention je n'ai jamais dit qu'il était indispensable de l'enlever, c'est juste histoire d'obliger le développeur à évoluer avec l'évolution du langage.

Ceci-dit en cherchant bien, je suis sur qu'on trouvera une dll équivalente pour le Basic11 ou Qbasic (pour les nostalgiques)

[electroremy]

Bonjour Pol63,

Attention je n'ai jamais dit qu'il était indispensable de l'enlever, c'est juste histoire d'obliger le développeur à évoluer avec l'évolution du langage.

Ceci-dit en cherchant bien, je suis sur qu'on trouvera une dll équivalente pour le Basic11 ou Qbasic (pour les nostalgiques)

Evolution oui... mais c'est quoi la réelle valeur ajoutée d'un changement de syntaxe imposé à l'utilisateur ???

Dans l'exemple MsgBox("toto") =>MessageBox.Show("toto"), le compilateur peut très bien évoluer en conservant la syntaxe, tout ceci est une énorme perte de temps, c'est d'ailleurs le rôle d'un compilateur de traduire du langage VB en langage machine, non

Plus sérieusement : l'informatique évolue trop vite. En fait non, je m'exprime mal, elle évolue vite mais mal.

Prenons la mécanique : les normes existent et elles durent longtemps; des outils avec une queue CN2 ou CN3 c'est du standard depuis 60 ans voire plus. Les outils ont évolués, les machines aussi, mais les normes sont restée et du coup pas besoin de remplacer tout son atelier ou de jeter à la poubelle de précieux outils et accessoires faits sur mesure.

C'est bien que l'informatique évolue... mais les incompatibilités aie aie aie... Un code source qui a seulement 5 ans peut poser pas mal de problèmes pour être utilisé aujourd'hui, un code qui a entre 5 et 10 ans encore plus, et un code qui a 15 ou 20 ans c'est quasi mission impossible, il faut déjà être capable de lire les supports sur lesquels ils sont enregistrés...

Du coup on passe notre temps à recommencer des trucs qui ont déjà été faits X fois. Vous allez me dire, ça fait marcher le commerce

Pire, des supers programmes ne peuvent plus êtres exécutes sur les ordinateurs modernes et on ne trouve plus d'équivalent. J'ai pas mal de vieux programmes de calcul scientifique faits sous MS-DOS au début des années 1990 et je ne retrouve pas d'équivalent, ou alors des équivalents buggués... Je conserve précieusement chez moi des ordinateurs de différentes époque. J'ai plusieurs appareils électroniques en très bon état de fonctionnement mais ils utilisent le port parallèle, pour les piloter il faut un PC avec MS-DOS, Win 95 ou 98 mais pas au delà.

Là je vous parle surtout du milieu industriel et scientifique ou les échelles de temps sont pas les même... Un projet peut mettre 10 ans voire plus avant d'aboutir... Un problème se pose alors : le logiciel d'un tel projet devient obsolète alors qu'il n'est même pas encore terminé

La programmation c'est quoi ? Deux étapes :
- le programmeur humain décrit un algorithme, une interface graphique et des opérations d'entrée/sortie dans un langage
- ce langage est traité par le compilateur pour obtenir un exécutable.

Les concepts tels que l'affectation d'une variable, les tests, les appels de fonction et procédure, la programmation orienté objet, la lecture et l'écriture dans un fichier, les chaines de caractères, les nombres, les maths, les bases de données, les fenêtres, les menus, la souris, le clavier, ect... bref toutes ces choses essentielles n'ont pas réellement évoluées depuis 20 ans dans leur principe.

Il aurait été possible de définir un langage universel et durable dans le temps, avec une vraie compatibilité ascendante et de vrais outils de conversion pour coder toutes ces choses sur n'importe quelle plateforme, sans empêcher les compilateurs d'évoluer.

Monde de la mécanique : J'ai acheté un mandrin porte-pince, je peux m'en servir dans toutes mes machines : le tour, la fraiseuse, la commande numérique, la perceuse à colonne et même le tour à bois. En plus, ces machines sont non seulement toutes de marque différentes, mais en plus la plus récente à un an et la plus vielle 20 ans. Ca c'est cool !

Monde de l'informatique : J'ai fait un programme, j'obtiens un fichier .exe qui ne marchera que sur les ordinateurs de type "PC" et que avec certaines versions de Windows. D'ici 5 ans je serais obliger de le reprogrammer car le type de fichier .exe ne sera plus pris en charge. Pas cool.

Devoir ré-écrire son logiciel car le langage évolue est une gageure...

Mais le pire, la grosse punition, c'est l'interface graphique... le passage VB5 -> VB.NET est une grosse perte de temps et aussi un gros problèmes (par ex la disparition des groupes de contrôles avec un index); je ne parle pas du passage VB5 => C++ ou Delphi

J'avais commencé la programmation sous Amiga 1200 (ça nous rajeunis pas...) J'avais fait pas mal de truc sympa, comme un logiciel de dessin de schéma électroniques... Des milliers d'heures de travail, je n'ai RIEN pu récupérer quand je suis passé au PC. Ensuite pas mal de truc sous DOS, et aussi j'avais récupérer des copains des trucs assez poussés sous DOS... pareil, une fois passé à Windows tout ceci était inutilisable.

Pour moi la valeur ajouté du programmeur c'est la conception des algorithmes, et la conception de l'ergonomie du logiciel.

La vraie valeur ajouté se situe peut être même en amont : résolution du problème de mathématique et/ou concept que représente le type de service rendu par le logiciel. Bref, l'idée.

Le codage est indispensable mais secondaire. Devoir re-coder c'est un non-sens.

[ACIVE_CS]

electroremy:
Je compatis... nous venons tous (du moins tous les deux) du même monde, ma formation au départ est en électronique digitale et microprocesseurs (du temps des portes logique CMOS qu'il ne fallait pas toucher avec les doigts)
C'est quand j'ai commencé à programmer des processeurs en assembleur que ça a commencé la galère des ordinateurs... je suis tombé dedans étant petit également...

J'avais commencé la programmation sous Amiga 1200 (ça nous rajeunis pas...)

J'ai commencé encore avant : ZX Spectrum 16ko de mémoire pas de disque dur, pas d'écran, sauvegardes sur une banale cassette audio avec un magnétophone. ZX Spectrum (pour les antiquaires)

la disparition des groupes de contrôles avec un index

Oui moi pareil, je ne vois pas pourquoi l'avoir enlevé, même si des d'autres solutions ont été mises en place pour palier a ça.

Les concepts tels que l'affectation d'une variable, les tests, les appels de fonction et procédure, la programmation orienté objet, la lecture et l'écriture dans un fichier, les chaines de caractères, les nombres, les maths, les bases de données, les fenêtres, les menus, la souris, le clavier, ect... bref toutes ces choses essentielles n'ont pas réellement évoluées depuis 20 ans dans leur principe.

La je pense que c'est un peu simple pour nous, en tout cas, voir plus efficace.

ils utilisent le port parallèle, pour les piloter il faut un PC avec MS-DOS, Win 95 ou 98 mais pas au delà.

Pour ça il existe des adaptateurs sous n'importe quel windows (si t'as besoin d'aide n'hésite pas)

Monde de l'informatique : J'ai fait un programme, j'obtiens un fichier .exe qui ne marchera que sur les ordinateurs de type "PC" et que avec certaines versions de Windows. D'ici 5 ans je serais obliger de le reprogrammer car le type de fichier .exe ne sera plus pris en charge. Pas cool.

Ca c'est du commercial.

Un projet peut mettre 10 ans voire plus avant d'aboutir... Un problème se pose alors : le logiciel d'un tel projet devient obsolète alors qu'il n'est même pas encore terminé

Ca c'est du commercial.

Dans l'exemple MsgBox("toto") =>MessageBox.Show("toto"), le compilateur peut très bien évoluer en conservant la syntaxe, tout ceci est une énorme perte de temps, c'est d'ailleurs le rôle d'un compilateur de traduire du langage VB en langage machine, non ?

Ca il faut demander à Bill mais je subsonne que
ce soit du commercial (le pauvre...)
D'ailleurs j'ai entendu dire quelquepart que dans la version 2014 de vb tout ce qui ressemble à de l'ancien ce sera du passé (à vérifier).
Ca c'est du commercial.

Du coup on passe notre temps à recommencer des trucs qui ont déjà été faits X fois. Vous allez me dire, ça fait marcher le commerce

c'est ça...

[Pol63]

...

quelques idées qui pourraient sembler vraies, mais quelques raccourcis aussi

par exemple un programme écrit sous vb6 avant les années 2000 fonctionne très bien aujourd'hui sous windows 7 (8 surement aussi)
et il est encore possible de modifier son code source
un programme vb.net 2005 est encore modifiable sur visual studio 2013 sans soucis

de plus le but d'un développeur et surtout d'une entreprise n'est pas seulement d'écrire un programme, c'est de le faire vivre, c'est à dire le modifier dans le temps, et souvent par des personnes qui se succèdent
en se sens vb.net apporte énormément de choses, en divisant le nombre de lignes de code par 10 entre vb6 et vb.net (si si) on obtient un code plus lisible par tous et donc plus maintenable
certaines évolutions sont nécessaires

[ranzoken]

par exemple un programme écrit sous vb6 avant les années 2000 fonctionne très bien aujourd'hui sous windows 7 (8 surement aussi)

alors je confirme que les programmes VB marche sous win7, 8, 8.1 A CONDITION de récupérer les composants graphique qui date de l'age de pierre puisqu'ils n'existent plus à partir de vista
(et ne pas oublié de les enregistrer dans le système avec la commande regsvr )
on ne sais jamais si quelqu'un en as besoin je peux en fournir un petit paquet.


et si ça évolue trop vite et trop mal faite du C

[electroremy]

alors je confirme que les programmes VB marche sous win7, 8, 8.1 A CONDITION de récupérer les composants graphique qui date de l'age de pierre puisqu'ils n'existent plus à partir de vista
on ne sais jamais si quelqu'un en as besoin je peux en fournir un petit paquet.

Ca c'est vraiment super sympa !

et si ça évolue trop vite et trop mal faite du C

Je voulais passer au C++, ou au moins faire mes nouveaux projets en C++ - Mais le travail nécessité par la création et la gestion d'une interface graphique complexe en C ... si j'avais un an devant moi à ne rien faire je dis pas ...

[Pol63]

il y a qt pour le c++ je crois c'est un standard d'interface graphique si j'ai bien suivi