| Autor |
Beitrag |
aloneboy 
      
Beiträge: 45
|
Verfasst: Sa 06.09.14 13:37
Kann man etwas machen das man feststellen kann warum die Zeile135 sooft aufgerufen wird und durch wen?
|
|
jfheins
      
Beiträge: 918
Erhaltene Danke: 158
Win 10
VS 2013, VS2015
|
Verfasst: Sa 06.09.14 13:56
Das wäre ein Profiler, aber das ist nicht dein Problem.
Das ist ein Stacktrace - die Wiederholung bedeutet, dass sich sine Funktion immer direkt selbst wieder aufruft. Quasi eine Endlosrekursion:
C#-Quelltext 1: 2: 3: 4: 5:
| private void Formgeschlossen(object sender,EventArgs e) { this.Close(); FormClosed -=new FormClosedEventHandler(Formgeschlossen); } |
der Aufruf von Close() wird wieder das FormClosed-Event auslösen. Damit wird deine Funktion wieder aufgerufen, diese ruft wieder Close() auf usw. usf.
Es ist einfach schwachsinnig, in dem FormClosed-Event nochmal Close() aufzurufen. Dann das Event bedeutet ja für gewöhnlich, dass gerade jemand Close() aufgerufen hat.
Was mich wundert, sind einige Sachen. Du schreibst was von Form3:
C#-Quelltext 1: 2: 3: 4:
| private void btn_Abschluß_Click(object sender, EventArgs e) { this.close(); } |
close() kleingeschrieben kommt mir jetzt nicht bekannt vor. und bei this.Close() sollte dann ja eigentlich Form3 geschlossen werden und nicht Form2. Und diese Zeile: C#-Quelltext 1:
| FormClosed -=new FormClosedEventHandler(Formgeschlossen); |
Ist vermutlich nutzlos. Du erzeugt erst ein neuen FormClosedEventHandler-delegaten und bittest dann darum, diesem doch bitte keine Events mehr zu schicken. Geht da nicht vielleicht sowas: C#-Quelltext 1:
| FormClosed -= Formgeschlossen; |
?
Damit das auch funktioniert, muss du dann beim abonnieren auch analog += Formgeschlossen schreiben.
Und besser die Reihenfolge umdrehen:
C#-Quelltext 1: 2: 3: 4: 5:
| private void Formgeschlossen(object sender,EventArgs e) { FormClosed -=Formgeschlossen; this.Close(); } |
Falls das alles nichts hilft, kannst du auch mal dein ganzes Projekt zippen und hochladen, dann kann man die Zusammenhänge besser sehen.
Edit:
Ich bin wohl geistig noch nicht ganz wach, und habe da Form2 und Form3 durcheinander gebracht. (Super Namen übrigens...). Dennoch macht es den Eindruck, als sei die Methode Formgeschlossen() auch als FormClose-Event von Form 2 registriert. Zumindest der StackTrace lässt das vermuten.
|
|
aloneboy 
      
Beiträge: 45
|
Verfasst: Sa 06.09.14 14:38
Hallo,
ok noch mal und ich hoffe besser dargestellt.
Aus der Hauptform
C#-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26:
| private void dataGridView_MeineAufträge_CellMouseDoubleClick(object sender, DataGridViewCellMouseEventArgs e) {
Form_Auftrag_bearbeiten Auftrag_bearbeiten = new Form_Auftrag_bearbeiten();
Auftrag_bearbeiten.FormClosed += new FormClosedEventHandler(Timer_neu_starten); Auftrag_bearbeiten.Show(); Auftrag_bearbeiten.Location = new Point((this.Width / 2 - Auftrag_bearbeiten.Width / 2) + this.Left, (this.Height / 2 - Auftrag_bearbeiten.Height / 2) + this.Top); Auftrag_bearbeiten.Owner = this;
}
public void Timer_neu_starten(object sender,EventArgs e) { } |
wird Auftrag_bearbeiten aufgerufen
in Auftrag_bearbeiten steht
C#-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22:
| Form_Auftrag_abschließen Auftrag_abschließen; private void btn_abschließen_Click(object sender, EventArgs e) { Auftrag_abschließen = new Form_Auftrag_abschließen();
Auftrag_abschließen.FormClosed += Formgeschlossen; Auftrag_abschließen.Owner = this; Auftrag_abschließen.lbl_NachrichtNr.Text = lbl_NachrichtNR.Text; Auftrag_abschließen.Show(); Auftrag_abschließen.Location = new Point((this.Width / 2 - Auftrag_abschließen.Width / 2) + this.Left, (this.Height / 2 - Auftrag_abschließen.Height / 2) + this.Top); }
private void Formgeschlossen(object sender,EventArgs e) { this.Close(); FormClosed -= Formgeschlossen; } |
Auftrag_abschließen wird aufgerufen
C#-Quelltext 1: 2: 3: 4: 5: 6: 7: 8:
| private void btn_Abschluß_Click(object sender, EventArgs e) { this.Close();
} |
Was ich nicht nachvollziehen kann ist,
Zusätzliche Informationen: Ungültiger threadübergreifender Vorgang: Der Zugriff auf das Steuerelement lbl_VerkäuferNr erfolgte von einem anderen Thread als dem Thread, für den es erstellt wurde.
das ein Zugriff auf lbl_VerkäuferNr erfolgt.
Das ist ein Label in Auftrag_abschließen und bezeichnet nur ein Textfeld.
|
|
jfheins
      
Beiträge: 918
Erhaltene Danke: 158
Win 10
VS 2013, VS2015
|
Verfasst: Sa 06.09.14 14:49
Was passiert, wenn du die Reihenfolge vertauschst?
C#-Quelltext 1: 2: 3: 4: 5:
| private void Formgeschlossen(object sender,EventArgs e) { FormClosed -= Formgeschlossen; this.Close(); } |
Zuletzt bearbeitet von jfheins am Sa 06.09.14 14:49, insgesamt 1-mal bearbeitet
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Sa 06.09.14 14:49
| Zitat: | | Auftrag_abschließen.FormClosed += Formgeschlossen; //<---- diese Änderung brachte keinen Erfolg |
| Zitat: | | FormClosed -= Formgeschlossen; //<--- diese Änderung brachte auch keinen Erfolg |
Wenn sich beide Zeilen in einer Form befinden machen sie in Kombination keinen Sinn. Du hängst den Handler an ein FormClosed Event einer anderen Form versuchst in aber an der eigenen Form abzuhängen.
Trotzdem sollten wir schauen woher der scheinbar problematische andere Thread herkommt,
Was machen die EventHandler der beiden erwähnten timer_Meine_Aufträge und timer_Auftragsbestand?
Edit | Zitat: | Was ich nicht nachvollziehen kann ist,
Zusätzliche Informationen: Ungültiger threadübergreifender Vorgang: Der Zugriff auf das Steuerelement lbl_VerkäuferNr erfolgte von einem anderen Thread als dem Thread, für den es erstellt wurde.
das ein Zugriff auf lbl_VerkäuferNr erfolgt. |
Im dispose werden alle Resourcen aller auf der Form befindlichen Controls zerstört auch lbl_VerkäuferNr. Wenn das zerstören aus einem anderen Thread erfolgt, weil dort zum Beispiel Close ausgerufen wurde, wird es einen Crossthread Call geben und lbl_VerkäuferNr ist vermutlich einfach nur zufällig das erste Control das versuchst wird zu zerstören. Darum richt das ganze auch immer noch nach einem Threaded Timer mit sehr kurzem Intervall.
|
|
aloneboy 
      
Beiträge: 45
|
Verfasst: Sa 06.09.14 15:06
Die Timer aktualisieren 2 Datagridviews in der Hauptform. Es sind zwei Timer Controls. Ich habe damit nur bewirken wollen das das event nicht neu aufgerufen werden kann, selbst wenn ich FormClosed -= Formgeschlossen; auskommentiert ist der Fehler da.
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Sa 06.09.14 15:15
Da ist zuviel Komplexität drin damit wir das erkennen können. Ich empfehle dir entweder solange Dinge weg zunehmen bis es geht (heißt nur das es dann nicht mehr knallt) oder umgekehrt auf der grünen Wiese anzufangen und deinen Code solange wieder zusammenzusetzen bis es nicht mehr geht und daraus deine Schlüsse zu ziehen. Letzteres mag insbesondere dann sinnvoll sein wenn du mittlerweile denn Faden verloren haben solltest was denn die beteiligten Einzelteile deines Codes denn jetzt genau tun
Um aus dem vorhandenen System durch Debugging die richtigen Schlüsse zu ziehen (durch betrachten aller Stacktraces aller Threads und setzen von Breakpoints an den relevanten Stellen) fehlt dir vermutlich die nötige Erfahrung und uns leider der nötige Ein- bzw. Überblick.
|
|
C#
      
Beiträge: 561
Erhaltene Danke: 65
Windows 10, Kubuntu, Android
Visual Studio 2017, C#, C++/CLI, C++/CX, C++, F#, R, Python
|
Verfasst: Sa 06.09.14 18:37
Mal ne andere Idee in Bezug auf das kleingeschriebene this.close(). Ist es möglich, dass dein neuer Code nicht kompiliert wird weil ein Fehler drin ist und du merkst nicht dass stattdessen der letzte erfolgreiche Build genutzt wird, weil du die Fehlermeldung verbannt hast?
So einen Fall gab es hier vor kurzem, deshalb ist mir das jetzt gerade eingefallen.
_________________ Der längste Typ-Name im .NET-Framework ist: ListViewVirtualItemsSelectionRangeChangedEventHandler
|
|
aloneboy 
      
Beiträge: 45
|
Verfasst: Sa 06.09.14 18:42
Daran habe ich auch noch dran gedacht, es könnte sein das ich es war der dieses Problem hatte.
Mit dem kleingeschriebenen hat es aber nicht zu tun da es ein Rechtschreibfehler von mir, hier im Forum war.
|
|
C#
      
Beiträge: 561
Erhaltene Danke: 65
Windows 10, Kubuntu, Android
Visual Studio 2017, C#, C++/CLI, C++/CX, C++, F#, R, Python
|
Verfasst: Sa 06.09.14 18:45
Dann guck mal ob das Projekt auch tatsächlich kompiliert wird. Wenn ja, zippe den Projektordner und lade ihn als Anhang hoch. Die Experten hier zerlegen den Code ratz fatz und finden den Fehler 
_________________ Der längste Typ-Name im .NET-Framework ist: ListViewVirtualItemsSelectionRangeChangedEventHandler
|
|
aloneboy 
      
Beiträge: 45
|
Verfasst: Sa 06.09.14 18:48
Wird er, da andere Änderungen laufen
|
|
C#
      
Beiträge: 561
Erhaltene Danke: 65
Windows 10, Kubuntu, Android
Visual Studio 2017, C#, C++/CLI, C++/CX, C++, F#, R, Python
|
Verfasst: Sa 06.09.14 18:50
Dann wird dir wahrscheinlich keiner mehr helfen können, wenn du deinen Code nicht hochlädst...
_________________ Der längste Typ-Name im .NET-Framework ist: ListViewVirtualItemsSelectionRangeChangedEventHandler
|
|
Th69
      

Beiträge: 4805
Erhaltene Danke: 1061
Win10
C#, C++ (VS 2017/19/22)
|
Verfasst: Sa 06.09.14 19:01
Hallo aloneboy,
ich finde den Beitrag von Ralf hier eigentlich einen guten Schlußsatz, denn mir erscheint das eher ein generelles Problem bei deinem Programm zu sein.
Du solltest dir selbst die Frage stellen, ob du die Komplexität selber noch beherrschst?
Warum z.B. benötigst du drei (nicht-modale) Dialoge gleichzeitig, die auch noch gegenseitige Abhängigkeiten haben?
Auch wenn modale Dialog (ShowDialog()) heutzutage nicht mehr so angesehen sind, wäre es für dein Programm doch wesentlich einfacher (Oder müssen die anderen Forms weiterhin bedienbar bleiben)?
Du solltest lernen, deine Programm generell ein bißchen strukturierter zu gestalten.
|
|
aloneboy 
      
Beiträge: 45
|
Verfasst: Sa 06.09.14 19:13
Mit ShowDialog hatte ich es vorher und ich habe es so nicht hin bekommen das sich beide Formen schließen. Auftrag_abschließen und Auftrag_bearbeiten.
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Sa 06.09.14 19:17
Wenn du aus einer Form ShowDialog einer anderen Form aufrufst dann ~hängt~ der Code in diesem Aufruf. Erst wenn du die modale Form dann schließt wird der Code fortgesetzt. Du mußt also einfach nur nach ShowDialog im Code Close auf sich selbst aufrufen weil dahin kommst du nur wenn die mit ShowDialog geöffnete Form geschlossen wurde.
|
|
aloneboy 
      
Beiträge: 45
|
Verfasst: Sa 06.09.14 19:25
Ein weiters Problem war, das wenn ich ausserhalb des Programms klicke, das sich alle geöffneten Formen sich minimieren.
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Sa 06.09.14 19:26
| Zitat: | | Ein weiters Problem war, das wenn ich ausserhalb des Programms klicke, das sich alle geöffneten Formen sich minimieren. |
Was würde es helfen das sich die anderen Formen nicht minimieren? Da die oberste Form modal ist lässt sich eh keine andere bedienen.
|
|
aloneboy 
      
Beiträge: 45
|
Verfasst: Sa 06.09.14 19:55
Das was realisiert werden sollte und wurde ist, das alle Formen sich minimieren so wie beim LostFocus und das klappte nicht mit ShowDialog.
Moderiert von Th69: Beiträge zusammengefasst
Wenn ich in Form Auftrag_bearbeiten
C#-Quelltext 1:
| Auftrag_abschließen.Owner = this; |
auskommentiere, dann läuft es.
|
|
aloneboy 
      
Beiträge: 45
|
Verfasst: So 07.09.14 22:22
Danke Leute, habe es hin bekommen.
C#-Quelltext 1:
| Auftrag_abschließen.Owner = this.Owner; |
und das ganze läuft.
|
|