Hallo,
application.doevent() Anweisungen platziert
das klingt nach Excel VBA?
Gibt es so auch in VB .Net. Normalerweise sind die Programme da so strukturiert, dass die Eventschleife des Formulars leer durchläuft bis der Anwender auf ein Menü oder einen Button klickt. Dann rennt irgendeine benutzerroutine los. Alle Formularcontrols sind tot, bis die Benutzerroutine zurückkehrt. Das hat zur Folge, dass irgendwelche Veränderungen an Controls, z.B. der Text in der Statuszeile oder ein Fortschrittsbalken nicht angezeigt werden, obwohl man sie programmtechnisch tadellos auf Werteäsetzen kann. Es wird erst der letzte Wert (100%) angezeigt, wenn die eigene Routine fertig ist und das Programm wieder zur Ereignisschleife des Formulars zurückkehrt. Wenn man Ewährend der Laufzeit der eigenen Routine einen Refresh des Bildschirms wünscht, damit Fortschrittsblken laufen und Statustexte sichtbar werden, muss man das zu Fuß tun, indem man immer mal wieder application.doevents() aufruft. Das hat aber mit meinem aktuellen Problem wenig zu tun.
draußen per Catch zum Abbruch der Importschleife führt.
Und das nach VB-NET.
Treffer, versenkt 
Jetzt gibt es neuerdings Dateien, die man vollautomatisch jede
Nacht importieren will. Dazu muss der Dateiname per
Kommandozeilenparameter übergeben werden,
Warum? Das verstehe ich nicht.
Für solche Zwecke lege ich eine Verknüpfung zur .exe an,
schreibe dort die Parameter und starte diese Verknüpfung per
Taskplaner. Wozu brauchst Du da das Konsolenfenster?
Von Konsole war ja auch nie die Rede. Kommandozeilenparameter wollte ich. Da sind wir uns einig
Dann wird die Importroutine gestartet, als hätte jemand auf
den Button geklickt … (Call Command1_Click) … und ab da
läuft das Programm ohne Unterschied, wie sonst auch.
Wir nähern uns dem Kern Genau das hatte ich vor. Das Problem: WO hänge ich den eigenen Aufruf rein, damit die Statuszeile des Formulars und der Abbrechen Button verwendbar bleiben. Die Ereignisschleife wäre wohl der ideale Einhängpunkt, aber die ist AFAIK in VB.Net out of reach für den Programmierer. Klemme ich den Aufruf in Form_Load, klappts nicht weil die Eventschleife des Formulars noch nicht läuft. Klemme ich den Aufruf ins Formular, krallt sich die Eventschleife des Formulars höchstwahrscheinlich den Ablauf und wartet drauf, dass ich endlich ein Control anklicke, was ich aber nicht tun will
Es geht nicht um die Routine und die Parameter, es geht um das „WO einhängen“. So ein Formular hat ja 1000 überschreibbare Methoden, und es gibt in vb dutzende exotische Controls die ich noch nie angeschaut habe. Ich suche einen Wegweiser der mir die Sucherei abkürzt.
Hilf mir doch mal vom Schlauch, warum soll der Abbrechen
Button nicht funktionieren, wenn das Programm automatisch
gestertet wurde, wenn er doch beim manuellen Start
funktioniert?
Wegen der Eventschleife des Formulars. Starte ich sie, übernimmt sie die Kontrolle. Statusanzeige und Abbrechen Button gehen, aber wie wartet dann auf irgendeine manuelle Aktion von mir. Starte ich sie nicht, läuft mein Import automatisch, klar, aber dann werden alle Controls nicht beachtet, also keine Stausanzeige und kein Abbrechen Button, und der Application.Doevents() Trick hilft mir nicht, weil kein Formular läuft, undd amit auch keine Formular-Eventschleife die ich triggern könnte.
Vor Jahren hatte ich ein ähnliches Problem in Delphi zu lösen. Formulartechnisch arbeitet es - wie wohl alle Windows Programmiersprachen - mit demselben Event-Konzept. Damals habe ich mir so beholfen dass ich in der Load Routine des Formulars einen eigens generierten Event in die Eventschleife packe der genau dem Event entspricht der ausgelöst wird, wenn man ein bestimmtes Menü anwählt. Durch diese Art der „Selbstbefriedigung“ lief mein Formular damals automatisiert los. Am Ende meiner Routine habe ich damals den Event für den Menüpunkt „Programm beenden“ mit demselben Trick an das Formular geschickt, und das Programm hat sich brav selber beendet. Das könnte ich eventuell wieder so machen, aber ich bin irgendwie sicher dass es dafür eine bessere Lösung gibt. Außerdem gab es manchmal Event-Chaos wenn andere Events in die Eventschleife des Formulars geraten sind, das Ganze war also nicht 100% betriebssicher.
Ich habe damals keine bessere Lösung gefunden. Jetzt habe ich den Ehrgeiz, es diesmal besser zu machen
Wirds jetzt deutlicher wo mein Problem liegt?
…Armin
