Abboniere das FormClosing-Event und reagiere dort drin. So z.B.:

Ich würd's per EventRaising machen:

...was bei genauerer Betrachtung effektiv das Gleiche ist

VaporiZed schrieb:

...was bei genauerer Betrachtung effektiv das Gleiche ist

Wobei trotzdem macht es Sinn das zu zeigen, wenn er auf veränderte Werte reagieren muss, ohne das die Form geschlossen wird, so weiss er nun schonmal wie es geht.

Events sind Ereignisse welche ausgelöst werden, wird das Event ausgelöst wird die Sub aufgerufen, welche diesem Event "zugeordnet" wurde, kennst du bestimmt schon vom Button.Click. Du kannst auch Events von anderen Objecten abbonieren, dazu brauchst du eine Sub welche die passenden Argumente nimmt.


Das hast du so ähnlich sicher schon beim Form_Load gesehen, nur das hinterdran Handles FormXYZ.FormLoad steht da siehst du welches Event vom welchem Object abboniert wurde, im Beispiel habe ich das nicht, weil ich das Event selbst abboniert habe.


Mit dem Handles... hinten dran klappt nur wenn das Object als WithEvents deklariert ist.

Schau auch mal wenn du im Designer bist im Eigenschaftenfenster, klicke dort mal auf dem Blitz, dann siehst du vom selektierten Control welche Events zur verfügung stehen, kannst sie auch dort abbonieren.

Handles Me.FormClosing

Me ist doch die Form selbst, nicht aber Frm

Wenn du das so machen möchtest dann erstmal so als "WithEvents" deklarieren, dann klappt das so:

Das in die Klasse der Form, auf welcher der Button ist.


Da jetzt die Klasse deines 2. Form wohl nicht MyForm ist, schaust mal nach wie die Klasse des 2. Form heist und nimmst anstatt MyForm den Klassennamen des 2. Forms. Wenn du sie nicht umbenannt hast z.B. Form2, Form3 etc...

Das funktioniert so nicht. Das liegt zwar nicht daran, dass Du den Microsoft.VisualBasic-Namespace drinnen hast, aber der sollte trotzdem raus.
Dein Code
zeigt ein Formular (frm vom Typ Form2) an und wertet danach, gleich nachdem dem Form per Show befehligt wird, sich zu zeigen, die Class1-Klasseninstanz (hiersollendatenrein) auf. Da ist noch nix Relevantes in frm passiert. Klar, man könnte in den Form2_Shown-EventHandler reinschreiben. Aber irgendwie hab ich das Gefühl, dass das etwas einschränkend wäre. Da soll doch bestimmt noch was auf frm/Form2 passieren, oder? Irgendwelche Eingaben z.B.

Ich bin davon ausgegangen, dass sich Deine zu manipulierende Klasseninstanz in frm befindet und Form1 die erhalten soll. Dann arbeitet man mit Events. Wenn allerdings das Unterformular eine Variable des Hauptformulars ändern soll, dann übergib vom Hauptformular die Variable an das Unterformular und fertig.


Stellt sich nur die Frage, wie bald die Variable geändert wird. Wenn man wirklich auf frm-Eingaben des Benutzers warten muss, dann geht es m.E. auch nur mit Events. Stell Dir das mit Events folgendermaßen vor.
Ein Objekt raised ein Event (per RaiseEvent) - verflucht, warum find ich auf Anhieb keine schöne Übersetzung dafür? Egal. Es geht ja um folgendes: Ein Button raised das Event Click. Das ist so, als ob der Button ne Nachricht an schwarze Brett pinnt: "Ich wurde angeklickt." Das schwarze Brett wird vielleicht ggf. von anderen Objekten angeschaut. Das sind sogenannte EventHandler. Und vielleicht ist auch ein EventHandler (oder auch mehrere) dabei, dass sich für jene Nachricht interessiert. Wenn es jene Nachricht am schwarzen Brett gibt, bekommt der EventHandler das mit und wird selbst aktiv.

Hast Du schon oft gesehen und verwendest es ja selber. Dies ist ein EventHandler namens Button1_Click. Der kann auch RäuberHotzenplotz heißen, das ist wurscht. Relevant ist, dass er sich für das Button1.Click-Event interessiert. Zu erkennen an Handles Button1.Click. Immer, wenn Button1 nen Click meldet, also ans hypothetische schwarze Brett pinnt, wird jener EventHandler, also jene Prozedur aufgerufen und ausgeführt.

Ich täte dem Konzept nochmal nach-leuchten - es ist imo nämlich noch ühaupt nicht definiert, was eiglich passieren soll.
Also in dieser Problemstellung sind 2 Unsinne drin, und müssen geklärt werden:

oobdoo schrieb:

Wie kann ich bei einem selbstgestalteten nicht modalen Fenster welches nach einem Buton Event angezeigt wird, eine Klasse als Rückgabe an mein Hauptprogramm übergeben?

1. VB hat (normalerweise) kein "Hauptprogramm".
   Es gibt ein MainForm, und wenn das geschlossen wird, ist das Programm beendet.
   Ist mit "Hauptprogramm" dieses MainForm gemeint?
   
2. ein nicht-modales Fenster hat keine Rückgabe.
   Nur bei einem modalen Fenster kann man von Rückgabe sprechen, nämlich die Rückgabe der Form.ShowDialog() - Methode. Aber genau die ist bei nicht-modal ja nicht gegeben, also was ist gemeint mit "Rückgabe"?
   Soll das Form danach geschlossen werden (wie bei einem modalen Form) oder weiter anzeigen?
   Und soll das MainForm - wenn das mit "Hauptprogramm" gemeint ist - gesperrt sein, bis die Eingabe ins Form vollzogen ist? (das ist ja meist sehr sinnvoll)
   

Aus Klärung dieser Fragen ergibt sich imo eindeutig, ob und welche der beiden bislang angedeuteten Wege gangbar ist.

Fein - du hast immerhin 2 von 4 Fragen beantwortet: Das Form soll nicht modal sein, und treffender als "Hauptprogramm" wäre, von "MainForm" zu reden:

ErfinderDesRades schrieb:

• was ist gemeint mit "Rückgabe"?
  
• Soll das Form danach geschlossen werden oder weiter anzeigen?
  

oobdoo schrieb:

So ähnlich schaut es bei mir aus.

Und wie sieht es konkret bei Dir aus? Denn der gezeigte Code ergibt m.E. überhaupt keinen Sinn.
Wenn jetzt 2 Fenster gleichzeitig offen sind (MainForm und ChildForm), was soll denn passieren, wenn jemand in MainForm an meineklasse rumspielt, dann wechselt zu ChildForm und da auch rumspielt? Welche Werte sind dann die richtigen? Das ist dann m.E. das gleiche Dilemma wie bei ner Datenbank mit mehreren Benutzern oder Multithreadingbearbeitung an den selben Daten. Da stellt sich dann auch die Frage: Wer hat recht? Bzw: Wessen Daten werden akzeptiert? Daher ist das ganze Konstrukt, welches Du anstrebst, noch fragwürdig.

hmm - ich finde den Code sinnvoll, und er wird auch wohl machen, was er machen soll: Das MainForm erzeugt ein meineKlasse-Objekt und übergibt das ans ChildForm.
Das Childform setzt irgendwelche Werte in dem Objekt.
Wird das ChildForm geschlossen, soll das MainForm das meineKlasse-Objekt auswerten.

Eiglich ist alles paletti - das MainForm muss das Form_Closed-Event des ChildForms abonnieren, und kann da die meineKlasse-Werte auswerten.

Was ist problem?

Ja, ok, meine Aussage ist möglicherweise etwas übertrieben gewesen. Wenn alles so läuft, ist ja gut.
Mir geht es darum, dass wir den "echten" Code nicht sehen. Am Ende scheitert es dann an solchen Sachen, wie wir hier schon häufiger im Forum hatten: "Es will nicht, ich habe alles genauso gemacht, wie Ihr gesagt habe. Ok, ich habe nicht meinen Originalcode gepostet. Dann eben hier der Originalcode. Ach, das hätte ich auch beachten sollen? Warum sagt mir das denn keiner? Dass es an sowas Kleinem scheitern kann. Hätte ich nicht gedacht." Dass Argumente an den Konstruktor übergeben werden, ist für mich auch so ne Sache. Ich selber mach es ungern, sondern benutz dafür ne extra Übergabe-Sub. Der Grund: Exception-swallowing. V.a. wenn die übergebende Klasseninstanz komplex ist und auch noch anfänglich vom ChildForm ausgewertet werden soll, tritt ggf. irgendwo Fehlverhalten auf und keiner weiß, warum. Da es beim TE noch Verständnisprobleme bei der Funktionsweise und Anwendung von Events geht, sehe ich somit das alles (zu?) kritisch.