Equivalents de ASC et CHR en VB.NETRésolu

Question

Salut
juste savoir si le frameWork du VS 2008,Donne une nouvelle instruction pour transformer un caractère en ASCII
En vb6 ju'uilisais ASC(valeur)

cs_ShayW · Accepted Answer

Salut

dim asc as integer
dim chr as char
 asc = Convert.ToInt32("A"c)
 chr = Convert.ToChar(asc)

cs_ShayW · Answer

avec le sujet comme VB.NET 
tu aurais pu écrire encore plus court  VB    non ?

Renfield · Answer

BRAVO !
Je salue un programmeur qui enfin se débarrasse des instruction VB6 dans son code .Net !

Il serai tellement plus simple de laisser la référence Microsoft.VisualBasic...

BRAVO, j&#8217;apprécie l'initiative !

Renfield - Admin CodeS-SourceS - MVP Visual Basic	& Spécialiste des RegExp

ehjoe · Answer

Cher ami Renfield,

Devant la noble assemblée mes Seigneurs, avec véhémence je proteste sur l'heure et le champ, en effet :

Vb6 est l'héritage de vbNet, alors, sauf à être de ceux qui dilapident l'héritage au lieu de le faire fructifier (l'histoire de la poule aux ?ufs d'or), il serait bien sot d'avoir un code qui fonctionne issu de vb6, et de volontairement perdre son temps à ne pas le mettre pour aller rechercher aléatoirement un code quatre fois plus long et deux fois moins compréhensible en vbNet.

C'est comme si en mécanique tu avais une clef de dix, mais qu'au lieu de l'utiliser, tu ailles chercher une clef de 3/8e de pouce pour faire chic comme c'est une mécanique anglaise?

En sus, ceux qui durant une douzaine d'année on investi dans vb6 savent bien que vbNet est une catastrophe subissant trop de critiques, et qu'un jour ou l'autre Microsoft risque de le laisser tomber pour encore un autre langage, alors moi je n'ai plus confiance, je ne fais aucun investissement avec des gens qui ne sont pas crédibles.

Côté code, comme susdit, vbNet est deux fois moins compréhensible que vb6.
Côté vitesse, il n'y a aucune différence entre les exécutables de vbNet et de vb6.
Côté longueur, vbNet est quatre fois plus long que vb6.
L'exemple le plus "débile" (appelons les choses par leur nom), est par exemple qu'en vb6, pour indicer 100 fois un objet O, on écrivait o(i), alors qu'en vbNet il faut au moins 120 lignes de code pour atteindre le même résultat (tout écrire dans une liste, puis tout écrire au bout de chaque procédure évènementielle, le paradis)?

En fait, malgré quelque avancées et quelques uniformité salutaire, vbNet est une régression totale par rapport à vb6, c'est une sorte d'usine à gaz dont personne ne comprend réellement la totalité, qui est d'une complexité monstrueuse et d'une rare stupidité. Avec vb6 nous n'écrivions plus les classes, évidemment, le système de programmation est capable selon les mots-clefs de les ajouter, alors qu'en vbNet il faut les mettre, ce qui ne peut s'appeler une amélioration !
Parce que si on suite le raisonnement, à la prochaine version (2011), on va programmer en hexadécimal, comme en 1975? Et à la version 2012 on va programmer en binaire comme en 1960 ! C'est le progrès vu par Microsoft? ou alors une façon comme une autre de faire du fric en vendant les versions pro et autres, et en rendant lentement vb6 incompatible à l'aide de l'OS, ça s'est déjà vu?

J'ai d'autres exemples, jadis en vb6, quand on voulait tracer une ligne in écrivait :
---
Line(x1, xy1) - (x2, y2)
*
Désormais en vbNet on écrit (ne prenez pas peur) :
---
Dim g As System.Drawing.Graphics
g = Me.CreateGraphics()
Dim c As New Pen(Color.FromArgb(c1, c2, c3), ct)
g.DrawLine(x1, y1, x2, y2, c)
g.Dispose()
*
Alors c'est des plus perfides, il faut déclarer la procédure en l'associant à une variable G de type système graphique, la matrice, puis encore le redéclarer, jamais deux sans trois mais une fois n'est pas coutume ; le déclarer à nouveau, mais cette fois-ci en lui disant qu'on veut créer un graphique sur la form. Déjà ce n'est pas très compréhensible d'avoir une variable qui avale deux données et conserve les deux pour fonctionner,  passons? Après on prend une seconde variable, C, elle c'est pour la couleur, comme si la couleur n'était pas accessible directement, mais non, il faut lui donner une forme particulière via sa variable pour qu'elle soit comprise. Au passage on met le mot-clef NEW, y en a partout de ces trucs là, c'est Américain, c'est comme NEW-York, on ne sait pas pourquoi il faut lui indiquer, il est réellement stupide le système, car si on déclare une (nouvelle variable) elle est NEW de facto, ce n'est pas la peine de le lui dire, elle le sait? Enfin on en arrive à notre ligne de code qui ma foi est la seul compréhensible en venant de vb6, puis on dispose l'objet évidemment?
C'est vachement simple comme disent les veaux?
*
24 signe en vb6 en 1 ligne
140 signes en vbNet en 5 lignes

Comme si? comme si en vb6 le mot-clef-ligne créait de façon transparente le code pour le faire tourner, alors qu'en vbNet il ne sait plus ce qu'est un mot clef, il faut tout lui écrire.
Bientôt on va aussi devoir écrire l'OS?

Et ce n'est pas tout, il faut encore moult code en vbNet, car en vb6 votre trait sur la form il y reste, mais en vbNet il n'y reste pas si vous mettez quelque chose devant ou réduisez l'objet qui le support, il faut sans cesse le recommencer dans une procédure Paint par exemple.

Qui ose dire que c'est une avancée ?

Dans vb6 on ne met pas d'entête depuis 1978, dorénavant dans vbNet on met les entêtes des classe (via souvent les DLL), mais ça je le faisais naguère en TC3++ en 1980, est-ce à dire qu'avec vbNet nous avons fait un bond de 30 ans en arrière ?

vb6 c'est la quintessence de la programmation simple et efficace, tandis que vbNet c'est l'?uvre d'épouvante de vieux ingénieurs malades qui ne savent plus quoi faire pour ramasser encore quelques milliards?

Alors oui je sais, il fallait faire ainsi pour rendre compatible avec d'autres langage via le noyau intermédiaire que constitue en fait la Framework?
Mais? pourquoi faire une plateforme pseudo multiprogrammes, ceux qui veulent programmer en VB et bien ça marchait, pour les autres, si ça ne leur convenaient pas, ils n'avaient qu'à changer de langage et d'OS? chacun son problème?
En dernier, rien n'interdisait de conserver et d'améliorer encore le langage vb6 et de rajouter un noyau intermédiaire à la Framework pour vb6, afin de le rendre si je puis dire automatiquement vbNet (et donc ne pas avoir de vbNet)?

Je hais vbNet ! 
J'y reste parce que je suis obligé et que sont prix est inclut dans l'achat de l'OS en somme, et surtout parce que pour quelqu'un issu de vb6 c'est un investissement moindre. Mais si vbNet avait été payant, et que plus un seul morceau de code de vb6 ne fonctionnait, je repartais vers le C visuel, vers Borland (s'il existe encore), tant qu'à programmer tordu, vaut mieux aller vers une société qui a toujours fait un code tordu de naissance? Mais on pensait Microsoft plus sein d'esprit? 

Merci de votre lecture, cordialement, Joe.

Renfield · Answer

un code quatre fois plus long et deux fois moins compréhensible en vbNet. 

la longueur d'un code ne fait pas tout, reste a voir sa maintenabilité...
pas dit que la reference Microsoft.VisualBasic reste encore bien longtemps.
A voir également le degré de prise en charge par le framework (exception, etc.)
A voir enfin le rendu MSIL de la chose, le code en "vrai" .Net est sans doute plus court/rapide

puis tout écrire au bout de chaque procédure évènementielle,
un boucle, un appel a AddHandler et zou!
Pas question de multiplier les Handles [...], effectivement
Moins "débile" que d'associer cela par le nom, et d'avoir la même procédure dupliquée x fois.

rien n'empeche également d'avoir un Handler d'evenement qui effectue une tache, par exemple la suppression d'un element d'une ListBox et de déclarer cet Handler pour l'evenement _Click d'un bouton et pour un _Click dans un menu, bien que ces deux elements soient de nature différente...


Line(x1, xy1) - (x2, y2) 
Héritage encore... du (Q?)Basic
syntaxe complètement farfelue, non ?

concernant le graphisme, se rappeler que System.Drawing est basé sur l'API GDI+.
surcouche de GDI sur lequel est basé VB6  (Gdi32.dll)
plus lourd, certes, mais on peut faire beaucoup plus de choses facilement. (transparence, fondus, transformations, antialiasing, etc.)
le fait de créer un objet pour le Pen est une avancée...
imagine que tu souhaites alterner les styles de traits.
en VB6, tu devrais tracer tous tes traits de style 1, puis tous tes traits de style 2 (ou changer de settings a chaque trait, m'enfin...)
ici, tu as juste a créer deux pen, et utiliser le bon lors de tes appels.
        Using g As Graphics = Me.CreateGraphics
            Dim p As Pen = New Pen(Color.FromArgb(c1, c2, c3), ct)
            g.DrawLine(p, x1, y1, x1, y1)
        End Using



Et ce n'est pas tout, il faut encore moult code en vbNet, car en vb6 votre trait sur la form il y reste, mais en vbNet il n'y reste pas si vous mettez quelque chose devant ou réduisez l'objet qui le support, il faut sans cesse le recommencer dans une procédure Paint par exemple. 
C'est faux... 
En VB6 on avait la propriété AutoRedraw qui servait à cela.

De toutes façon, on est censé dessiner dans le _Paint
Le code devient alors :
Dim p As Pen = New Pen(Color.FromArgb(c1, c2, c3), ct)
        e.Graphics.DrawLine(p, x1, y1, x1, y1)

Je passe sur le reste...
J'ai codé et code encore pas mal en VB6. J'ai été très réticent envers .NET
Le frameWork est dorénavant inclus sur quasiment tous les postes, ce qui enlève une de ses plus grosses critiques.
Avouons que .Net permet de coder plus vite.
Le frameWork nous apporte pleins d'outils nécessitant auparavant quantité d'appels APIs, etc.

Le système de gestion d'erreurs par exception est une avancée, également, lorsqu'il est bien utilisé. Plus de crash inopiné, on peut poursuivre l&#8217;exécution, etc. 

Je peux comprendre ta réticence, je code plus volontiers en C# qu'en VB.net, d'ailleurs...
quitte a devoir changer ses habitudes, autant que le langage ne ressemble pas trop a VB6. Et vu que je code un peu en tout (VB, C#, C, python, rexx, etc).

Alors héritage, oui, mais je n'irai pas jusqu'à refuser le support du FrameWork, globalement bien pratique, niveau fonctionnalités, bien  qu'un peu lourd, parfois a mettre en place, je le reconnais volontiers.
Tu ne pourras en tirer avantage pleinement qu'en acceptant de supprimer la référence Microsoft.VisualBasic de tes projets, et de coder cela en épousant la philosophie .NET

Ravi de dialoguer sur ce sujet, réellement !

Renfield - Admin CodeS-SourceS - MVP Visual Basic	& Spécialiste des RegExp

Equivalents de ASC et CHR en VB.NET

5 réponses

Votre réponse

Discussions similaires