MSDN schrieb:

Eine Module-Anweisung definiert einen Verweistyp, der im gesamten Namespace verfügbar ist. Ein Modul (zuweilen auch als Standardmodul bezeichnet)ähnelt einer Klasse, doch bestehen einige wichtige Unterschiede. Jedes Modul verfügt über genau eine Instanz und muss weder erstellt noch einer Variablen zugewiesen werden. Module unterstützen keine Vererbung und implementieren keine Schnittstellen. Beachten Sie, dass ein Modul kein Typ in dem Sinn ist, in dem eine Klasse oder Struktur ein Typ ist – Sie können ein Programmierelement nicht mit einem Datentyp Modul deklarieren.

Module kann nur auf Namespaceebene verwendet werden. Dies bedeutet, dass der Deklarationskontext für ein Modul eine Quelldatei oder ein Namespace sein muss und keine Klasse, keine Struktur, kein Modul, keine Schnittstelle, keine Prozedur und kein Block sein kann. Sie können Module nicht in anderen Modulen und auch nicht in einem Typ schachteln. Weitere Informationen finden Sie unter Deklarationskontexte und Standardzugriffsebenen (Visual Basic).

Ein Modul verfügt über die gleiche Lebensdauer wie das Programm. Da alle seine Member Shared sind, entspricht deren Lebensdauer ebenfalls der Lebensdauer des Programms.

Sagt doch eigentlich schon alles oder?

und hier kannsten och mehr über Module Lesen: msdn.microsoft.com/de-de/libra…xss7da%28v=vs.100%29.aspx

Es gibt in VB keinen Grund, Module zu nutzen, es sei denn, Du implementierst Extensions.

Weiterhin gibt es keinen Grund, ein Programm künstlich in einen Wartezustand zu versetzen. Auch wenn Du es nicht hören magst. Wer hat Dir gesagt, dass Application.DoEvents() irgend eine Steuerung an andere Prozesse abgibt? Application.DoEvents verarbeitet höchstens Meldungen in der Warteschlange und der Loop treibt die CPU-Auslastung hoch. Ist umgangssprachlich bekannt als Ranz. VB.Net ist eventgesteuert. Es wartet ohnehin auf Interaktion, da gibt es nur wenige Fälle, wo ein künstlicher Wartezustand angebracht ist. Für diese Fälle gibt es verschiedene Arten von Timern.

Dein Beispiel würde ich mit einer Statischen Funktion erstellen

Aufruf:


lg

Ich stelle mir Module vorallem in der Wartung kritisch vor. Da man Ihre Methoden direkt aufrufen kann, muss man ständig im Kopf behalten, welches Modul welche Methoden beinhaltet. Schau dann mal nach nem Jahr wieder drauf, und du bist ständig am suchen^^ und so haste die Klassennamen dabei, schafft Ordnung und übersicht, und die vier Buchstaben + einen Tab die du Mehr tippst machen den Kohl auch nicht Fett.

Mir geht es eher darum, dass man die Modulfunktionen im gesamten Namespace ohne Nennung des Moduls aufrufen kann, sodass da schnell mal die übersicht verloren geht, ausser due schreibst sie dann so wie Klassen, doch dann könntest du auch gleich Klassen nehmen, da sie zukunftssicherer sind, willst du doch mal mit Interfaces Arbeiten oder Vererben, was Module, laut zitat oben ebend nicht können.

Ich verwende beides.

Ich habe meistens sogar mehrere Module in einem Program.
z.B. lagere ich im Modul "PublicVariablen" Variablen aus die ich im Programm überall brauche.
Oder im "Dirty_Modul" Lagere ich Option-Strickt-Off Methoden aus.

Außerdem würde dir bei der Benutzung auch direkt die Umsetzbarkeit in C# erhalten bleiben oder anders gesagt: In C#, dem großen kleinen Bruder von VB (neuer aber mit mehr Funktionen und von den meisten benutzt) gibt es auch keine Module, also kannst du es auch gleich lassen.

Mir erschließt sich nach wie vor nicht, wozu du jemanden 2 Sekunden auf nichts warten lassen willst. nenn mir bitte mal ein praktisches Beispiel, in dem Es nötig ist, einen Anwender auf etwas warten zu lassen, anstatt ihm sofort nach irgendeiner Interaktion etwas anzeigen zu lassen.

Ebenso erschließt sich mit nicht ganz der sinn deiner Schleife.

das "Dirty_Modul"

@nafets3646:

Das stimmt nicht. In C# gibt es Static, was dem VB-Modul wohl ziemlich nahe kommt.

@dive26:

Es dreht sich hier eigentlich um die Frage, ob Du Deine alten VB6-Gewohnheiten loslassen willst. Es ist nicht nur eine einfache Frage ob Klasse oder Modul, sondern es ist eher die Frage nach OOP oder nicht. OOP bringt Dir im weiteren Verlauf viel mehr praktischen Nutzen. Das geht auch einher mit einem Umschwenken in der Denkweise. Befasse Dich mal etwas ausführlicher mit OOP und die Frage nach einem Modul wird sich Dir nicht mehr stellen. Liegt an Dir.

Du musst die Funktion halt schon als Shared deklarieren :D.

Oder Singleton implementieren

Man sollte Leuten einfach nicht helfen die so ignorant sind. Der TE möchte seine schlechten Gewohnheiten, die absolut unbrauchbaren und schlecht wartbaren Code produzieren, beibehalten und will von OOP nichts hören.

Entweder gehst du auf die Antworten ein, oder bleib bei VB6.

Module sind das, was in C# statische Klassen sind. Wer sich den resultierenden IL anschaut, wird das auch sehen.
Deshalb sind Module immer dann zu verwenden, wenn man in C# eine statische Klasse verwenden würde.
VB unterscheidet sich da nur Syntaktisch von C#: Die einzelnen Klassenmember müssen nicht alle noch einmal angeben, dass sie statisch (Shared/static) sind. Außerdem muss man keinen Modulnamen angeben, wenn man eine Funktion aus einem Modul verwenden will (was ich ziemlich blöd finde, ist aber so).

Dieses Modul:


...würde in C# so aussehen:

Beides hat nahezu identischen IL-Code (beim Modul ist noch ein Attribut dran, aber das kann man vernachlässigen). Es gibt in VB.NET deshalb auch keine andere Möglichkeit Extension Methods zu erstellen, als mit Modulen.

Aber warum keine nicht-statische Klasse anstatt eines Moduls verwenden?
Um ein ähnliches Verhalten wie in C# zu erzeugen sieht man häufig sowas:

Das funktionert so auch, hat aber den "Nachteil", dass auch Instanzfunktionen möglich sind. Außerdem hat diese klasse einen Default-Konstruktor (Sub New()), der durch Zauberei vielleicht irgendwo aufgerufen werden könnte. Dafür kann man bei dieser Methode vererbung anwenden (warum gibt es eigentlich keine statische Vererbung?). Den Konstruktor sollte man auch - sofern man ihn nicht benötigt - Private oder Protected machen:

...um zu verhindern, dass irgendjemand davon Instanzen erstellt.

Module haben übrigens auch einen Konstruktor. Dieser ist einfach nur ein statischer Konstruktor, den es bei normalen, nicht-statischen Klassen auch gibt.


Edit:
Übrigens würde ich die Warten-Funktion imt einem Callback definieren. Spart Ressourcen und ist einfach sauberer.

nikeee13 schrieb:

Module sind das, was in C# statische Klassen sind.

Nicht ganz, es gibt einen feinen Unterschied. Member von Modulen in VB kann man von überall her aufrufen, ohne das Modul mit anzugeben, bei Membern einer statischen Klasse in C# geht das nicht, da muss man die Klasse immer vorneanstellen. Ich glaube aber, das hat eher was mit dem Compiler zu tun, nicht mit dem IL-Code.

Artentus schrieb:

Member von Modulen in VB kann man von überall her aufrufen, ohne das Modul mit anzugeben

Das habe ich oben bereits geschrieben. Es handelt sich dabei einfach um eine Eigenheit der Sprache. Irgendwer hat gesagt "so machen wir das". Es ist allerdings auch nur in VB.NET so. Will man eine VB.NET-Modulfunktion in einem C#-Programm verwenden, so muss man den Modulnamen angeben.
VB schaut dabei nur auf das von mir oben genannte Attribut. Sobald eine Klasse damit beklebt ist, ist es für VB.NET ein Modul, bei dem man den Namen nicht mehr angeben muss.

Übrigens löst der Compiler das vollständig auf, d. h. im IL wird explizit auf die Funktion via Modulname (bzw. Klassenname) zugegriffen.

dive26 schrieb:

Aber bis auf "dudu - kein Modul verwenden" macht es bei diesem Beispiel wohl keinen Unterschied ob Modul oder Klasse ?

Ganz genau erkannt: es macht keinen Unterschied, ausser dass sich dogmatisch angehauchte Leuts drüber aufregen.

(normale Klasse ist sogar bisserl ungünstiger, weil man immer erst mit New instanzieren muß - also 2 Zeilen braucht, wo Modul oder statische Methode direkt aufrufbar wären.)
Mit dogmatisch meine ich, dass losgeschimpft wird, ohne eine wirkliche Begründung zu liefern, warum nu eine Klasse oder ein Singleton soo viel besser wäre.
AFAIK werden Module wirklich in statische Klassen übersetzt, also es ist wirklich die c#-Entsprechung einer static class.
Aber ebenso richtig ist, dasses in c# besser gelöst ist, nämlich, dass nicht jede Methode einer static class von überall direkt zugreifbar ist.
Dem kann man in diesem Fall mit einem Namespace abhelfen, aber wenn das Modul eh nur eine Methode enthält, wird dadurch auch nix gewonnen, weil dann ist die Methode zwar verborgen, dafür hat man aber einen neuen Namespace rumfahren inne Intellisense.