De fem bästa ändringarna från VB 6 till VB.NET

Visual Basic 1.0 var en stor jordbävning under hela programmeringen. Innan VB1 var du tvungen att använda C, C ++ eller någon annan hemsk utvecklingsmiljö för att skapa Windows-applikationer. Programmerare tillbringade bokstavligen veckor bara på att rita fönster på skärmar med picky, detaljerad, svår att felsöka kod. (Samma sak du kan göra genom att dra ett formulär från verktygsfältet på några sekunder.) VB1 var en hit och gazillions av programmerare började omedelbart använda det.

Men för att få magin att hända gjorde Microsoft några stora arkitekturkompromisser. Eftersom VB1 skapade formulär och kontroller gav de inte programmeraren tillgång till koden som gjorde det. Du låter VB skapa allt, eller så använde du C ++.

VB 2 till 6 upprätthöll samma arkitektur. Microsoft gjorde några mycket smarta uppdateringar som gav programmerare mycket mer kontroll, men i slutändan kunde inte programmerare integrera sin kod med VB-koden. Det var en svart låda - och inte på det bra OOP-sättet. Ett annat sätt att säga detta var att programmeraren inte hade tillgång till de interna VB-objekten och ett annat sätt att säga det var att VB6 fortfarande inte var helt "objektorienterad".

Under tiden kom Java, Python och en hel del andra programmeringsspråk som VAR objektorienterade att dyka upp. Visual Basic började passera - stor tid! Detta är en situation som Microsoft inte tolererar... och de beslutade att lösa problemet en gång för alla. Lösningen är .NET.

Men för att göra de saker som .NET behövde göra, beslutade Microsoft att de måste "bryta kompatibiliteten". Det vill säga Visual Basic-program hade varit (med mycket mindre undantag) "uppåt kompatibla" från VB1 ända upp till VB6. Ett program skrivet i den första versionen av VB skulle fortfarande kompilera och köras i nästa version. Men med VB.NET fann Microsoft att de bara inte kunde göra språket helt OOP och upprätthålla kompatibelt uppåt.

När de fattade detta grundläggande beslut öppnade översvämningsgrindarna på tio år med ackumulerade "önskelista" -förändringar och alla gick in i det nya VB.NET. Som de säger i Storbritannien, "In för ett öre, in för ett pund."

Utan ytterligare försening, här är min mycket personliga lista över de fem bästa ändringarna från VB6 till VB.NET i omvänd ordning.

Wellllll... bara ytterligare en försening. Eftersom vi byter från VB6, där en matris förklaras som Dim myArray (5) har 6 element, Vi har sex av dem. Det passar bara ...

(Trumvirvel, tack ...)

"Pris (5)", vår 6: e plats utmärkelsen till C groupies val: C-liknande syntaxändringar!

Nu kan du koda a + = 1 istället för a = a + 1 och spara TRE HELA KEYSTROKES!

Världens programmerare, jubla! VB har höjts upp till C-nivå, och en helt ny generation som försöker lära sig VB kommer att komma lite närmare massförvirringen som konfronterar studenter på C ++.

Men vänta! Det finns mer!

VB.NET har nu "kortslutningslogik" som har infört subtila buggar i C ++ -kod i flera år för att spara dyrbar nano-sekunder processortid. Kortslutningslogik utvärderar endast flera villkor i ett logiskt uttalande om det behövs. Till exempel:

Dim R Som Boolean
R = Funktion1 () Och Funktion2 ()

I VB6 utvärderas båda funktionerna om de behöver det eller inte. Med VB.NET, om funktion 1 () är falsk, ignoreras funktion 2 () eftersom "R" inte kan vara sant. Men vad händer om en global variabel ändras i Function2 () - bara av en slump (C ++ programmerare skulle säga, "av dålig programmering ".) Varför ger min kod fel svar någon gång när den är översatt till VB.NET? Det här kan vara det!

För Provaing hårdare, kommer VB.NET Fånga lite tur och Till sist bli erkänd för "exceptionell" felhantering.

VB6 hade det sista hållet GoTo: "On Error GoTo". Även jag måste erkänna att C ++ -stilen "Try-Catch-Final" strukturerad undantagshantering är en enorm förbättring, inte bara en halv enorm förbättring.

Vad säger du "On Error GoTo" finns fortfarande i VB.NET? Wellll... Vi försöker att inte prata om så mycket.

5: e plats urval är en grupppris: Diverse kommandot ändras! De måste dela ut den här utmärkelsen och det finns en gazillion av dem. Microsoft har sparat upp i tio år och de skar verkligen loss.

VB.NET stöder inte längre VarPtr-, ObjPtr- och StrPtr-funktioner som hämtade minnesadressen för variabler. Och det stöder inte VB6 LSet som användes för att konvertera en användardefinierad typ till en annan. (Förväxlas inte med VB6 LSet som gör något helt annat - se nedan.)

Vi bjuder också på snygga att låta, saknas, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar och (min personliga favorit!) GoSub.

Cirkeln har omvandlats till GDI + DrawEllipse. Detsamma gäller för Line to DrawLine. I beräkningen har vi nu Atan istället för Atn, Sign går in för Sgn och Sqrt passar upp för det stora spelet istället för Sqr.

I strängbehandling, även om de fortfarande är tillgängliga om du hänvisar till en Microsoft-kompatibilitet namnområdet, vi har PadRight för VB6: s LSet (igen, helt annorlunda än VB6: s LSet, naturligtvis) och PadLeft för RSet. (Där går de tre tangenttryckningar som vi sparat med "+ ="!)

Och naturligtvis, eftersom vi OOP nu, oroa dig inte om Property Set, Property Let och Property Get inte uppfylls i VB.NET, satsar du!

Slutligen felsöka. Skriv ut blir endera felsökning. Skriv eller felsök. Skrivlinje. Endast nördor skriver ut allt ändå.

Detta berör inte ens alla de NYA kommandona i VB.NET, men vi måste stoppa denna nonsens någonstans.

I 4: e plats, vi har Ändringar av procedursamtal!

Detta är utmärkelsen "godhet, renhet och hälsosam dygd" och representerar mycket hårt kampanj av fraktionen "inte mer slarvig kod".

I VB6, om en procedurparametervariabel är en egen typ, är det ByRef, såvida du inte har kodat den ByVal uttryckligen, men om det inte är kodat ByRef eller ByVal och det inte är en egenvariabel så är det ByVal... Förstod det?

I VB.NET är det ByVal om det inte är kodat ByRef.

ByVal VB.NET-standard förhindrar förresten också ändringar av parametervariabler i procedurer från att oavsiktligt spridas tillbaka till samtalskoden - en viktig del av god OOP-programmering.

Microsoft "överbelaster" också VB.NET med en ändring av kraven för parenteser i procedursamtal.

I VB6 krävs parenteser kring argument när du gör funktionssamtal, men inte när du ringer till en subrutin när du inte använder samtalsuppgiften men de krävs när samtalsuppdraget används.

I VB.NET krävs alltid parenteser runt en lista över icke-undantagna argument.

Bronspriset - 3: e plats, går till Matriser är 0 baserade istället för 1 baserade!

Det är bara en syntaxförändring, men den här förändringen får status "medaljpodium" eftersom det röstas, "mest troligt att skruva upp din programlogik". Kom ihåg 3: e plats ÄR "Pris (2)" i vår lista. Om du har räknare och matriser i ditt VB6-program (och hur många som inte gör det), kommer detta att MÄSTA DIG UPP.

I tio år har People frågat, "Vad rökte Microsoft när de gjorde det på detta sätt?" Och i tio år har programmerare slags universellt ignorerade det faktum att det fanns ett myArray (0) element som bara tog plats och inte vände sig till något... Förutom de programmerare som DID använde det och deras program såg ut, menar jag, bara "konstigt".

För I = 1 till 5
MyArray (I - 1) = Vad som helst
Nästa

Jag menar, VERKLIGEN! ...

Silvermedaljen av 2. plats går för att hedra en gammal vän som tappades i bitskopan med programmering med VB6! Jag talar om ingen annan än, Variantdatatypen.

Troligtvis representerar ingen annan enda funktion i Visual Basic "notNet" bättre filosofin om "snabb, billig och lös". Den här bilden dog VB fram till införandet av VB.NET. Jag är gammal nog för att komma ihåg introduktionen av Visual Basic 3.0 av Microsoft: "Oh Wow! Lookee här! Med den nya, förbättrade datatypen för Variant, behöver du inte deklarera variabler eller inte. Du kan bara tänka dem och koda dem. "

Microsoft ändrade sin melodi ganska snabbt på den och rekommenderade att deklarera variabler med en specifik datatyp nästan omedelbart, vilket gör att många av oss undrar, "Om du inte kan använda varianter, varför ha dem?"

Men medan vi handlar om datatyper, bör jag nämna att många datatyper har förändrats förutom att droppa Variant i våt cement. Det finns en ny Char-datatyp och en lång datatyp som är 64 bitar. Decimal är väldigt annorlunda. Kort och heltal är inte längre längre.

Och det finns en ny "Objekt" -datatyp som kan vara något. Hörde jag någon säga, "Son of Variant"?

Till sist! Guldmedaljen, 1: a plats, den högsta utmärkelsen jag kan tilldela går till ...

TA DAH!

VB.NET är äntligen helt objektorienterad!

När du går till stranden kommer C ++ - programmerarna inte att sparka sand i ansiktet och stjäla din (flickvän / pojkvän - välj en). Och du kan fortfarande kod för en fullständig balansbok för General Ledger medan de försöker ta reda på vilka rubrikfiler som ska inkluderas.

För första gången kan du koda så nära chipet som du behöver och få tillgång till alla systeminternationer som ditt hjärta önskar utan att behöva tillgripa de otäcka Win32 API-samtal. Du har arv, funktionsöverbelastning, asynkron multitrådning, skräpuppsamling och allt är ett objekt. Kan livet bli bättre?

Hörde jag någon säga att C ++ har flera arv och .NET gör det fortfarande inte?

Bränn kättaren!