Zauberwort: Klassen:

Du musst die Klasse nicht direkt importieren, sofern sie nicht in einer Lib sind oder in einem Namespace.

LG

Es gibt verschiedene Arten von Klassen. Als Beispiel hab ich hier eine "normale" Klasse verwendet und eine Klasse, die eine statische Methode hat. Der Unterschied besteht darin, dass die normale Klasse(Klasse A) zu erst instanziert werden muss(also new) um auf die Methode Test zuzugreifen. Ansonsten würde man praktisch ins Leere reinprogrammieren. Bei der anderen Klasse kann man hingegen auf die Methode Testit zugreifen ohne die Klasse zu instanzieren, da die Methode als statisch deklariert ist(Stichwort:Shared(in anderen Sprachen static)).

LG

ChOoSeMyNaMe schrieb:

Es gibt verschiedene Arten von Klassen.

Du meinst hier offsichtlich verschiedene Arten von Methoden, nicht von Klassen.
Weil die "Klassen-Art" ist ja gleich, und genau genommen gibt es keine verschiedenen Arten Klassen.
Naja, man könnte ein Modul doch als besondere Art Klasse auffassen, nämlich wo nur statische Member drin sind. Aber das liegt hier ja nicht vor.

So - ich hoffe, damit genug Verwirrung gestiftet zu haben, um @CharlyVB zu überzeugen, dass er sich ein gutes Buch downloaden soll, und nicht versuchen, programmieren nur mit Fragen in Foren zu erlernen.
Foren sind prima, um die richtige Richtung gewiesen zu bekommen, aber zum Aufbau fundierter Kenntnisse - vor allem der Grund-Kenntnisse! - setze man auf gute, vorzugsweise kostenlose Bücher, wie sie u.a. in Entwickler-Ressourcen und Tools, Bücher und WebCasts gelistet sind.

Als Appetit-Happen bringt vlt. auch Grundlagen: Fachbegriffe was, aber das ist ganz absichtlich unfundiert gehalten und soll anregen, fundiertes Knowhow selbst zu recherchieren in allen Punkten, die man nicht mit absoluter Sicherheit verständnismäßig einfach abnicken kann.

Ausserdem steht noch gleichzeitig Visual Studio - Empfohlene Einstellungen auf dem Plan, damit VB.Net überhaupt als richtig objektorientierte Sprache funktioniert - ist schlimm, aber ist so, dass mans erst dafür einrichten muss, und zwar noch bevor man ühaupt einen Schimmer davon hat, was das eiglich bedeutet (der Schimmer kommt erst mit der Zeit).

Edit: Huch!

CharlyVB schrieb:

A.Test() läuft bei mir genauso.

Das kann ja garnet sein, wenn du Choomseimakenekj's Code verwendest. Oder wie hast du das zuwege gebracht?
Zum Code-Posten nutze übrigens den VB-Tag - oder hier noch eine umfangreichere Anleitung der VBP-Möglichkeiten:

CharlyVB schrieb:

A.Test() läuft bei mir genauso.

Ist A eine von Form abgeleitete Klasse?
Da ist von Microsoft noch eine alte VB6-Kompatibilität implementiert, die wir hier nicht (mehr) nutzen wollen.
Gugst Du hier, wie Formen (Dialoge) instanziiert und aufgerufen werden.

CharlyVB schrieb:

aus einer separaten .vb-Datei mit Imports einzubinden

Du kannst in .NET selbstverständlich die Implementierung einer Klasse aud mehrere Dateien verteilen:

Ich glaube, CharlyVB hat schon einiges an Plan, er kommt nur mit den Unterschieden zwischen Delphi und C#/VB.NET noch nicht ganz klar.

In Delphi werden die verschiedenen Klassen und Methoden in sogenannte Units gepackt. Das sind stinknormale Quelltext-Dateien mit Klassen und Methoden und sogar globalen Variablen und globalen Prozeduren/Funktionen. Um so eine Unit nun in einer Anwendung nutzen zu können, muß man sie in einem Uses-Block angeben. Der Compiler übersetzt das ganze dann und linkt die in der Unit verwendeten Routinen zusammen.

Dies ist in C#/VB nicht nötig. Du packst deine Source-Codedatei einfach ins Projekt und kannst das Zeug in der "Unit" dann einfach verwenden, den Rest macht der Compiler für dich. Mußte ich mich auch erst dran gewöhnen und man merkt erst mit der Zeit, wie weit Delphi selbst als XE8 hinter den modernen Sprachen herhinkt - sowohl Sprachfeature-technisch als auch IDE-technisch

Wie dem auch sei. Einen Unterschied macht es, wenn du die ausgelagerten Sourcecode-Teile in einen Namespace einschließt. Dann muß die Datei wie üblich ins Projekt hinein. Zusätzlich muß dieser Namespace mit einer imports-Anweisung in jeder Quelltext-Datei, wo das Zeug verwendet wird, mit angegeben werden - aber das war es dann auch schon.

CharlyVB schrieb:

Dass A.Test() im obigen Beispiel nicht geht, will ich gerne glauben.

Das ist eiglich nix zum glauben, sondern zum Ausprobieren.
Kopier den Code in ein VB.Net-Projekt, und sieh, wie der Compiler dich anmeckert. Learning by Doing eben

Hingegen ich glaube nicht, dasses bei dir läuft, wie du in post#3 behauptest.
Und das könntest du halt bestätigen oder widerlegen durch ein Codebeispiel von dir, wo's doch läuft (und ich's ausprobieren kann).

Deine Funktion ist auch statisch (als Shared deklariert), d.h. sie kann nicht auf Klassenmember oder Funktionen zugreifen wenn diese nicht auch statisch sind. Statisch bedeutet, dass Felder/Funktionen nur einmal existieren und zwar statisch . Jede Instanz greift aufs Selbe zu, deswegen kann man diese Felder/Funktionen auch ohne Instanz zugreifen. Entfernst du das Wörtchen Shared, dann wird das nicht mehr funktionieren.

Jo - eine statische Methode ist ein Riesen-Unterschied zu dem, was ChoosenName in Post#2 vorgegeben hatte.

CharlyVB schrieb:

mit meiner ersten Frage in einem Forum so auf die Schnauze zu fallen.

Also von Foren-Fragen stellen wollte ich dich ganz bestimmt nicht abbringen - die sind auch unerhört wichtig.
Manch einer murkelt sich da über Jahre was als Einzelkämpfer zurecht, und fragt erst, wenner dann iwann gar nimmer weiter kommt. Und dann öffnet man vlt. ein Türchen in eine ganz neue Welt, und das ist dann eine gute und eine schlechte Nachricht: Die Gute ist die neue Welt, die schlechte, dass seine komplette bisherige Arbeit für die Tonne ist.

Und was heisst "auf Schnauze fallen" - ja, hier springen lauter penetrante, streitsüchtige, kleinliche, nervtötende Rechthaber herum, und ich bin evtl. einer der Schlimmsten. Aber grade wenn ich ein Rechthaberei-Kämpfchen "verliere", grade dann habe ich gewonnen, nämlich was gelernt.

CharlyVB schrieb:

Aber gib mir erst mal die Chance zu nerven, dann verstehe ich auch Deine Reaktion.

Du musst auch unsere Reaktion verstehen.
Permanent kommen solche Nerver, da ist es schon sinnvoll, gleich das Nerven in gewisse Schranken zu weisen.