ein modaler Aufruf ist zb das Form, was bei Messagebox.Show() kommt (los, probiers aus!).
Dieses Form versperrt die anderen Forms, und du kannst in deim Proggi erst weiter machen, nachdem du die Messagebox weggeklickt hast.

Bei einem unmodalen aufruf erscheint das neue Form neben dem alten, und du kannst problemlos zwischen beiden wechseln (geht natürlich nicht mit Messagebox).

Amro schrieb:

Ist es dann so, dass wenn ich eine Oberfläche im Designer erstelle (also Form mit Buttons,Textboxen etc. ), ich eigentlich eine Klasse
designe ??

ich hab mal den Satz bisserl verändert so wie ich ihn verstehen kann.
Und Antwort: Ja, so isses
Der Form-Designer ist nix als ein nützliches Tool, mit dem du durch grafische Eingaben eine Klasse programmierst. Du kannst den generierten Klassen-Code sogar angucken, musste im Solution-Explorer "Alle Dateien anzeigen" anklicksen, dann den Form1-Knoten erweitern, und die Form1.Designer.vb öffnen.
Da siehst du dann den Code, den du auf grafische Weise programmiert hast.

​MessageBox.Show ruft dann wohl oder übel intern einen Dialog auf und der wird nat. instanziiert.

Grüße

Messagebox ruft intern direkt WindowsAPI auf -> MessageBox(). Warum Form.Show() falsch ist, ist ganz einfach: Form.Show() ist nicht statisch, MessageBox.Show() wohl.

(nun hoffen wir, dass amro sich fragt, was "statisch" wohl bedeutet)

Naja, wenigstens fragt er nach . Eine Methode, oder Member einer Klasse können statisch sein, das heißt diese Methoden können nur auf statische Felder, Member und Methoden, nicht aber auf nicht statische Dinge zugreifen. Man kann auf statische Dinge ohne Instanz zugreifen, da keine gebraucht wird. Shared deklariert in VB eine Methode oder ein Feld als statisch. Statische Sachen schlagen der Objektorientierung ein Schnippchen, denn nicht alles ist mit OOP zu lösen. Im Falle MessageBox.Show(), dient dass nur der Kapselung.

@Amro Sinnigerweise verhält es sich bei der MessageBox anders als bei anderen Dialogen.
Es gibt nur MessageBox.Show(), das ist modal.
Bei Dialogen ist .Show() nicht modal, .ShowDialog() hingegen modal.
Probier dies (ohne jetzt über das fehlende Dispose reden zu wollen):

Da fehlt kein Dispose - unmodale geöffnete Forms disposen sich selbst, sobald sie geschlossen werden.
Modale geöffnete Forms hingegen disposen sich nicht - da ist dann am besten ein Using-Block - also dein Code ist perfekt, in beiden Varianten

bitte versuche sinnvolle Sätze zu formulieren.

Ein Dispose kann man nicht überprüfen. .Dispose() ist eine Objekt-Methode, daher kann es "das Dispose" gar nicht geben.

Da gibts normal auch nix zu überprüfen, man ruft .Dispose() auf, und dann ist disposed. Für Ausnahmen, bei bestimmten Klassen kann man auch .IsDisposed abprüfen, aber wie gesagt: Normal disposed man, und fasst das Objekt anschließend nicht mehr an.

Amro schrieb:

Und ist das überhaupt nötig, VB übernimmt das doch selbst mit den Garbage ?

Ja, ist nötig, für genau die Fälle (und deren gibt es viele), in denen das Aufräumen durch den GarbageCollector nicht hinlangt.
Google mal ein bischen nach "Dispose-Pattern" oder "Resourcenbereinigung".
Oder lies das entsprechende Kapitel eines guten Buchs.
Weil das Thema ist wichtig, bisserl kompliziert und sogar umstritten - bei Google ist nicht gesichert, dass du eine korrekte und vollständige Erläuterung erhälst.

Amro schrieb:

VB übernimmt das doch selbst mit den Garbage

sofern es sich um managed Ressourcen handelt.
Gelegentlich greift .NET auch auf unmanaged Ressourcen zu, die müssen disposed werden.

Amro schrieb:

Klaus Löffelmann.... War auch nicht einfach es zu bekommen.

hmm? kann man doch einfach downloaden: Entwickler-Ressourcen und Tools, Bücher und WebCasts

Da ist kein altes Zeug drin, was du nicht brauchen würdest.
Allenfalls das neuere Zeug, was seither hinzugekommen ist, entgeht dir, wenn Löffi deine einzige Lektüre bleibt, und du einzig durch Löffi2005-Lesen imstande bist, was hinzuzulernen (wonach es ja nicht aussieht ).
Aber all das neure Zeugs baut auf dem alten auf, also man kanns kaum verstehen, wenn man den Löffi2005er-Stoff nicht geschnackelt hat.

Ok, ein paar Seiten kannste auch überblättern. Etwa das Kapitel zum Umstieg von vb6 sagt dir nix, wenn du vb6 nie kennengelernt hast. (Falls du aber doch vb6 oder vba kennst, dann ist das Kapitel sehr wichtig!) Aber das merkste glaub schnell selber.

Und einiges, was er vom VisualStudio beschreibt, stimmt heutzutage nicht mehr. Aber stattdessen gibt es anderes, und deshalb darfst du diese Teile nicht überblättern, sondern musst dich auf die Suche machen, wie die beschriebenen Features heutzutage im VS umgesetzt sind.

Und jetzt lies das Kapitel zur Resourcenbereinigung nach - dann hast du aus diesem Thread hier ein Vielfaches dessen gelernt, was du eiglich gefragt hattest.