De fem beste endringene fra VB 6 til VB.NET

Visual Basic 1.0 var et stort jordskjelv under programmering. Før VB1 måtte du bruke C, C ++ eller et annet fryktelig utviklingsmiljø for å lage Windows-applikasjoner. Programmerere brukte bokstavelig talt uker bare på å tegne vinduer på skjermer med kresen, detaljert, vanskelig å feilsøke kode. (Det samme kan du gjøre ved å dra et skjema fra verktøylinjen i løpet av noen få sekunder.) VB1 var et treff og gazillions av programmerere begynte umiddelbart å bruke det.

Men for å få magien til å skje, kom Microsoft med noen store arkitekturskompromisser. Siden VB1 opprettet skjemaene og kontrollene, ga de ikke programmereren tilgang til koden som gjorde det. Du lot enten VB lage alt, eller så brukte du C ++.

VB 2 til 6 opprettholdt den samme arkitekturen. Microsoft gjorde noen veldig smarte oppdateringer som ga programmerere mye mer kontroll, men til slutt kunne ikke programmerere integrere koden sin med VB-koden. Det var en svart boks - og ikke på den gode OOP-måten. En annen måte å si dette på var at programmereren ikke hadde tilgang til de interne VB-objektene, og en annen måte å si det på var at VB6 fremdeles ikke var helt "objektorientert".

I mellomtiden begynte Java, Python og en hel masse andre programmeringsspråk som VAR objektorientert å vises. Visual Basic ble passert - big time! Dette er en situasjon som Microsoft ikke tåler... og de besluttet å løse problemet en gang for alle. Løsningen er .NET.

Men for å gjøre tingene som .NET måtte gjøre, bestemte Microsoft at de måtte "bryte kompatibiliteten". Det vil si at Visual Basic-programmer hadde vært (med veldig mindre unntak) "oppover kompatible" fra VB1 helt opp til VB6. Et program skrevet i den første versjonen av VB vil fremdeles kompilere og kjøres i den neste versjonen. Men med VB.NET fant Microsoft at de bare ikke kunne gjøre språket helt OOP og opprettholde kompatibilitet oppover.

Da de først hadde tatt denne grunnleggende avgjørelsen, åpnet flomportene ti år med akkumulerte "ønskeliste" -endringer, og ALLE av dem gikk inn i det nye VB.NET. Som de sier i Storbritannia: "Inn for en krone, inn for et pund."

Uten ytterligere forsinkelse, her er min veldig personlige liste over de fem beste endringene fra VB6 til VB.NET i omvendt rekkefølge.

wellllll... bare en ytterligere forsinkelse. Siden vi endrer fra VB6, der en matrise erklært som Dim myArray (5) har 6 elementer, Vi har seks av dem. Det er bare passende ...

(Trommelrulle vær så snill ...)

"Pris (5)", vår 6. plass prisen går til C groupies valg: C-lignende syntaksendringer!

Nå kan du kode a + = 1 i stedet for a = a + 1, og spare TRE HELE nøkkelstikk!

Verdens programmerere, gleder deg! VB er hevet opp til C-nivå, og en helt ny generasjon som prøver å lære VB vil komme litt nærmere masseforvirringen som konfronterer studenter på C ++.

Men vent! Det er mer!

VB.NET har nå "kortslutningslogikk" som har introdusert subtile feil i C ++ -kode i årevis for å spare dyrebare nano-sekunder prosessortid. Kortslutningslogikk evaluerer bare flere forhold i en logisk setning om nødvendig. For eksempel:

Dim R Som boolsk
R = Funksjon1 () Og Funksjon2 ()

I VB6 evalueres begge funksjonene om de trenger det eller ikke. Med VB.NET, hvis funksjon1 () er usann, ignoreres funksjon2 () siden "R" ikke kan være sant. Men hva om en global variabel blir endret i Function2 () - bare ved en tilfeldighet (C ++ programmerere vil si, "av dårlig programmering ".) Hvorfor gir koden min feil svar noe av tiden når den er oversatt til VB.NET? Dette kan være det!

Til Prøveing hardere, VB.NET vil Å fange litt flaks og Endelig bli anerkjent for "eksepsjonell" feilhåndtering.

VB6 hadde den siste holdout GoTo: "On Error GoTo". Selv jeg må innrømme at C ++ - stilen "Try-Catch-Endelig" strukturert unntakshåndtering er en enorm forbedring, ikke bare en halv enorm forbedring.

Hva, sier du "On Error GoTo" er fremdeles i VB.NET? Wellll... Vi prøver å ikke snakke om det for mye.

5. plass utvalg er en gruppepris: Diverse kommandoen endres! De må dele denne prisen, og det er en gazillion av dem. Microsoft har spart opp i ti år, og de skar virkelig løs.

VB.NET støtter ikke lenger VarPtr-, ObjPtr- og StrPtr-funksjoner som hentet minneadressen til variabler. Og den støtter ikke VB6 LSet som ble brukt til å konvertere en brukerdefinert type til en annen. (For ikke å forveksle med VB6 LSet som gjør noe helt annet - se nedenfor.)

Vi tilbyr også kjærlighet til Let, Is Missing, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar, og (min personlige favoritt!) GoSub.

Circle har omgjort til GDI + DrawEllipse. Det samme gjelder Line to DrawLine. I beregning har vi nå Atan i stedet for Atn, Sign går inn for Sgn, og Sqrt passer opp til storspillet i stedet for Sqr.

I strengbehandling, selv om de fremdeles er tilgjengelige hvis du refererer til en Microsoft-kompatibilitet navneområdet, vi har PadRight for VB6s LSet (igjen, helt annerledes enn VB6s LSet, selvfølgelig) og PadLeft for RSet. (Der går de tre tastetrykkene vi lagret med "+ ="!)

Og selvfølgelig, siden vi er OOP nå, må du ikke kjempe om Property Set, Property Let og Property Get ikke blir oppfylt i VB.NET, satser du!

Til slutt, feilsøk. Skriv ut blir enten feilsøking. Skriv eller feilsøk. Writeline. Bare nerder trykker alt uansett.

Dette berører ikke engang alle de NYE kommandoene i VB.NET, men vi må stoppe dette tullet et sted.

I 4. plass, vi har Endringer i prosedyresamtaler!

Dette er prisen "godhet, renhet og sunn dyd" og representerer mye hard kampanje av fraksjonen "ikke mer slurvete kode".

I VB6, hvis en prosedyreparametervariabel er en egenart, er det ByRef, med mindre du har kodet den ByVal eksplisitt, men hvis det ikke er kodet ByRef eller ByVal og det ikke er en egenvariabel, så er det ByVal... Forstod det?

I VB.NET er det ByVal med mindre det er kodet ByRef.

ByVal VB.NET-standard forhindrer forresten også endringer i parametervariabler i prosedyrer fra å utilsiktet forplantes tilbake til anropskoden - en sentral del av god OOP-programmering.

Microsoft "overbelaster" også VB.NET med endring i kravene til parenteser i prosedyresamtaler.

I VB6 kreves parenteser rundt argumenter når du ringer funksjonssamtaler, men ikke når du ringer til en subroutine når du ikke bruker samtaleoppgaven, men de er påkrevd når anropsuttalelsen brukes.

I VB.NET kreves det alltid parenteser rundt en liste over ikke-dispenserende argumenter.

Bronseprisen - 3. plass, går til Arrays er 0 basert i stedet for 1 baserte!

Det er bare en syntaksendring, men denne endringen får status "medalje-pallen" fordi den er stemt, "mest sannsynlig vil du skru opp programlogikken din". Husk at 3. plass ER "Award (2)" på listen vår. Hvis du har tellere og matriser i VB6-programmet ditt (og hvor mange som ikke gjør det), MESS DEG DEG OPP.

I ti år har People spurt: "Hva røykte Microsoft da de gjorde det på denne måten?" Og i ti år har programmerere slags universelt ignorert det faktum at det var et myArray (0) element som bare tok plass og ikke ble brukt til hva som helst... Bortsett fra de programmerere som IKKE brukte det og programmene deres så ut, mener jeg, bare "rart".

For jeg = 1 til 5
MyArray (I - 1) = Uansett
neste

Jeg mener, EGENTLIG! ...

Sølvmedaljen av 2. plass går for å hedre en gammel venn som ble droppet ned i bøtten med programmering med bestått av VB6! Jeg snakker om ingen ringere enn, Varianten Datatype.

Sannsynligvis representerer ingen andre funksjoner i Visual Basic "notNet" bedre filosofien om "rask, billig og løs". Dette bildet trakk VB helt fram til introduksjonen av VB.NET. Jeg er gammel nok til å huske introduksjonen av Visual Basic 3.0 av Microsoft: "Oh Wow! Lookee her! Med den nye, forbedrede Variant-datatypen, trenger du ikke å deklarere variabler eller ikke noe. Du kan bare tenke dem og kode dem. "

Microsoft endret melodien ganske raskt på den og anbefalte å erklære variabler med en spesifikk datatype nesten umiddelbart, og lar mange av oss lure på, "Hvis du ikke kan bruke varianter, hvorfor har dem?"

Men mens vi er inne på datatyper, må jeg nevne at mange datatyper har endret seg i tillegg til at de dropper Variant i våt sement. Det er en ny Char-datatype og en Long-datatype på 64 biter. Desimal er måte annerledes. Kort og heltall er ikke like lengde lenger.

Og det er en ny "Object" -datatype som kan være hva som helst. Hørte jeg noen si:Son of Variant"?

Endelig! Gullmedaljen, 1. plass, den høyeste utmerkelsen jeg kan gi til ...

TA DAH!

VB.NET er endelig fullstendig objektorientert!

Når du går til stranden, vil ikke C ++ -programmerne sparke sand i ansiktet ditt og stjele (kjæresten / kjæresten din - velg en). Og du kan fortsatt kode en fullstendig hovedbokprøvebalanse mens de prøver å finne ut hvilke toppfiler som skal inkluderes.

For første gang kan du kode så nær brikken du trenger og få tilgang til alle systeminterne-rene ditt hjerte ønsker uten å måtte ty til de ekle Win32 API-anropene. Du har arv, overbelastning av funksjoner, asynkron multithreading, søppelinnsamling og alt er et objekt. Kan livet bli bedre?

Hørte jeg noen si at C ++ har flere arver og .NET gjør det fortsatt ikke?

Brenn kjetteren!