Au man...ich hab´s "verbockt"!

Beim Schließen einer Midi Form / Beenden des Debugging geschieht seltsames:

Das Programm wird beendet, man sieht den Task im Taskmanager "verschwinden", aber dann taucht er an anderer Stelle wieder auf! Gleicher Name!

(Und verhindert so natürlich sehr wirksam jedes weiterarbeiten...:-)

Task gewaltsam beenden, und schon geht´s normal weiter! Neustart VB2010 hilft natürlich auch, ist aber noch nerviger.

Hatte sowas schonmal unter VB6, da half es dann, vor dem Ende, alle Childs definitiv zu entladen und sicherzustellen, das nicht irgendein Event wieder auf eine Childform zugreift und sie damit während des Beendens wieder läd. Das Problem ist prinzipiell anscheinend nicht wirklich neu, denn auch Programme wie ein älteres Outlook oder Photoeditor in Office 2000-2003 legen manchmal so ein "Ei" ab.

Aber hier komme ich nun nicht weiter....da IST definitiv nichts mehr aktiv/geladen und dummerweise habe ich auch echt keinen Schimmer mehr, an welcher "Schraube" oder Code ich da gedreht habe, bevor das Problem auftauchte. Das Einzige, was ich noch weiß, ist, das ich (unter anderem) in den Childs mit den dort benutzten ActivX "gespielt" habe. Kann ein ActiveX trotzdem aktiv bleiben, obwohl die Form schon entladen ist, und so ein normales Programmende "sabotieren"?

Gibt es in VB2010 sinngemäß so etwas wie einen "Kill All" Befehl? Oder eine Einstellung/Funktion in der MDI Form, die "sicher" alles "mitreißt"?

Du liegst vermutlich richtig. Es muß ein ähnliches gelagertes Phänomen sein. Und auch das Excel-"Ei" kenne ich leider nur zu gut...:-)

Es liegt in meinem Fall tatsächlich an den ActivX. Sobald ich die rausnehme oder durch "Dummys" ersetze, funktionierts wieder sauber. Ich konnte heute auch wieder nachvollziehen, was ich geändert habe:

Die ActiveX waren anfangs nicht sauber und korrekt eingebunden, da ich "hinterrücks" einfach neuere Versionen auf die Maschine gespielt hatte, und VB das dann so wohl nicht sauber handeln konnte. Jedenfalls waren die Events der ActivX nicht funktionsfähig. Erst, nachdem ich den alten Kram komplett manuell rausgeworfen hatte, und dann wieder neu eingebunden hatte, wurden auch Events gefeuert. Das muß aber auch wohl der Zeitpunkt gewesen sein, ab dem die ActivX ein "resistentes Eigenleben" entwickelt haben und zum Problem führten. Vielleicht sind es sogar gerade diese Events, die ständig gefeuert werden und so ein sauberes Entladen der Childforms verhindern.

In den Projekteinstellungen habe ich heute mal unter "Debugging" das Häkchen bei VB-Hosting Prozess weggenommen. (Denn der Hostingprozess war es, der im Taskmanager immer wieder hochkam) Damit ist jetzt zwar angeblich laut VB Warnung auch ein Sicherheits-Debug-Logging deaktiviert worden, aber es läuft (Beendet sich) schonmal wenigstens sauber in der Entwicklungsumgebung. Ich denke aber, das Problem wird mich später bei der fertigen Exe wieder einholen, und dann werde ich mir wohl doch nochmal den Kopf darüber machen müssen, wie ich damit umgehe. Ansatzpunkte wären die Vermeidung von selbstständigen Childformen oder auch das gezielte Entladen oder "Ausknocken" der ActiveX vor Programmende.

Bin gespannt, was da noch so an Überraschungen kommt...:-)) Eine weitere Neue durfte ich heute schon wieder erleben....aber das ist ein anderer Thread...:-)

Danke dir erstmal! Du warst bis jetzt der Einzige, dem das zumindest bekannt vorkam!

Das Ding mit Excel habe noch vor mir. Mir schwant jetzt schon Böses....:-))

Programm (noch in VB6) Steht auf Platz 5 meiner ToDo Liste, ist schätzungsweise so in ca. 3 Monaten spätestens dran. Das Ding macht ständig Gebrauch von Excel Daten und ist als "Dauerläufer" konzipiert, der eigentlich nie neu gestartet werden sollte. (Hintergrund-Prozessanalyse und Visu). Das "schreit" ja geradezu nach Problemen mit Excel-Resten im Speicher.

Aber ich kenne da jetzt jemanden in einem Forum, der da schon Erfahrung mit hat!