[.NET] Overstap van VB naar VB .NET: verschillen *

[Anoniem: 32345]

Ik ben aan het overstappen van VB naar VB .NET. Daar zijn nogal wat veranderingen in gekomen. Ik heb er al een hoop gevonden, maar vroeg me af of jullie nog meer grote verschillen tegen zijn gekomen. Het gaat dus echt om dingen die in VB .NET anders gaan dan dat die vroeger in VB gingen.

Volgende post wordt wat ik al gevonden heb...

[Anoniem: 32345]

Variant

De Variant bestaat niet meer, dit is het object geworden.

Dit x as variant wordt Dim x as object

Integers

De Integer is een Short geworden, de Long is een Integer geworden.

Dim x As Integer wordt Dim x as Short
Dim y as Long wordt Dim y as Integer

Currency

De Currency is een Decimal geworden.

Dim x As Currency wordt Dim x as Decimal

Date

De datum/tijd is niet meer te benaderen als een double. Vroeger kon je een datum/ tijd als een double benaderen, nu is dat helaas over.

Wanneer je de datum/tijd toch als double wil zien, moet je de functie ToOADate gebruiken, en terug converteren gebeurd met FromOADate.

Voorbeeld:

Dim datum as Date
Dim dblDatum as Double

DblDatum = Datum.ToOaDate

Fixed length strings

String variabelle met een vaste waarde bestaan niet meer in .Net. Je kan de functionaliteit nog wel bereiken door het VB6 object aan te spreken, maar doe dit niet uit geheugen besparende overwegingen, omdat dit object meer geheugen kost dan het declareren van een normale string.

Dim strString as String * 100 wordt Dim strString as New VB6.FixedLengthString(100)


Type

Het Type keyword is veranderd in Structure.

code:

Type MyType
    MyVariable as Integer
End Type

Wordt:

code:

Structure MyType
    Dim MyVariable as Short
End Structure

True

De True waarde was altijd te behandelen als een waarde van 1. In VB .Net is deze waarde 1 geworden.

Empty

Varianten worden in VB6 altijd als EMPTY aangemaakt. Getallen worden altijd standaard 0, en string waarde worden een vbNullString.

In .Net worden varianten altijd als NOTHING aangemaakt. ( Dus met IsNothing te controleren ). Getallen worden altijd nog standaard 0 en string waarden nog steeds VbNullString.

Null

De Null waarde in .Net wordt niet meer ondersteund. ADO.NET waarde die NULL zijn, worden weergegeven als een object van het type DBNull.

If x Is Null then msgbox Null wordt If IsDbNull(x) then msgbox Null

Locale variabellen zijn blok geactiveerd

Gedeclareerde variabellen zijn nu echt per blok actief en te declareren. In het volgende voorbeeld:

code:

Sub Test(x As Integer)
    If x < 0 Then
      Dim y As Integer = - x
      '...
    Else
      '...
    End If
End Sub

Zou de variabelle y alleen actief zijn in het x<0 = true gedeelte, buiten dit blok ( ook niet in het else gedeelte ), is de y niet meer gedeclareerd. Dit geeft de mogelijkheid om geheugen- efficientie te vergroten. Je kan natuurlijk de y ook gewoon op sub nivo of module nivo etc declareren.

Arrays

Met Option Base kon je aangeven of je arrays op 0 of op 1 werden geinitializeert. In .Net kan dit niet meer en beginnen alle arrays gewoon op 0.
Set en Let statements

Jammer, maar deze statements bestaan niet meer in .net.

Aanroepen van procedures

Alle procedures moeten in .Net worden aangeroepen met haakjes eromheen en met de call procedure ervoor. Je kon in VB6 wel eens een procedure als volgt aanroepen:

DoeDit Met deze string

Wordt:

Call DoeDit(Met deze string)

Static procedures

In VB6 kon je een procedure als volgt declareren:

code:

Static Sub Toongetal(intgetal as integer)
Dim intX as Integer

    Msgbox intX
    Intx = intgetal

End sub

Alle variabellen binnen de sub waren dan statisch. Als je de sub 1 maal uitvoert met waarde 30, zal deze de eerste keer als message 0 teruggeven, maar de intX wordt dan wel ( ook buiten de sub ) nog onthouden. De volgende keer dat een getal wordt meegegeven, zal dus eerst het voorgaande nummer ( 30 ) getoond worden, voordat dit getal wordt overschreven.

In VB .NET is dit wat anders, static subs bestaan niet meer, maar variabellen kunnen wel als statisch worden opgegeven. Dit moet dan wel PER variabelle opgegeven worden ( in VB6 werden ALLE variabellen binnen een static sub automatisch statisch ). Voorbeeld om deze sub in .net te maken:

code:

Sub Toongetal(intgetal as integer)
Static intx as Integer

    Msgbox intx
    Intx = intgetal

End sub

Byval en Byref

In VB6 worden alle parameters waarbij niet specifiek ByVal of ByRef opgegeven wordt geinterpreteerd als ByRef. In .NET wordt dit standaar ByVal.

IsMissing

In VB6 kan je voor optionele varianten parameters in een sub kijken of ze zijn meegegeven door de functie IsMissing ( let op, werkt alleen op varianten!, strings zijn standaard vbnullstring en getallen worden 0 als ze niet zijn meegegeven ).

In VB .NET bestaat de IsMissing niet meer, omdat je voor alle optionele parameters een default waarde moet meegeven. Als ze dan dus niet meegegeven zijn krijgen ze die default waarde.

As Any parameter

In een Declare type kan je een type die voor 2 of meer waarde doorgegeven kan worden declareren als AS ANY ( in VB6 ), je kan dan dus bijvoorbeeld een integer of een string meegeven. Voorbeeld:

code:

Private Declare Function GetPrivateProfileString _
      Lib "kernel32" Alias "GetPrivateProfileStringA" ( _
      ByVal lpApplicationName As String, _
      ByVal lpKeyName As Any, _
      ByVal lpDefault As String, _
      ByVal lpReturnedString As String, _
      ByVal nSize As Integer, _
      ByVal lpFileName As String) As Integer

In VB .NET is dit veranderd. Je moet hier met het overloads statement alle mogelijke combinaties neerzetten, zodat de compiler zelf kiest welke deze neemt. Als de as any dus een integer en een string kan krijgen, zou je dat op deze manier kunnen declareren:

code:

Overloads Private Declare Function GetPrivateProfileStringKey _
      Lib "kernel32" Alias "GetPrivateProfileStringA" ( _
      ByVal lpApplicationName As String, _
      ByVal lpKeyName As String, _
      ByVal lpDefault As String, _
      ByVal lpReturnedString As String, _
      ByVal nSize As Integer, _
      ByVal lpFileName As String) As Integer
Overloads Private Declare Function GetPrivateProfileStringNullKey _
      Lib "kernel32" Alias "GetPrivateProfileStringA" ( _
      ByVal lpApplicationName As String, _
      ByVal lpKeyName As Integer, _
      ByVal lpDefault As String, _
      ByVal lpReturnedString As String, _
      ByVal nSize As Integer, _
      ByVal lpFileName As String) As Integer

De while loop

In VB6 wordt de While loop afgesloten met Wend. Om consistent te blijven met de overige loop structuren wordt nu in .NET afgesloten met End While.

Goto en Gosub

Alleen on error goto werkt nog in VB .NET. Alle overige gotos zou je moeten vervangen door een case statement en worden niet langer ondersteund.

File I/O

Het openen van files is drastisch veranderd om alle verschillende talen te ondersteunen. Open iets voor input als iets, zou betekenen dat open een reserved word zou zijn, en dat willen ze niet. Het open statement is daarom aangepast:

Open Mijnbestand.txt For input as #1 wordt
FileOpen( 1, Mijnbestand.txt, OpenMode.Input )

Debug.Print

In VB.Net is het Immediate window vervangen door een Immediate en een Output scherm. Het immediate window wordt gebruikt zodat gebruikers waarde kunnen invoeren en de resultaten kunnen bekijken als een applicatie in de pauze modus staat. Het Output scherm wordt gebruikt om build informatie en programma output naartoe te schrijven.

Hierdoor is Debug.Print vervangen door Debug.Writeline

Name property

De name property die je in VB6 kan gebruiken om bijvoorbeeld forms aan te geven wordt in .Net niet meer ondersteund in runtime. Je kan nog wel door de Controls collectie lopen om een control met een bepaalde naam te vinden. Je kan de .Net framework System.Reflection classes gebruiken om het te vinden.

Caption property

De Caption property is dood in .NET. Alles wordt consistent op .text gehouden.

Tag property

Aan de tag property kan je eigen waarden meegeven aan je control. Je had dit in VB 6 nodig omdat je de built in controls niet zelf uit kon breiden. In .Net kan dit wel, en als je dan een tag nodig hebt, moet je dus even een property bijbouwen om deze tag op te slaan.

ScaleMode

In VB6 kan je met de scalemode aangeven in welke eenheid geschaald moet worden. In .NET wordt alles in pixels geschaalt. Daarbij heeft .NET een betere manier om met resize om te gaan. De AutoScaleBaseResize property past automatisch de schaal aan aan de resolutie van het scherm en het lettertype dat je gebruikt.

Fonts

Fonts en controls kunnen in VB6 alle windows fonts gebruiken. In .NET kan je alleen nog maar TrueType of OpenType fonts gebruiken.

Screen.Mousepointer

Deze feature werkt momenteel niet in vb .net.

Timers

In VB6 kan je een timer interval instellen op 0, de timer is dan disabled. Een timer control heeft echter ook een property enabled. In VB .NET kan de timer interval waarde geen 0 meer zijn, maar moet met enabled worden aangegeven of de timer actief is ja of nee.

OLE Containers

In VB .Net bestaan geen ole container controlls meer, je kan wel een WebBrowser control gebruiken om als OLE container dienst te doen.

Image boxen en Pictureboxen

De .NET Picturebox control vervangt het VB6 Picturebox en image control. De picturebox ondersteunt ook geanimeerde gif afbeeldingen. Image controls bestaan dus niet meer.

Line en Shape controls

De line en shape controls bestaan niet meer, de GDI+ class in System.Drawing vervangt deze in .NET. Je moet hier de draw methode van System.Drawing voor gebruiken.

Clipboard

Je kan met .NET veel meer met het clipboard doen dan in VB6 het geval was, alleen de propertys van het clipboard statement zijn veranderd, dus zijn niet meer compatible met VB6.

DDE ( Dynamic Data Exchange )

Sommige controls hadden DDE support ( om direct data uit een database te tonen etc ), deze functionaliteit is in .NET verdwenen.

ADO, RDO en DAO code

De ADO, RDO en DAO objecten die in VB6 gebruikt konden worden om naar databases te verbinden zijn vervangen door ADO.NET, deze bied extra functionaliteit om disconnected met data te kunnen werken. Ook XML support is hier volledig geïntegreerd. ADO, RDO en DAO functionaliteit KAN echter in .NET nog wel gewoon worden gebruikt.

Msgbox

Msgbox bestaat nog wel, maar Messagebox.show is de nieuwe fancy manier om een message te tonen. Voorbeeld:

MessageBox.Show("Hello World!", "My First App")

Property declaratie

Property declaratie is goed veranderd, je hebt geen let, get en set meer voor een property, maar de property wordt nu als volgt gedeclareerd, voorbeeld:

code:

Public property MachinePart() as string

    Set
        MstrName = value
    End set

    Get
        MachinePart = mstrName
    End get

End Property

Dus eigenlijk wordt de get en de set in de property zelf afgehandeld.


Error handling

Error handling is even ietsje anders, we gebruiken nu de Try, Catch en Finally structuur. Dit werkt als volgt:

code:

    Try
        Afgevangen programmablok
    Catch
        Wordt uitgevoerd als er een fout optreed
    Finally
        Wordt altijd uitgevoerd.

Geen .show meer

Er is geen simpele form.show methode meer. Alles is in VB.Net een object geworden, dus je moet echt Dim formnaam as new formnaam doen en dan een formnaam.show geven wil je dit nog bereiken.

Return keyword

Een functie geef je in VB6 zijn return waarde door functienaam = waarde op te geven. In .NET gebruik je hier het return keyword voor, dus return waarde. Dit geeft als voordeel dat je de functienaam kan wijzigen zonder dat je dan overal je return waarde statements moet aanpassen.

Backwards compatibility

Als je echt iets mist uit VB6, kan je de namespace Microsoft.VisualBasic.Compatibility.VB6 gebruiken, deze bevat bijna alle oude VB6 functionaliteit, maar het is natuurlijk beter als je omschakelt naar de nieuwe functies.

[KO]

[quote
Als je echt iets mist uit VB6, kan je de namespace Microsoft.VisualBasic.Compatibility.VB6 gebruiken, deze bevat bijna alle oude VB6 functionaliteit, maar het is natuurlijk beter als je omschakelt naar de nieuwe functies.
[/quote]

* Dus weer onnodig veel MB's op je schijf

[mbravenboer]

Ik heb je topic titel ietsje uitgebreid.

Leuk overzichtje!

[RobzQ]

Heb je al op msdn.microsoft.com gezocht?
Volgens mij is daar een lijst beschikbaar met de verschillen en how-to upgrade..

[Anoniem: 32345]

Op woensdag 27 februari 2002 16:50 schreef mbravenboer het volgende:
Ik heb je topic titel ietsje uitgebreid.

Leuk overzichtje!

Dank je... wou je hem nog uitbreiden?

[Anoniem: 32345]

Op woensdag 27 februari 2002 16:51 schreef RobzQ het volgende:
Heb je al op msdn.microsoft.com gezocht?
Volgens mij is daar een lijst beschikbaar met de verschillen en how-to upgrade..

Zoeken naar .NET of DOTNET geeft een hoop troep waar je niks aan hebt. Een hoop van deze info komt wel van microsoft, maar ook wel wat van andere sites, en ik weet gewoon dat er duizende verschillen bij zijn.

Waarschijnlijk verschillen die MS niet zo snel wil melden , maar ik hoor al behoorlijk veel van mensen om me heen die er al mee bezig zijn en tegen van alles en nog wat aanlopen.

Van VB6 naar VB .NET is een wat grotere overstap dan van VB 5 naar 6, eigenlijk is het bijna vergelijkbaar met de stap van Quickbasic naar VB

[markvt]

unload me

werkt niet zomaar meer zonder extra stuff

[Anoniem: 32345]

Op woensdag 27 februari 2002 16:35 schreef KO het volgende:
[quote
Als je echt iets mist uit VB6, kan je de namespace Microsoft.VisualBasic.Compatibility.VB6 gebruiken, deze bevat bijna alle oude VB6 functionaliteit, maar het is natuurlijk beter als je omschakelt naar de nieuwe functies.

* Dus weer onnodig veel MB's op je schijf
[/quote]

Dat heeft alles binnen .NET wel. Maar alles zit in VB .NET mooi in dit soort namespaces verwerkt. Wel netjes, maar ook wel naar.

Je kan bijvoorbeeld niet eens meer "Open 'c:\pino.txt' for output as #1" gebruiken, neeeee... dat zit nu helemaal in een namespace, anders zou 'open' een reserved word zijn, en dat willen ze natuurlijk niet meer

Is voor mij wel even wennen, dat .NET, maar begin het wel erg leuk te vinden.

[Anoniem: 32345]

Op woensdag 27 februari 2002 17:21 schreef markvt het volgende:
unload me

werkt niet zomaar meer zonder extra stuff

Hee, cool, die wist ik dus ook nog niet. Kan je die extra stuff er ook nog bij vermelden? Want nu ben ik ineens erg nieuwschierig...

[mbravenboer]

Mammaplank: Dank je... wou je hem nog uitbreiden?

* mbravenboer werkt niet met VB of VB .NET .
Lees: geen idee wat ik erbij moet zetten .

[mbravenboer]

Mammaplank: Je kan bijvoorbeeld niet eens meer "Open 'c:\pino.txt' for output as #1" gebruiken, neeeee... dat zit nu helemaal in een namespace, anders zou 'open' een reserved word zijn, en dat willen ze natuurlijk niet meer

Het moet toch prettig zijn dat je eindelijk een nette omgeving tot je beschikking hebt? .

[whoami]

Het belangrijkste verschil: VB.NET is object georienteerd terwijl VB dat niet was.

[GBits]

Beetje offtopic:

Gaat iemand hier nog naar toe?: http://www.microsoft.com/netherlands/events/dotnet/donbox070302.asp

Misschien handig voor de frontapge, daar wordt net een quote van DonBox 'besproken'

[Woudloper]

Mammaplank:
Zoeken naar .NET of DOTNET geeft een hoop troep waar je niks aan hebt. Een hoop van deze info komt wel van microsoft, maar ook wel wat van andere sites, en ik weet gewoon dat er duizende verschillen bij zijn.

En dat levert niet zoveel resultaten... Als je de verschillen wilt weten moet je denk ik ook zoeken naar : Upgrading VB6 to .NET

Dan kom je namelijk op de volgende resultaten:

• Upgrading from Visual Basic 6.0

• Preparing Your Visual Basic 6.0 Applications for the Upgrade to Visual Basic.NET

Met name die laaste geeft ook de verschillen weer tussen VB6 en .NET.

Van VB6 naar VB .NET is een wat grotere overstap dan van VB 5 naar 6, eigenlijk is het bijna vergelijkbaar met de stap van Quickbasic naar VB

Dat valt toch wel mee , kijk maar wat Microsoft hierover zegt:

Visual Basic.NET enables a fundamental shift from traditional Windows development to building next-generation Web and n-tier applications. For this reason, your code will need to be upgraded to take advantage of Visual Basic.NET.

This happens automatically when you open a Visual Basic 6.0 project in Visual Basic.NET: the Upgrade Wizard steps you through the upgrade process and creates a new Visual Basic.NET project (your existing project is left unchanged). This is a one-way process; the new Visual Basic.NET project cannot be opened in Visual Basic 6.0.

M.a.w. je hoeft niets zelf te doen

[OMX2000]

Op woensdag 27 februari 2002 17:42 schreef Lecram het volgende:
Beetje offtopic:

Gaat iemand hier nog naar toe?: http://www.microsoft.com/netherlands/events/dotnet/donbox070302.asp

Misschien handig voor de frontapge, daar wordt net een quote van DonBox 'besproken'

Als je de kans krijgt is het zeker de moeite waard. Ik heb Dos Box twee jaar geleden op Tech-Ed gezien, en hij was een van de weinige met een goed verhaal. Hij zegt zinnige dingen!!!

[OMX2000]

Ik ben trouwens van mening dat, als je gaat overstappen naar .NET, je beter meteen C# kunt gaan leren.

[whoami]

Op woensdag 27 februari 2002 17:58 schreef OMX2000 het volgende:
Ik ben trouwens van mening dat, als je gaat overstappen naar .NET, je beter meteen C# kunt gaan leren.

Dat denk ik ook. C# is de taal van .NET.
* whoami is trouwens C# aan het leren (maar vordert niet snel wegens gebrek aan tijd)

[Prozaq]

Lees je het weer, "C# is de taal voor .net". Wat is dat nou voor onzin? Ik ben van mening dat het voor het gros van de ontwikkelaars geen ene fluit uitmaakt wat je nou eigenlijk leert.

En als je er anders over denkt, fundeer dan eens een keer die uitspraak.

[mbravenboer]

Prozaq: Lees je het weer, "C# is de taal voor .net". Wat is dat nou voor onzin?

Uiteraard moet je zelf weten welke taal je leert, maar grote onzin is deze uitspraak niet. C# is de versyntaxing van het object-model wat .NET intern gebruikt. C# is dus in feite de manier waarop op je op een beschaafde wijze exact kunt programmeren in het model wat .NET intern gebruikt. C# past daarom erg goed in .NET. C# is niet zomaar 'yet another language' die op .NET draait.

[whoami]

Op woensdag 27 februari 2002 19:07 schreef mbravenboer het volgende:

[..]

Uiteraard moet je zelf weten welke taal je leert, maar grote onzin is deze uitspraak niet. C# is de versyntaxing van het object-model wat .NET intern gebruikt. C# is dus in feite de manier waarop op je op een beschaafde wijze exact kunt programmeren in het model wat .NET intern gebruikt. C# past daarom erg goed in .NET. C# is niet zomaar 'yet another language' die op .NET draait.

zo, beter kon ik het niet verwoorden.

[Anoniem: 4283]

Op woensdag 27 februari 2002 17:22 schreef Mammaplank het volgende:
Je kan bijvoorbeeld niet eens meer "Open 'c:\pino.txt' for output as #1" gebruiken, neeeee... dat zit nu helemaal in een namespace, anders zou 'open' een reserved word zijn, en dat willen ze natuurlijk niet meer

Vreemd dat je juist dit punt aangeeft . Persoonlijk ben ik juist door zulk soort RANZIGE taalconstructies een steeds groter hekel aan VB gaan krijgen.
(mwhaa, dit is iets overdreven, want ik programmeer graag met VB, maar dit soort constructies laten me )

Heb je bijvoorbeeldje al eens een lijntje getekend in VB? Dan moet je iets doen als

code:

Form1.Line (x1, y1) - (x2, y2), diam, color, extraparams_in_de_vorm_van_LETTERS!

Dat slaat toch _HELEMAAL_ nergens op? Dat is een of andere achterlijke erving van Quickbasic die ze er in de eerste versie uit hadden moeten gooien!

Maar goed, da's mijn mening

[Prozaq]

Op woensdag 27 februari 2002 19:07 schreef mbravenboer het volgende:

[..]

C# is niet zomaar 'yet another language' die op .NET draait.

En ook niet de weg naar rome. Het zal best zo zijn dat het "de versyntaxing van het object-model wat .NET intern gebruikt" is. Maar denk je dat iemand die alleen geinteresseerd is in het maken van een programma, professioneel of niet, zich daar druk om zal maken?

Ik wil alleen duidelijk maken dat voor het grootste gedeelte van de programmeurs, het 0,0 zal uitmaken of ze nu programmeren in VB ob C#. Uitspraken als 'dit is de programmeertaal voor dotnet' geven mij de indruk dat de rest niet zou voldoen oid.

[whoami]

Op woensdag 27 februari 2002 20:11 schreef Prozaq het volgende:

[..]

Ik wil alleen duidelijk maken dat voor het grootste gedeelte van de programmeurs, het 0,0 zal uitmaken of ze nu programmeren in VB ob C#. Uitspraken als 'dit is de programmeertaal voor dotnet' geven mij de indruk dat de rest niet zou voldoen oid.

Dat zal een kwestie van persoonlijke voorkeur zijn, of je nu C# doet of VB.NET.
Maar imho kun je -ook als je VB programmeur bent- evengoed C# gaan leren ipv VB.NET, gewoon omdat de curve van VB naar VB.NET redelijk steep is volgens mij.
Maar goed, ieder zijn voorkeur.

[OMX2000]

Op woensdag 27 februari 2002 20:11 schreef Prozaq het volgende:

[..]

En ook niet de weg naar rome. Het zal best zo zijn dat het "de versyntaxing van het object-model wat .NET intern gebruikt" is. Maar denk je dat iemand die alleen geinteresseerd is in het maken van een programma, professioneel of niet, zich daar druk om zal maken?

Ik wil alleen duidelijk maken dat voor het grootste gedeelte van de programmeurs, het 0,0 zal uitmaken of ze nu programmeren in VB ob C#. Uitspraken als 'dit is de programmeertaal voor dotnet' geven mij de indruk dat de rest niet zou voldoen oid.

De rest voldoet ook zeker, dat klopt. Zij het alleen dat C# naadloos past, terwijl er in VB veranderingen zijn gemaakt om het passend te maken. Ik denk dat we over een jaar dankzij ervaring beter aan kunnen geven welke taal nu beter "past"

[Anoniem: 32345]

Op woensdag 27 februari 2002 17:51 schreef Woudloper het volgende:

[..]

En dat levert niet zoveel resultaten... Als je de verschillen wilt weten moet je denk ik ook zoeken naar : Upgrading VB6 to .NET

Dan kom je namelijk op de volgende resultaten:

• Upgrading from Visual Basic 6.0

• Preparing Your Visual Basic 6.0 Applications for the Upgrade to Visual Basic.NET

Met name die laaste geeft ook de verschillen weer tussen VB6 en .NET.
[..]

Dat valt toch wel mee , kijk maar wat Microsoft hierover zegt:
[..]

M.a.w. je hoeft niets zelf te doen

Dat zeggen ze wel ja , maar ik krijg het simpelste project hier nog niet automatisch geconverteerd, allemaal upgrade errors etc. Kan je nog een halve studie voor gaan volgen om dat weer leuk te laten lopen .

Bedankt voor je links trouwens :)! Kunnen alle info goed gebruiken hier.

[Anoniem: 32345]

Op woensdag 27 februari 2002 19:27 schreef KoenM het volgende:

[..]

Vreemd dat je juist dit punt aangeeft . Persoonlijk ben ik juist door zulk soort RANZIGE taalconstructies een steeds groter hekel aan VB gaan krijgen.
(mwhaa, dit is iets overdreven, want ik programmeer graag met VB, maar dit soort constructies laten me )

Heb je bijvoorbeeldje al eens een lijntje getekend in VB? Dan moet je iets doen als

code:

Form1.Line (x1, y1) - (x2, y2), diam, color, extraparams_in_de_vorm_van_LETTERS!

Dat slaat toch _HELEMAAL_ nergens op? Dat is een of andere achterlijke erving van Quickbasic die ze er in de eerste versie uit hadden moeten gooien!

Maar goed, da's mijn mening

Dat is inderdaad heeel erg , en een beter voorbeeld dan die ik gaf inderdaad

Wat ik ook wel erg appart vind is dat ze alle shape controlls weg hebben gehaald. Je kan nou in design- time niet zomaar even een lijntje op je formulier gaan plaatsen ( of ik zie het weer helemal verkeerd ).

[Anoniem: 32345]

Op woensdag 27 februari 2002 20:11 schreef Prozaq het volgende:

[..]

En ook niet de weg naar rome. Het zal best zo zijn dat het "de versyntaxing van het object-model wat .NET intern gebruikt" is. Maar denk je dat iemand die alleen geinteresseerd is in het maken van een programma, professioneel of niet, zich daar druk om zal maken?

Ik wil alleen duidelijk maken dat voor het grootste gedeelte van de programmeurs, het 0,0 zal uitmaken of ze nu programmeren in VB ob C#. Uitspraken als 'dit is de programmeertaal voor dotnet' geven mij de indruk dat de rest niet zou voldoen oid.

De programmeurs maakt het misschien wel wat uit, tenminste, als ik voor mezelf mag spreken. Ik ga graag over naar C#, omdat ik denk dat dat toch de nieuwe programmeertaal gaat worden. De overstap is niet erg groot. Ik ben ook blij dat ik van QuickBasic ooit naar VB ben overgestapt.

Daarbij heb je hier de projectleiders, die denken nogal MS, en hebben ook het idee dat bij VB .NET de ontwikkeling van VB wel ongeveer aan zijn einde is. Alle talen worden even compatible .net gemaakt, en de bedoeling is dat C# het verder over gaat nemen ( aldus onze projectleiders ).

[Anoniem: 4283]

Op donderdag 28 februari 2002 08:46 schreef Mammaplank het volgende:
Wat ik ook wel erg appart vind is dat ze alle shape controlls weg hebben gehaald. Je kan nou in design- time niet zomaar even een lijntje op je formulier gaan plaatsen ( of ik zie het weer helemal verkeerd ).

Dat klopt idd. Het zal wel komen omdat ze bij die controls ook van deze smerige trucs uithaalden, die gelukkig maar in .Net niet meer ondersteund worden.
Maar volgens mij is het heel makkelijk om zo'n control zelf in elkaar te knutselen (of van inet te downen) dus zo'n probleem is dat ook weer niet .

[Anoniem: 32345]

Ik hoop dat ik niet net nog een groot verschil heb ontdekt, maar m'n F8 ( debug ) werkt niet, en ik kan ook nog niet zien hoe dat mogelijk is.

In VB6 was DEBUG mogelijk doordat alles door de interpretator draaide, je kon daarom ook in het immediate window direct variabelle toewijzingen aanpassen.

In .NET wordt alles direct gecompileerd, dus debuggen en het immediate window lijken me erg moeilijk. Heb ook nog niet uitgevonden hoe dat gebruikt moet worden.

Helemaal debuggen door verschillende talen in een .NET omgevind lijkt me wel erg appart.

[Anoniem: 32345]

Op donderdag 28 februari 2002 09:21 schreef KoenM het volgende:

[..]

Dat klopt idd. Het zal wel komen omdat ze bij die controls ook van deze smerige trucs uithaalden, die gelukkig maar in .Net niet meer ondersteund worden.
Maar volgens mij is het heel makkelijk om zo'n control zelf in elkaar te knutselen (of van inet te downen) dus zo'n probleem is dat ook weer niet .

Je, ik denk dat die controlls gewoon een image controll waren waar ze ook met DRAW van die lollig functies op uitvoerde. Zou dan dus wel weer simpel te realiseren zijn, maar wel vreemd dat ze die eruit hebben gelaten.

[Anoniem: 4283]

Op donderdag 28 februari 2002 09:51 schreef Mammaplank het volgende:
Ik hoop dat ik niet net nog een groot verschil heb ontdekt, maar m'n F8 ( debug ) werkt niet, en ik kan ook nog niet zien hoe dat mogelijk is.

In VB6 was DEBUG mogelijk doordat alles door de interpretator draaide, je kon daarom ook in het immediate window direct variabelle toewijzingen aanpassen.

In .NET wordt alles direct gecompileerd, dus debuggen en het immediate window lijken me erg moeilijk. Heb ook nog niet uitgevonden hoe dat gebruikt moet worden.

Helemaal debuggen door verschillende talen in een .NET omgevind lijkt me wel erg appart.

KLopt, dit is idd een van de grootste nadelen van VB.Net. Je kan in .Net van Managed talen geen code meer at run-time wijzigen. Je kan nog wel gewoon de waarde van een variabele at runtime wijzigen in het debug venster.

Hier is volgens mij zelfs al een keer een heel topic over geweest, maar die kan ik niet terugvinden .

[Prozaq]

Op donderdag 28 februari 2002 09:51 schreef Mammaplank het volgende:
Ik hoop dat ik niet net nog een groot verschil heb ontdekt, maar m'n F8 ( debug ) werkt niet, en ik kan ook nog niet zien hoe dat mogelijk is.

View-> Web Browser -> home
dan
my profile in het menu kiezen
dan bij profile VB developer kiezen

In .NET wordt alles direct gecompileerd, dus debuggen en het immediate window lijken me erg moeilijk. Heb ook nog niet uitgevonden hoe dat gebruikt moet worden.

Kan ook nog,
druk op ctrl-alt-a
tik dan in: immed
en je kunt weer immediate werken

[Adion]

F8 is gewoon standaard F11 ofzo geworden (zoals het in Visual C++ 6 was)
Je kan dit inderdaad gewoon instellen.
Ik vind het ook wel jammer dat je niet meer je code kan aanpassen at runtime. Wel vreemd eigenlijk aangezien Visual C++ 6 dat wel kon, en die moest toch ook recompilen daarvoor?

Verder lijkt het mij weinig uit te maken dat je nu naar C# of naar VB .NET gaat. VB is zo hard ingepast in .NET dat ik denk dat op dat vlak de verschillen bijzonder klein zijn.

En nog een verandering :
Een picturebox heeft geen hdc/handle meer die je naar de oude GDI functies kon sturen.
Dit is ontzettend lastig wegens upgrade redenen, maar voor nieuwe projecten vind ik het niet zo erg gezien de mogelijkheden die GDI+ bied (rotation/transparency/...)

Je kan denk ik nog wel een hdc krijgen als je een graphics object maakt, maar dat doet de upgrade wizard niet en als je toch al zoveel bent aan het veranderen kan je beter GDI+ gebruiken zoals het hoort.

[whoami]

Op donderdag 28 februari 2002 20:56 schreef Adion het volgende:

Verder lijkt het mij weinig uit te maken dat je nu naar C# of naar VB .NET gaat. VB is zo hard ingepast in .NET dat ik denk dat op dat vlak de verschillen bijzonder klein zijn.

Hmm. Microsoft heeft VB aangepast naar VB.NET en C++ naar C++.NET. En dan hebben ze gezien dat het eigenlijk een zooitje was. C++ was zo al verstoken van specifieke MS keywords en constructies en voor VB hebben ze zeer ingrijpende veranderingen moeten doen. Zo hebben de mannen (en vrouwen) bij Microsoft besloten om een heel nieuwe taal te schrijven die gebaseerd is op het .NET framework en er naadloos in past.

Uit een boek over .NET

In coding examples and press blurbs, Microsoft emphasizes C# over VB.NET. Also Microsoft plans to rely heavily on C# for future development, and to publicize a C# standard....
This facts imply that VB.NET programmers might be marginalized in the future. On the other hand, name-recognition for VB is so strong that VB.NET might just marginalize C#!

In reality, it may make little difference wether you choose to use C# of VB.NET. Just don't choose VB.NET with the hopes of making an easy transition, because it won't be.

Over die naambekendheid heeft de auteur wel een punt. Velen zullen VB zien staan en denken dat het gewoon Visual Basic is.

[Anoniem: 32345]

Thnx, ik leer ineens een hele boel van dit soort reply's. GDI+ had ik ook nog nooit van gehoord. Zou dus betekenen dat je met VB.NET nu ook een beetje leuke grafische progs zou kunnen maken...

Ik heb al wel gezien dat 3D programmeren in VB.NET erg dicht bij de mogelijkheden komt, ben benieuwd.

Weet iemand eigenlijk hoe het nou precies zit met DLL's? Ik weet dat dat allemaal helemaal anders is geworden, maar ik vroeg me even wat af...

Vroeger wat C++ volgens mij de enigste taal die 'echte' DLL library's kon maken ( weet niet meer zeker wat er nep was aan de DLL's van VB, maar er was verschil... ). Hoe zit dat nu met .NET? DLL's aanmaken hoort toch nog wel bij de mogelijkheid? Het werkt alleen even helemaal anders qua registreren enzo ( de GUC directory? ), maar kunnen alle talen nou 'echte' DLL's maken?

[whoami]

Op vrijdag 01 maart 2002 08:54 schreef Mammaplank het volgende:
Thnx, ik leer ineens een hele boel van dit soort reply's. GDI+ had ik ook nog nooit van gehoord. Zou dus betekenen dat je met VB.NET nu ook een beetje leuke grafische progs zou kunnen maken...

GDI+ is toch gewoon een evolutie van de GDI (Graphics Device Interface) zoals die er nu is? Ik zie niet in dat je daardoor plots leukere grafische progs zou kunnen maken... Je kan dit nu toch ook al? Of wat bedoel je hiermee?

Ik heb al wel gezien dat 3D programmeren in VB.NET erg dicht bij de mogelijkheden komt, ben benieuwd.

Nu kun je dat toch ook doen met de DirectX libraries?

[Anoniem: 4283]

Op vrijdag 01 maart 2002 08:54 schreef Mammaplank het volgende:
Weet iemand eigenlijk hoe het nou precies zit met DLL's? Ik weet dat dat allemaal helemaal anders is geworden, maar ik vroeg me even wat af...

Je kan in ieder geval in .Net je oude vertrouwde dll's blijven gebruiken. Je kan ook met .Net nieuwe dll's compileren, maar die kan je (uiteraard) niet in een oude omgeving gebruiken.

Het registreren is idd ook veranderd, je hebt nu een speciale directory (heette die niet Assembly ) waarin nu ook meerdere versies van dezelfde dll naast elkaar kunnen staan. Dit is idd een zeer grote verbetering. Ook is regsvr32 ook niet meer nodig .

Als je nu een applicatie wil installeren voldoet het kopieren van alle exe's en dll's meestal al!

[whoami]

Een assembly is imho geen directory maar een 'unit' met alle nodige IL-code in, dus eigenlijk zoals we nu een exe hebben, maar dan ook met de DLL's ofzo erin. (correct me if i'm wrong).

[Anoniem: 32345]

Op vrijdag 01 maart 2002 09:20 schreef whoami het volgende:

[..]

GDI+ is toch gewoon een evolutie van de GDI (Graphics Device Interface) zoals die er nu is? Ik zie niet in dat je daardoor plots leukere grafische progs zou kunnen maken... Je kan dit nu toch ook al? Of wat bedoel je hiermee?
[..]

Nu kun je dat toch ook doen met de DirectX libraries?

Gewoon een beetje transparante afbeeldingen maken, rotatie, etc. Was in VB nog wel lastig, als er nu gewoon een GDI+ in zit is dat wel grappig.

Met DirectX libraries kan je inderdaad in VB6 ook leuke dingen doen, maar dat haalde het nooit met 3D applicaties die geschreven waren in C++. Hopelijk met .Net een nieuwe revolutie daarin

[Anoniem: 32345]

Nog wat dingen die mij maken over .Net:

-De regio controle die er in zit!!!, is echt leuk, je kan tussen #Region en #End Region je eigen code delen bepalen, en daardoor een hele mooie boomstructuur van code opbouwen. Netjes en gestructureerd... erg mooie nieuwe functie.

-Eigenlijk zou het Visual Studio .XML moeten heten, want echt alles ondersteunt nu het XML gebeuren... niks mis mee

-Web Forms, je VB forms door ASP, zo kan zelfs ik nog een mooie web pagina toveren zonder dat de gebruiker daar al mijn eigen active X jes eerst voor moet gaan downloaden...

-Hier http://www.c-sharpcorner.com//Tools/APIViewerPKS.asp kan je lezen hoe je in .NET api calls kan doen... ook erg leuk.

-Hier http://www.allapi.net kan je een heeeel mooi tooltje downloaden voor alle API calls inclusief heeele duidelijke omschrijving + voorbeelden in VB en .NET. Persoonlijk vind ik die eeeerug handig, wilde het hier toch ook even melden .

-Namespaces, in het begin gigantisch wennen, nu vind ik ze wel erg handig. Weer een + puntje.

-.NET ondersteunt nu 'inner classes'. Ik heb nog geen idee wat dat is en wat ik er aan heb, maar hoor er veel mensen +++ over praten, dus het zou wel handig zijn.

En dat is het momenteel wel weer even...

[Anoniem: 22001]

Op vrijdag 01 maart 2002 12:23 schreef Mammaplank het volgende:
-Web Forms, je VB forms door ASP, zo kan zelfs ik nog een mooie web pagina toveren zonder dat de gebruiker daar al mijn eigen active X jes eerst voor moet gaan downloaden...

Als je webforms gebruikt wordt de html vanzelf gegenereerd neem ik aan, op zich leuk. Maar hoe zit het eigenlijk met de compabiliteit? Heb je daar al wat mee geprobeerd, werken webforms ook in mozilla, netscape 4 en opera. Of alleen in IE? Hoe zit het met de HTML die er uit rolt, kun je die ook aanpassen of ben je helemaal overgeleverd aan de html codeer talenten van microsoft?

[Anoniem: 32345]

Op vrijdag 01 maart 2002 12:28 schreef Zef het volgende:

[..]

Als je webforms gebruikt wordt de html vanzelf gegenereerd neem ik aan, op zich leuk. Maar hoe zit het eigenlijk met de compabiliteit? Heb je daar al wat mee geprobeerd, werken webforms ook in mozilla, netscape 4 en opera. Of alleen in IE? Hoe zit het met de HTML die er uit rolt, kun je die ook aanpassen of ben je helemaal overgeleverd aan de html codeer talenten van microsoft?

Das het aller aller aller aller aller leukste van wat ik er van hoor is dat ie het mooi voor alle browsers compatible maakt, en dat het door alles wordt ondersteunt, zonder dat je voor elke browser appart weer nare dingen moet programmeren.

I .NET.

[Anoniem: 32345]

Ik loop me nu al een tijdje rot te zoeken naar het dirlistbox en filelistbox component, die hebben ze er gewoon maar even uit gehaald... daar wordt ik toch wel weer wat minder vrolijk van.

[Scare360]

Ik denk zelf wel een nuttige aanvulling aan dit topic te kunnen geven dus daar gaan we:

Momenteel port ik een inmense 3-tier applicatie vanuit vb 6.0 naar vb.net. Resultaat:

presentatie layer:
- error handling naar de knoppen
- alle interactie met de database om de captions op te halen zuigt na de port
- interop maakt er 1 grootte zooi van

business layer
- COM/COM+ enorm bagger te porten, na alles geport te hebben is het nagenoeg onmogelijk om COM componenten te debuggen aangezien je niet naar een managed COM Component kunt vanuit de debugger indien deze allemaal managed/unmanaged code gebruiken vanuit andere componenten.
- indien je gebruik maakt van instanties van eerder aangemaakte transactie objecten heb je een probleem met porten net als ik
- error handling wederom naar de knoppen (maak gebruik van enums om de error strings op te maken)
- wederom interop zuigt
- werken met de snk, tlimb.exe is ff flink aanklooien
- zoals ik al zij debuggen vanuit de client applicatie is ondoenelijk aangezien je niet van de client naar de implementatie van de COM objecten kan steppen zoals dat in VB wel ging

Data layer:
- wederom MTS die dwarsligt...alle transaction handling vanuit de business layers doen vreemd
- MTS is gewoon vet bagger, zo onvoorspelbaar als de pest indien je een procedurele opmaak in gedachten had bij je architectuur ontwerp
- ADO.NET is erg erg goed


Over het algemeen... porten is bijna niet te doen indien je aardig gedistribueerd aan het werken bent. verder is VB.NET een zwaar relaxed en productieve taal volledig OOP.

En dat zegt iemand met een C++/Java/Delphi achtergrond. Indien ik VB.NET onder de knie heb begin ik aan C#, momenteel ligt de prioriteit op .NET essentials mbt het FrameWork en VB.NET om supersnel de code te kloppen zonder veel na te hoeven denken over de syntax.

[whoami]

Op vrijdag 01 maart 2002 19:50 schreef paulgielens het volgende:
Ik denk zelf wel een nuttige aanvulling aan dit topic te kunnen geven dus daar gaan we:

Momenteel port ik een inmense 3-tier applicatie vanuit vb 6.0 naar vb.net. Resultaat:

presentatie layer:
- error handling naar de knoppen

Je moet idd wel je error handling aanpassen, maar zeg nu zelf. De error-handling in VB.NET is gebaseerd op exceptions en dat is toch een veel beter mechanisme dan die ongestructureerde on error goto constructie.

Data layer:
- MTS is gewoon vet bagger, zo onvoorspelbaar als de pest indien je een procedurele opmaak in gedachten had bij je architectuur ontwerp

Tja, het hele .NET framework is nu eenmaal object oriented...

En dat zegt iemand met een C++/Java/Delphi achtergrond. Indien ik VB.NET onder de knie heb begin ik aan C#, momenteel ligt de prioriteit op .NET essentials mbt het FrameWork en VB.NET om supersnel de code te kloppen zonder veel na te hoeven denken over de syntax.

Hmm, ik vraag me dan eigenlijk af waarom je niet direct naar C# overstapt?

[Scare360]

[b]Op vrijdag 01 maart 2002 19:54 schreef whoami het
Hmm, ik vraag me dan eigenlijk af waarom je niet direct naar C# overstapt?

Waarom? VB.NET is niets mis mee en is meer dan goed genoeg om RAD te doen. Komt nog eens bij dat als je complete in-house software in VB 6.0 geschreven is je wellicht beter gewoon naar VB.NET kunt porten. Je personeel is meestal niet zo blij als ze in een compleet nieuwe taal aan de gang moeten. Trouwens ook zonde van de investeringen in VB 6.0 ontwikkeltraject. Als " hobby'er" is het wellicht verstandiger meteen in C# te beginnen, dus vandaar dat ik prive wat tijd in C# ga steken.

ps: de meeste bebruiken error ranges in hun code om applicatie specifieke problemen te achterhalen. Tevens worden alle melding naar de NT-Application Event Log geschreven. Dit is allemaal net iets anders in VB.NET. Als je dus in ons geval alleen in de Business layer 580.000 regels code heb (in COM/COM+ objecten, MTS) met in iedere functie een andere error handler valt het allemaal iets anders uit dan dat je in simpele testprojecten of de hoe makkelijk te porten verhaaltjes van Microsoft.

Grootte appicaties zijn nagenoeg niet compleet te porten, herschrijven lijkt de enige uitweg! Probleem is dat Mic COM/COM+ in combinatie met MTS wil gaan scrappen in RC 2 van .NET en hun eigen transactie klassen introduceren (zitten er al in geloof ik alleen niet actief). Het leuke is dan dat je niet 1,2,3 snel alles port, omdat dit een nogal zinloze investering is indien je over 1 jaar weer moet overstappen naar de nieuwe .NET techniek.

Tis allemaal net iets anders in "real life"

[Anoniem: 37786]

Dankuwel voor deze informatie, hier was ik naar op zoek :):)

[Scare360]

Zijn er trouwens nog meer mensen die soortgelijke problemen oplopen? In een commerciele omgeving dan...geen thuishobby projecten. Volgens mij zijn er weinig bedrijven die echt direct begonnen zijn met porten. K'zou graag wat andere reacties horen m.b.t. dit onderwerp.

[Anoniem: 4283]

Op zondag 03 maart 2002 12:01 schreef paulgielens het volgende:
Zijn er trouwens nog meer mensen die soortgelijke problemen oplopen? In een commerciele omgeving dan...geen thuishobby projecten. Volgens mij zijn er weinig bedrijven die echt direct begonnen zijn met porten. K'zou graag wat andere reacties horen m.b.t. dit onderwerp.

Het bedrijf waar ik bij werk heeft een gezond kritische houding tegen .Net (in mijn opinie dan). We hebben een aantal programma's in VB geschreven, maar die worden voorlopig niet geport, waarom zou je ook .Net biedt niet echt grote voordelen voor zulk soort applicaties.

Volgens mij is het alleen interresant om de hele boel overnieuw te maken want dan kan je tenminste alle voordelen van .Net gebruiken, en voorkom je allerlei wazige constructies.
Maar voorlopig zijn die voordelen nog niet navernand groot om ook daadwerkelijk te porten.

Ik denk dat het verhaal heel anders komt te liggen als er nieuwe componenten / web-services bij gemaakt gaan worden, dan wordt het wel zeker interresant om die nieuwe stukken in .Net (dus dan ook maar c#) te gaan maken.

[mbravenboer]

Mammaplank: .NET ondersteunt nu 'inner classes'. Ik heb nog geen idee wat dat is en wat ik er aan heb, maar hoor er veel mensen +++ over praten, dus het zou wel handig zijn.

Geneste klassen zijn in C# alleen leuk voor de zichtbaarheid. Je kunt aangeven dat een klasse alleen nuttig is voor de interne werking van de klasse waarin deze geneste klasse zich bevindt. C# ondersteunde de laatste keer dat ik het teste echter geen lexical-scope van deze geneste klassen.

Dat maakt het idee eigenlijk een stuk minder boeiend: in een instantie van de geneste klasse 'leeft' nu niet echt in de omringende klasse, zoals dat wel bij Java het geval is... Uiteraard is hiervoor wel een eenvoudige workaround, maar jammer is het wel. Ik heb liever geen geneste klassen dan geneste klassen zonder lexicale-scope.

[Scare360]

mmm, eigenlijk nog nooit de behoefte gehad om een dergelijke constructie toe te passen. Misschien leuk om .NET tegen Java uit te zetten...

Nu ik redelijk ingewerkt ben wat .NET betreft heb ik de neiging mijn Walter Savitch Java boek er weer eens bij te pakken en lekker de 1.3 weer eens in te duiken met Collections, Observers/Observable... B, Binairy trees. Ik moet zeggen mocht er ooit een ontwikkelomgeving komen zoals VS.NET voor .NET, maar dan een voor Java dan ga ik 100% om. Het Mic gevoel zit toch in de vingers terwijl je .NET induikt.

Heb net een C# boek besteld... wellicht dat we daar iets wijzer van worden

Java vs. C#/.NET

[supermadcow]

ik ben nu ook met visual basic.net begonnen.
Maar ik heb ook ff een beginnerscursus boek geleend van iemand.
Alleen nu heb ik iets inelkaar moeten zetten maar als ik op debug druk dan zegt ie dat ie het .exe bestand mist.
Hoe kan dat, kan iemand mij helpen.

[whoami]

Klik eerst eens op run of build oid...

[whoami]

<font color="blue">
Opmerking: dit is een oud topic....</font>

[supermadcow]

whoami schreef op 14 november 2002 @ 19:41:
<font color="blue">
Opmerking: dit is een oud topic....</font>

ja ik weet het alleen ik dacht dat er alsnog wel mensen zouden reageren.
Iedergeval ik hoop het.

[whoami]

supermadcow schreef op 14 november 2002 @ 19:42:
[...]


ja ik weet het alleen ik dacht dat er alsnog wel mensen zouden reageren.
Iedergeval ik hoop het.

Ehm, ik heb gereageerd....

[supermadcow]

Ehm, ik heb gereageerd....

Dat klopt tenminste 1 iemand die nog ff wil reageren.
Thanks

[supermadcow]

whoami schreef op 14 november 2002 @ 19:30:
Klik eerst eens op run of build oid...

ik heb het allebij gedaan wat jij zei, maar hij zegt dat hij het sub_main ofzo niet kan vinden
en als ik dat build solution doe zegt ie hetzelfde

[whoami]

Dan moet je maar ff zorgen dat je een main method hebt.... Lees eens een VB.NET boek oid.

[supermadcow]

whoami schreef op 14 november 2002 @ 21:12:
Dan moet je maar ff zorgen dat je een main method hebt.... Lees eens een VB.NET boek oid.

uhm.. wat bedoel je ermee, waar zou dat moeten staan?
ik zal anders zelf nog wel ff checken, en als ik het echt niet kan vinden dan vraag ik het nog wel ff aan je, okay??

[whoami]

Ieder .NET programma moet een main method hebben, een main entry point .

In C#:

code:

public static void Main()
{
}

[supermadcow]

whoami schreef op 14 november 2002 @ 21:24:
Ieder .NET programma moet een main method hebben, een main entry point .

In C#:

code:

public static void Main()
{
}

maar hoe kan je dat dan aanzetten, is dat dan niet een optie ofzo.

[whoami]

supermadcow schreef op 14 november 2002 @ 21:26:
[...]


maar hoe kan je dat dan aanzetten, is dat dan niet een optie ofzo.

*sigh, de wizard generatie*

Neen, dat moet je zelf maken. (Maar als je VS.NET gebruikt, dan wordt dat wel automatisch al voor je aangemaakt).

[supermadcow]

oww, want dat doet ie volgens mijn dan juist niet goed.
Ik heb het ook geprobeerd al eerder op een andere computer maar toen gaf die hetzelfde aan

[supermadcow]

ik kan ook niet rebuild doen want bij alles wat ie wil doen is het dat het ...... .Form1.exe niet kan vinden

[supermadcow]

ff vraagje, is wat makkelijker om te overleggen.
Als je msn heb wil je me dan toevoegen. als je je e-mail adres dan ff naar mijn andere wilt sturen graag(dus die van wanadoo)
kunnen we misschien morgen nog ff overleggen(of ik dan dus vragen stellen)

[mulder]

LiteMod whoami = new LiteMod();
whoami.Assign(new HelpDeskUser(supermadcow));
whoami.Mentor()

_sorry

[whoami]

supermadcow schreef op 14 november 2002 @ 21:47:
ff vraagje, is wat makkelijker om te overleggen.
Als je msn heb wil je me dan toevoegen. als je je e-mail adres dan ff naar mijn andere wilt sturen graag(dus die van wanadoo)
kunnen we misschien morgen nog ff overleggen(of ik dan dus vragen stellen)

Nee, sorry.... Daar heb ik geen tijd voor.
Ik zal morgen wel eens kijken en het hier dan evt posten.

Ben je trouwens wel zeker dat je het juiste type project gestart hebt?

[maikel]

Heb je die main-method al toegevoegd ?
Zo niet, doe dat dan eens al eerste.

[supermadcow]

maikel schreef op 14 November 2002 @ 23:57:
Heb je die main-method al toegevoegd ?
Zo niet, doe dat dan eens al eerste.

hoe moet ik dat dan doen, want ik ben nog maar net met vb.net begonnen dus nog een echte n00b

[maikel]

Ergens op het scherm staat een groot vlak met allemaal tekst. Daar staat allemaal code die uitgevoerd wordt. Voeg daar eens het volgende toe (copy/paste)

C++:

public static void Main()
{
}

En probeer het dan nog eens.
Overigens is het erg vreemd dat die method nog niet in de code staat (bovenaan ongeveer) aangezien dat (in VS.Net) altijd automatisch wordt toegevoegd.
Heb je 't niet zelf verwijderd dan of zo ??

Of werk je niet in VS.Net ??

[whoami]

supermadcow schreef op 15 November 2002 @ 08:48:
[...]


hoe moet ik dat dan doen, want ik ben nog maar net met vb.net begonnen dus nog een echte n00b

Wel supermadcow, ik denk dat je best eens naar de boekhandel ofzo holt en daar een boek koopt over VB.NET. (Of zoek eens op internet naar wat tutorials).
Dit is echt allemaal wel heel basic .

heropend

[ Voor 2% gewijzigd door D2k op 22-11-2002 15:05 ]

[Anoniem: 32345]

Deze vraag past wel in dit topic. Ik zoek me al de hele tijd helemaal gek naar het app.path statement in vb.net. In alle links heb ik de vervangende code hiervoor nog niet kunnen vinden. Heeft iemand enig idee hoe dit te bereiken is?

[pkouwer]

OK, effe snel tussendoor:

Ik zit met veel interesse dit topic te volgen omdat ik, als VB-programmeur, ook de overstap wil maken naar .Net Ik heb gekozen om in eerste instantie C# te leren. Ik heb wat boeken gedownload (shame on me) maar heb weinig oefenmateriaal kunnen vinden. Ik kan natuurlijk de boeken doorworstelen en hopen dat ik het kan onthouden, of praktische ervaring opdoen.

Hoe doen jullie dat, hoe brengen jullie de theorie in praktijk ? Zijn er sites (vast wel) waar ik e.e.a. aan samples kan vinden ?

[EfBe]

Anoniem: 32345 schreef op 31 December 2002 @ 17:59:
Deze vraag past wel in dit topic. Ik zoek me al de hele tijd helemaal gek naar het app.path statement in vb.net. In alle links heb ik de vervangende code hiervoor nog niet kunnen vinden. Heeft iemand enig idee hoe dit te bereiken is?

app.path statement? Het pad naar de executable oid? Al gekeken in de wonderschone properties in het 'application' object (winforms/console apps) ?

[pkouwer]

EfBe schreef op 31 december 2002 @ 18:36:
[...]

app.path statement? Het pad naar de executable oid? Al gekeken in de wonderschone properties in het 'application' object (winforms/console apps) ?

Application.ExecutablePath() ?

[Anoniem: 32345]

Dan vat ik het niet meer. Ik ben een web- form project ( sorry, solution ) begonnen. Daarin heb ik een module gemaakt. Deze module snapt helemaal geen application object. Ik heb al bij de references gekeken om te zien of ik daar iets mis, maar ik heb de system objecten. Een application object is hier alleen niet te vinden. Ik zal nu eens een gewoon project starten om te kijken of ik daar wel een application kan gebruiken. Bedankt alvast.

[Anoniem: 32345]

pkouwer schreef op 31 december 2002 @ 18:30:
OK, effe snel tussendoor:

Ik zit met veel interesse dit topic te volgen omdat ik, als VB-programmeur, ook de overstap wil maken naar .Net Ik heb gekozen om in eerste instantie C# te leren. Ik heb wat boeken gedownload (shame on me) maar heb weinig oefenmateriaal kunnen vinden. Ik kan natuurlijk de boeken doorworstelen en hopen dat ik het kan onthouden, of praktische ervaring opdoen.

Hoe doen jullie dat, hoe brengen jullie de theorie in praktijk ? Zijn er sites (vast wel) waar ik e.e.a. aan samples kan vinden ?

www.gotdotnet.com
www.vbworld.com

Persoonlijk heb ik de step by step boekenserie. Daar zitten ook voorbeeld cd-tjes bij. De boeken zijn ook wel duidelijk ( maar beginnen wel echt helemaal bij het begin, en ik heb de vervanger voor app.path er nog niet in kunnen vinden ).