Will von form3 das ergebnis nach form 2 senden

das ganze passiert in einer Funktion oder einer Sub. Müsste das nicht reichen um die Variablen, nach ende der Sub/Funktion auf jeden Fall zu löschen / frei zu geben?

frifri schrieb:

nach ende der Sub/Funktion

Wo wäre die betreffende Codezeile?
Genau dafür gibt es Using-Blöcke, da kannst Du nicht vergessen, diese Variablen aufzuräumen, das macht das Framework für Dich.

Ich hatte jetzt nur einen kleinen Ausschnitt gepostet aber ich stelle hier gerne auch mal die gesmmte Sub ein.
aber müssten nicht in jedem Falle, ausser ich bin in der Private Sub Form1_Load, beim Verlassen der Sub, die Variablen und Ähnliches gelöscht und der Speicher wieder freigeben werden?
Interessiert mich jetzt. Dann würde ich in Zukunft einen Using Block verwenden, ausser wenn das nicht nötig ist. Wäre ja dann doppelt gemoppelt.

Kraut und Rüben. Ich will gar nicht wissen, wie der Rest aussieht (oder vielleicht doch?).
Was disposed werden kann, sollte disposed werden. Für Deine hiesigen Variablen (außer eben dlgFrmMenue) brauchst Du zum Freigeben nix weiter, die werden alle nach Beendigung der Sub entsorgt, sofern sie nicht irgendwo anders heimlich weiterverwendet werden. Schwer zu sagen bei dem Code.
-> Boolean-Vergleiche mit True sind überflüssig.
Wozu hast Du überhaupt die Abgebrochen-Variable? Schreib doch gleich If dlgFrmMenue.Abgebrochen Then Return. Wobei sich die Frage stellt, was das Besondere an Abgebrochen ist und inwieweit sich das von einem passenden DialogResult (z.B. Cancel) unterscheidet.
Ist Deine Datengrundlage eine CSV-Datei?

btw: Der Thread artet mir etwas aus. ich erwäge da einen Schnitt anzusetzen und das in einen eigenen Thread auszulagern. Ich muss nur noch schauen, wo ich den am besten ansetze …

ich mag so einfache und, für mich, übersichtliche Dinge wie Abgebrochen = True.
So verschachtelte Ausführungen ohne Variablen zu nehmen kenne ich auch aber da wirds schnell, finde ich, unübersichtlich. Von daher verwende ich gerne mal "Örtliche" Variablen um den Code übersichtlicher und einfacher zu machen.
Die CSV Daten hole ich aus einem anderen Programm. Ich selber nehme eine Access Datenbank zum speichern der Daten.
Ich mach das auch nicht beruflich oder professionell. Nur für mich.

Darum poste ich nicht so gerne einen kompletten Code hier. Man muss sich immer erklären wie schlecht man doch programmiert und dass das ja alles nix ist. Man kommt sich dann immer so dumm vor.
Ich freue mich immer wenn sich hier jemand Zeit nimmt und einem nicht beruflichem Programmierer, etwas erklärt.

Ein eigener Threat wäre vieleicht von Vorteil. Ist ja schon etwas vom Thema abgedriftet.

frifri schrieb:

Darum poste ich nicht so gerne einen kompletten Code hier. Man muss sich immer erklären wie schlecht man doch programmiert und dass das ja alles nix ist. Man kommt sich dann immer so dumm vor.

Nun, Du hast den Code von Dir aus reingestellt und klar muss man damit rechnen, dass andere dann was dazu sagen. Wenn man nur vor sich selber programmiert und andere nicht einen kritischen Blick auf die eigenen Codeigentümlichkeiten werfen lässt, kommt man m.E. nicht so gut voran wie mit kritischen Blicken. Wenn Du es dabei belassen willst, ist das Dein Ding. Aber ich habe in meiner Anwesenheit hier im Forum gelernt, dass ich nur besser werde, wenn andere meinen Code zerlegen und mir klarmachen, wo ich was vergeige, umständlich mache, mich in die falsche Richtung begebe. Bevor ich mich eben in irgendwas verrenne. Wenn Du wüsstest, wie mein Code aussah, bevor ich hier aktiv war …
Aber zu Deinem Code kann ich sonst wenig sagen, da ich den Rest nicht kenne. Daher ist die Anzahl meiner Verbesserungsvorschläge gering.

frifri schrieb:

Ich mag so einfache und, für mich, übersichtliche Dinge wie Abgebrochen = True. So verschachtelte Ausführungen ohne Variablen zu nehmen kenne ich auch aber da wirds schnell, finde ich, unübersichtlich.

Ich glaub nicht, dass der Code was an Übersichtlichkeit durch die Zusammenfassung verloren hat. Ich find's soger aussagekräftiger If dlgFrmMenue.Abgebrochen Then Return = "Wenn Dialog abgebrochen (wurde) dann verlasse Prozedur."
Ich selber würd ja eben so schreiben: If dlgFrmMenue.ShowDialog(Me) = DialogResult.Cancel Then Return, aber das wird (Dir) wohl zu kryptisch.

so komme ich dann zu meiner nächsten Frage, warum "Kraut und Rüben"?

Weil der Code sich einem Außenstehenden nicht erschließt. Und das bedeutet, dass die Chance sehr hoch ist, dass Dir das ebenfalls so geht, sobald Du ein halbes Jahr nicht mehr an den Projekt gearbeitet hast.

• Warum steht Zeile#6 nicht in Zeile#2? Warum also Variablen deklarieren, wenn sie ggf. eh nicht verwendet werden? If Text = "" meckert auch der Compiler und macht einen Gegenvorschlag, aber das ist zweitrangig.
  
• If SPKDaten_Absender.Count > 0 Then Da frag ich mich, ob es zu einem Crash kommt, wenn Count doch mal 0 ist.
  
• Zu der Datenübergabe selbst lässt sich nix sagen, da das Projektkonzept und die Datenhaltung unklar ist. DataBinding würde die ganze Geschichte wahrscheinlich auf ein Minimum verkürzen, aber das ist advanced topic plus Spekulatius.
  
• Wozu das SubForm den Namen des aufrufendenForms braucht, ist mir schleierhaft, aber auch da schlägt die Unkenntnis zu.
  
• GroupBox2_füllen - da fragt sich der Leser: Was ist diese ominöse GroupBox2? Was ist dann GroupBox1 und gibt es noch mehr durchnummerierte? Und was beherbergt diese GroupBox2 überhaupt?
  
• Der Leser fragt sich auch: Warum ist Code auskommentiert? Ist das testweise? Ist das alt? Ist das Kunst oder kann das weg?
  

VaporiZed schrieb:

Weil der Code sich einem Außenstehenden nicht erschließt. Und das bedeutet, dass die Chance sehr hoch ist, dass Dir das ebenfalls so geht, sobald Du ein halbes Jahr nicht mehr an den Projekt gearbeitet hast.

ja passiert schon mal

Warum steht Zeile#6 nicht in Zeile#2? Warum also Variablen deklarieren, wenn sie ggf. eh nicht verwendet werden? If Text = "" meckert auch der Compiler und macht einen Gegenvorschlag, aber das ist zweitrangig.

ich hab mir angewöhnt Variablen immer als erstes zu deklarieren, damit ich nicht irgendwo im Code nach den deklarationen suchen muss.
ja Zeile 6 könnte ich ganz nach oben setzen, dann würden erst keine Variablen erzeugt.

If SPKDaten_Absender.Count > 0 Then Da frag ich mich, ob es zu einem Crash kommt, wenn Count doch mal 0 ist.

Ich möchte die Daten nur einlesen wenn wenigstens ein Datensatz vorhanden ist. Wenn kein Datensatz vorhanden würde ja einlesen keinen Sinn machen.

Zu der Datenübergabe selbst lässt sich nix sagen, da das Projektkonzept und die Datenhaltung unklar ist. DataBinding würde die ganze Geschichte wahrscheinlich auf ein Minimum verkürzen, aber das ist advanced topic plus Spekulatius.

Ich hol mir die Daten aus einer CSV Datei. Die lese ich ein und nach dem verarbeiten brauche ich die Daten nicht mehr.

Wozu das SubForm den Namen des aufrufendenForms braucht, ist mir schleierhaft, aber auch da schlägt die Unkenntnis zu.

das mache ich nur für den Debugger. Da habe ich eine Übersicht woher der Aufruf kommt. Falls ich mich blöd suche und der Aufruf kam woanders her. Ist aber eigentlich überflüssig.

GroupBox2_füllen - da fragt sich der Leser: Was ist diese ominöse GroupBox2? Was ist dann GroupBox1 und gibt es noch mehr durchnummerierte? Und was beherbergt diese GroupBox2 überhaupt?

Da stehen die Daten eines Mieterkontos drinn. Ich rufe die Form DatensatzFenster auf, kann da Daten ändern und zum Schluss lese ich den Kompletten Datensatz nochmal aus der Datenbank ein um auch wirklich den aktualisierten Datensatz zu haben. Es gibt auch andere GroupBoxen. Ich benutze diese sehr gerne um die Übersichtlichkeit im Form1 zu behalten. Da kann man dann auch schnell mal alle Controls unsichtbar machen oder die Werte in den TextBoxen löschen für eine neue Eingabe oder auch manchmal alle Felder nur zum Anzeigen der Daten .Enabled = False

Der Leser fragt sich auch: Warum ist Code auskommentiert? Ist das testweise? Ist das alt? Ist das Kunst oder kann das weg?

Testweise auskommentiert.