Visual-Basic-Forum VB-Paradise.de

in VB gibt es ByRef(zweimal darfste raten, für was...)
Hier unterscheiden wir Methoden(in C++ void) und Funktionen(Rückgabewert Funktionsname in C++) natürlich sind in C++ die Bezeichnungen nicht gleich, aber das sollte hier sowiso irrelevant sein...
Ein Aufruf erfolgt ohne #PRAGMA oder sonstiges zeug, beim übergeben der Parameter musst du nichts außer die Parameter angeben(also kein ByRef oder so davor setzen...)
eine Shared Variable musst du einfach nur als Public deklarieren, dann ist diese von überall zugreifbar...so z.B. FormularName.Variablenname...
den == Operator gibt es in VB nicht, hier reicht ein einziges = als Zuweißung sowie als Vergleichsoperator..
If x = 10 Then'weißt die Variable nicht zu sondern überprüft NUR ihren Wert
x = 10 ' weißt die Variable zu
y = x = 10'(C++ y = x == 10->y bekommt True wenn x = 10...)

Fehler sollte man allgemein verhindern, deshalb immer erst abfragen, so z.B.:

Logische Operatoren:
VB - C/++
Or - |
OrElse - ||
And - &
AndAlso - &&
Not - !

Allgemein würde ich dir empfehlen das hier komplett durchzulesen: http://openbook.galileocomputing.de/einstieg_vb_2008/

Achja Programm beenden geht follgendermaßen: System.Windows.Forms.Application.Exit() - System.Windows.Forms kann in einem Formular weggelassen werden(bzw. allgemein wo System.Windows.Forms importiert wurde..)

Hallo Barto,
man merkt an deinem Posting dass du aus der C-Welt kommst ;-)

VB.NET ist eine Objektorientierte Sprache, und man sollte seine Programme auch danach ausrichten,
so sind alle "Globalen"-Variablen und Funktionen ein Verstoß gegen dieses Objektorientierte Konzept und auf einen schlechten Stil hinweisen, weswegen davon abzuraten ist.
Mehr Dazu: http://blog.bigbasti.com/tod-den-modulen-in-vb-net/

Wie jvbsl es schon sagte solltest du dir etwas Zeit nehmen und ein Buch durcharbeiten, da C und VB.NET Enorm viele Unterschiede aufweisen die du nicht auf Anhieb verstehen wirst, da du Objekte nicht gewohnt bist.

Ich würde dir auch weiterhin empfehlen nicht mit VB.NET sondern mit C# anzufangen, da dort die Syntax zu 80% der von C gleicht du aber alle Vorteile von VB.NET hast und noch mehr!

Zitat

Wie jvbsl es schon sagte solltest du dir etwas Zeit nehmen und ein Buch durcharbeiten, da C und VB.NET Enorm viele Unterschiede aufweisen die du nicht auf Anhieb verstehen wirst, da du Objekte nicht gewohnt bist.

so rießig finde ich die Unterschiede jetzt auch nicht
Ich schätze wenn er in C programmiert hat wird er auch in C++ Programmiert haben und sollte daher auch Objekte und somit die Objektorientierte Programmierung kennen...

Eine Globale Variable kann man zwar noch verwenden, aber so wie in Modulen ist nicht unbedingt empfehlenswert und ist verpönt. aber Public Shared x As String ist ebenso Global deklariert und ganz gewiss nicht falsch, dies wird nicht nur im kompletten .Net Framework mehrmals verwendet, sondern macht ein Programm meist sehr übersichtlich und man sieht, was diese darstellt, z.B. so:

Mal kurz OT:
WAS soll das denn bewirken: #PRAGMA DB_Connect(*Hndl as Intiger,DBSting as String) ?
Das scheint mit irgendwie unsinnig zu sein, bzw mir erschließt sich nicht, was das mit globlen Funktionen zu tun habe?

Zitat von »jvbsl«

aber Public Shared x As String ist ebenso Global deklariert und ganz gewiss nicht falsch, dies wird nicht nur im kompletten .Net Framework mehrmals verwendet, sondern macht ein Programm meist sehr übersichtlich

Hallo,

falsch ist es nicht, aber es ist ein schlechter Stil. In so gut wie jeder Situation kann man eine bessere, "Richtigere" Lösung finden, als eine "Globale" variable. Microsoft Vorträge raten davon auch ab, und auch MVPs verpönen diese Art der Nutzung von Variablen.
Es ist auch nicht im Sinne von OOP, weswegen es so etwas offiziell auch nicht gibt, bis auf die Relikte namens Module in VB.

Anfänger nutzen gerne diese Möglichkeiten, da diese einfach der schnellere "dirty " Weg ist die Arbeit zu erledigen. Wenn man es aber ordentlich machen will, sollte man darauf verzichten.

Zitat

falsch ist es nicht, aber es ist ein schlechter Stil. In so gut wie jeder Situation kann man eine bessere, "Richtigere" Lösung finden, als eine "Globale" variable. Microsoft Vorträge raten davon auch ab, und auch MVPs verpönen diese Art der Nutzung von Variablen.
Es ist auch nicht im Sinne von OOP, weswegen es so etwas offiziell auch nicht gibt, bis auf die Relikte namens Module in VB.

Dann nenn mir nur einen Grund, warum dieses auch im .Net Framework verwendet wird? Und zwar mehrmals? Machen die Programmierer des .Net's etwa das ganze falsch?! Ich glaube du meinst etwas anderes wie ich, weißt du überhaupt was Shared mit der Variable macht? Nenn mir eine schönere und nicht so "dirty" Methode eine Variable welche du in 100 Klassen verwenden möchtest, welche Konstant ist, oder immer von denselben dingen abhängt zu verwenden, außer als Shared in einer aussenstehenden Klasse? Etwa in jeder der 100 Klassen neu definieren? Das soll nicht dirty sein? Überleg mal scharf nach, auch performance wird Shared nicht beeinflussen, weder beim Compilen noch sonst wo, das 100 malige deklarieren würde den Compiler jedoch schonmal langsamer machen...

hallo,
ich habe nie behauptet, dass es absolut keine Situationen gibt, wo man Variablen public shared machen sollte. Ich wollte nur unterstreichen, dass man es nach Möglichkeit meiden sollte.
Zu deinem Beispiel, 100 Klassen die eine variable nutzen, ist sicherlich keine schönes Design, und auch über Threadsicherheit, und Deadlocks müsste man sich hier viele viele Gedanken machen. - Es hängt halt wie gesagt komplett von der Problemstellung ab.

Ich bin mir auch dessen bewusst, dass man solche Methoden und Variablen überall im Framework findet, die sind aber meist shared, damit man keine Instanz der Klasse erstellen muss. Mit anderen Worten, es sind Funktionen die die für alle Klassen relevant sind und es einfach keinen Sinn macht eine Instanz der Klasse zu bilden. Beispiel: Math-Klasse Alles ist shared, da es einfach keinen Sinn macht diese Klasse zu instanzieren, da es nichts ändern würde.

Zitat

Zu deinem Beispiel, 100 Klassen die eine variable nutzen, ist sicherlich keine schönes Design, und auch über Threadsicherheit, und Deadlocks müsste man sich hier viele viele Gedanken machen. - Es hängt halt wie gesagt komplett von der Problemstellung ab.

Man muss doch nicht direkt Threading verwenden, wenn man viel Klassen nimmt...Und auch da kann man Synchronisieren...

Ich habe hier außerdem nur von Shared gesprochen, bei den anderen habe ich direkt zu beginn gesagt bzw. gemeint dass diese nichts sind...xD

Wahrscheinlich reden wir nur aneinander vorbei...