[ot]
Ja, sorry, hatte nicht gesehen, dass der Moderated war - war aber IIRC auch nicht in der Liste aufgetaucht?! (Oder ich hatte ihn auch DA übersehen… jetzt ist er freigeschaltet)
[/ot]
Moin,
habe gerade mal kurz gesucht … HIDE_ON_CLOSE nutze ich gar nicht, DISPOSE_ON_CLOSE in 19 Dialogklassen, von denen hier im Streßtest jedoch nur eine einzige (Login-Dialog) relevant ist, da alles andere beim Streßtest durch eine automatische Meldungsbearbeitung unterdrückt wird (es gibt eine bool’sche Variable, die das Ansprechen entsprechender Dialoge unterdrückt).
Ich werde heute nochmal händisch mit den Debugger Stück für Stück durch die Meldungsdarstellung, da ich gestern das Gefühl hatte, dass hier an einigen Stellen während des Bildschirmaufbaus die Zahl der USER-Objecte nach oben ging …
Gruß Klaus
Hier könnte aber der Pudelskern liegen.
Ich hatte einmal das Problem, dass sich ein von mir entwickeltes Java Programm nicht mehr terminieren lies. Lösung war, dass ich einen Jdialog zwar angelegt hatte. (new JDialog aber diesen auf Grund von verschiedenen Logiken nie sichtbar gemacht habe und daher auch nie disposed wurde.
Ich weiß nicht wie diese „Unterdrückung“ funktioniert aber wenn dennoch der JDialog (oder ein anderes Fenster) angelegt wird, kann dies dennoch dein Verhalten erklären.
Nur als Denkanstoß
Lg
YES !! :lol: ich habe es gefunden :lol:
Bei der Aufbereitung einer Meldung zur Anzeige im Programm wurden an einer bestimmten Stelle fünf (!!) neue Dialoge erzeugt und mit bestimmten Daten gefüllt.
Am Ende nur sie dann dann nur an einer Stelle im Code mit einer eigenen Methode “disposeDialogs” gecancelt (die wirklich ein dispose für alle fünf durchführte), aber an weiteren Stellen wurde tatsächlich nur auf ‘null’ gesetzt. Rufe jetzt an diesen anderen Stellen ebenfalls die genannte Methode auf und die Objekte bleiben stabil bei 37 Stück !!!
Vielen Dank an @Marco13
Gruß Klaus
Hey Glückwunsch!
Merci vielmals ::headbang
War auch ein hartes Stück Arbeit …
So las es sich hier auch, aber es hat sich gelohnt. Je nachdem wie lange die Software im regulären Einsatz so läuft, hätte es dann ja auch irgendwann zu “seltsamen Symptomen” kommen können, und sowas schwer testbares kann man ja mal so gar nicht gebrauchen.
Moin,
So könnte man es nennen - das Programm blieb dann einfach stehen 
Aber es passierte eben nur während des Streßtests! Im regulären Betrieb sind es acht-Stunden-Schichten, da wäre nix passiert! Aber Fehler ist Fehler - und der muss raus 
Ist halt die Frage, in wieweit der Streßtest die Realität abbildet …
Gruß Klaus