Försöker lära mig VB.Net på egen hand men har vissa problem. Har försökt kompilera koden nedan men får följande felmeddelande: Testa med: Microsoft.VisualBasic- namespace:t innehåller ju så vitt jag vet gamla vb-prylar. Är det inte lite fult att använda sånt i nya .net? App app app app app!!! Så ska man INTE göra!!!! Det är väl ändå fel. Det retunerar ju en sträng som motsvarar talet. Itte asci tecknet. >Microsoft.VisualBasic- namespace:t innehåller ju så vitt jag vet gamla vb-prylar. Är det inte lite fult att använda sånt i nya .net? Hur man skall göra och vad han ville göra är enligt mig två olika saker, jag uppfattade att han ville hitta alla "gamla" kommandon vilket jag gav en ledtråd om, men jag borde förstås ha pluttat in ett (mera) korrekt exempel också... det blir dessutom inte "slöare" på något sätt bara för att du sätter referens till fler assemblies, däremot äter det lite mer minne ( inte för att visualbasic namespacet tar massa MB precis). Jag ber om ursäkt för det lilla syntaxfelet :-( Oj vad rörigt det vart nu... =) Så de gamla VB-funktionerna finns alltså inte kvar i .NET? Eller har jag missförstått detta nu? Har ju använt VB.NET-referensen på MSDN och där finns ju alla dem gamla funktionerna med. >Så de gamla VB-funktionerna finns alltså inte kvar i .NET? Hej >Mne massa gaml VB ivrare var vansinniga när M$ ändrade i deras språk. Hej. Varför skulle man vilja flytta ett gammalt vb-system till vb.net?? >Ja Vilka idioter, tacka vet jag konsulter som skriker släng all gammal kod den är värdelös nu ska ni börja från början vi har massa bra kurser och "erfarna" dotNet utvecklare att erbjuda. >Varför skulle man vilja flytta ett gammalt vb-system till vb.net?? >>Varför skulle man vilja flytta ett gammalt vb-system till vb.net??Chr
C:\test.vb(9) : error BC30451: Name 'Chr' is not declared.
Console.WriteLine(Chr(i))
Koden:
<code>Imports System
Module Modul
Sub Main()
Dim i As Integer
For i = 65 To 97
Console.WriteLine(Chr(i))
Next
End Sub
End Module</code>
Har samma problem med funktionerna Trim(), Left() och Right()...Sv: Chr
<code>
Imports System
Module Apa
Sub Main()
Dim i As Integer
For i = 65 To 97
Console.WriteLine(Microsoft.VisualBasic.Chr(i))
Next
End Sub
End Module
</code>Microsoft.VisualBasic
Är "ms.vb" helt managed? och säkert att använda i program som ska kunna köras på andra plattformar?Sv: Chr
*host host*
Eftersom du i det läget måste lyfta in ett helt bibliotek till så kommer koden kanske inte med en gång att bli slö men om du matar på med mera kod och sen alla andra bra bibliotek som man brukar använda (System.Data t ex) så finns det risk att det inte riktigt blir bra..
Nåväl.. Såhär ska du göra om du vill vara .NETig:
I klassen System finns en liten trevlig funktion som heter ToString. Eftersom alla klasser i .NET ärver från System så har dessutom alla klasser tillgång till denna funktion. Meningen med funktionen är att förvandla ett objekt till en sträng, så att du t ex kan lägga ut den i et textbox eller liknande. I många fall är det självklart att det kommer bli en sträng men ibland så måste du tala om för "den" att du vill ha en sträng.
I ditt fall så skulle du skriva:
<code>
Dim i As Integer
For i = 65 To 97
Console.WriteLine(i.ToString())
Next
End Sub
</code>
Det stämmer dessutom bättre överens med den mer objektorienterade syntax som VB.NET har.
Fortsätt plugga dock. Det blir ännu roligare..
//Mikael.NETSv: Chr
Sv: Microsoft.VisualBasic
Nää
>Är "ms.vb" helt managed?
Ja. Skriven i VB.NET, som bara kan producera "managed code".
>och säkert att använda i program som ska kunna köras på andra plattformar?
Alla VB progam länkar till Microosft.VisualBasic.dll, vare sig du använder den eller inte. Så det blir inte "mindre säkert" av att använda språkfunktionenerna som finns implementerade där.
MSSv: Chr
Sv: Chr
Jag håller defintivt med de som säger att man skall försöka använda .NET's sätt att utföra saker, gillar inte att M$ lämnat massa extra implementationer, för igentligen mappar det bara emot .NETs implementationer.
Mne massa gaml VB ivrare var vansinniga när M$ ändrade i deras språk. En av anledningen till varför VB*s arrayer kan bete sig annorlunda gälalnde L/U bounds också .. Gamla stötar som inte vill se ngn förnyelse utan är nöjda emd hur det fungerar. Sv: Chr
Men det stämmer att det finns klara nackdealr med att mata in allt gammalt MEN det är guld värt när Storföretaget (tm) ska konvertara sin kassakossa till .NET.
Regeln skulle annars kunna vara att just då använder man konverteringsbiblioteken, och annars inte.
Andra exempel är:
MsgBox("Hello Wårld") ' Fungerar men...
MessageBox.Show("Hello wårld") ' är rätt.
En tumregel är att om du ha fasligt mass punkter och långa programrader så gör du "rätt" :-)
//Mikael
.:: Tänker ha en trvilig helg ::.Sv: Chr
Sv: Chr
Joo. Somliga anser att det är fel/fult/dåligt att använda dem, andra inte. Välj själv.
MSSv: Chr
>Gamla stötar som inte vill se ngn förnyelse utan är nöjda med hur det fungerar.
Det var den mest korkade kommentaren den här månaden
Klart att man är nöjd när det fungerar.
Phuuuuuuuu.
SvenSv: Chr
Ja Vilka idioter, tacka vet jag konsulter som skriker släng all gammal kod den är värdelös nu ska ni börja från början vi har massa bra kurser och "erfarna" dotNet utvecklare att erbjuda.Sv: Chr
Hela grejen är att det inte är så mycket man behöver lära på nytt.
Bara man läser lite.
programmering som programmering...
Det är inte bara koden som gör programmen.
//freddaSv: Chr
Att importera gammal kod är i stort sett förkastligt då det blir så mycket jobb med att korrigera allt, och om man tjänar på att importera den så är det också förkastligt för då är det ingen större kodsnutt man läst in och kan lika gärna göra den "rätt".
Nä, när ett så fint verktyg som vs.net landar hos oss utvecklare och vi skall göra ngt med det är det lika så bra att göra det rätt...Sv: Chr
Ehh, den där logiken förstod jag inte... vad har konsultbolags vilja att bygga system med ny teknologi, med gamal vb utvecklares ovilja att låta m$ göra stora förändringar i "deras" språk när en uppdatering släpps?
Om en uppdatering släpps, betyder det även om det skulle varit VB7, att det blir nya projekt i en ny miljö.
Vad gäller .NET är ändå inte den högsta inlärningstrsöskeln språket utan plattformen i sig, och den är bra.
Vill man fortsätta jobba i VB6 kan man göra det, och kommer fortsätta kunna göra det ett bra tag till. Men varför smutsa ner ngt som skulle vara helt nytt och fräscht?Sv: Chr
När jag köper nya program brukar jag förutsätta att mina existerande arbeten fungerar lika bra i den nya versionen, förväntar mig
inte att dessa kallas smuts eller att mitt betende är förkastligt.
>lika så bra att göra det rätt...
Håller med om att klassik VB var fel sätt ;-)
>Ehh, den där logiken förstod jag inte...
Vilken logik ;-).Sv: Chr
>När jag köper nya program brukar jag förutsätta att mina existerande arbeten fungerar lika bra i den nya versionen, förväntar mig
>inte att dessa kallas smuts eller att mitt betende är förkastligt.
Innan jag köper ny mjukvara så brukar jag ta reda på om bakåtkompabilitet finns, därför känner jag att de som är intresserade av att uppgradera sina befintliga VB6-projekt genom en import har ett förkastligt beteende. VB.Net är inte bakåtkompatibelt och har inte marknadsförts på det sättet heller.
>>lika så bra att göra det rätt...
>Håller med om att klassik VB var fel sätt ;-)
Classic VB är bra till enormt mycket, jag gör det mesta i VB6 fortfarande och kommer sannolikt att fortsätta med det, men den lama objektorienteringen (obefintliga) i VB6 gör VB.NET och C# till klara vinnare för större system IMO.