Suchergebnisse

Die Prozedur-Markierung Async erfolgt im Button_Click-Prozedurkopf. Im Button_Click-Code selbst an passender Stelle das Await. Ich stell mir das dann meistens so vor: VB.NET-Quellcode (5 Zeilen) *wobei »warten« fast schon der falsche Ausdruck ist. Eigentlich ist das Programm ja eher ungeduldig und will eben nicht warten, bis die Aufgabe fertig ist, sondern sagt sich: ok, wenn die Aufgabe fertig ist, mach ich da weiter, aber inzwischen mach ich all die anderen Dinge, die so anstehen. btw: Gibt's …

Als Alternative zum Weglassen und auf Deine Frage hin, warum da was zurückgegeben werden muss: VB.NET-Quellcode (21 Zeilen) Damit Await auch weiß, wann die langatmige Aufgabe fertig ist, muss diese was zurückgeben. Wenn man dann einen Task mit Parameter angibt, erhält man jenen Parametertyp zurück. Ohne Parameter würde es dann z.B. so aussehen: VB.NET-Quellcode (6 Zeilen) Allerdings ist das nur dann sinnvoll, wenn dann in der longLoad() mit Await (weiter-)gearbeitet wird. Von daher arbeite mit m…

Wenn ich folgendes Konstrukt verwende VB.NET-Quellcode (9 Zeilen) kommt bei mit die Infobox erst, wenn die For-Loop durch ist. Kann es sein, dass Deine scheinbar langlebige Aufgabe doch nicht so viel Zeit in Anspruch nimmt und der Memory-Copy-Teil eher der Flaschenhals ist? Hau doch mal ne MessageBox ans Ende der LongLoad-Sub, um zu sehen, wann sie wirklich fertig ist.

Zitat von PlatinSecurity: „Also mein longLoad() sollte eigentlich lang lebig sein“Seh ich anders. Das geht bei mir durch wie der ICE (ok, schlechtes Beispiel). Dass die gestartete Exe noch läuft hält die Console nicht davon ab sich zu verabschieden und die Sub zu beenden.

Zum Thema DoEvents: siehe hiesigen Thread, warum (besser) nicht Das mit den globalen Variablen und dem Timer: Da wären wir dann wieder bei BeginInvoke() und Co. als Alternative. Falls jemand den Vorschlag EventRaising bringen will: geht nicht, da threadübergreifender Prozess.

Macht er doch in Post#33, z.B. Zeile#20: VB.NET-Quellcode (8 Zeilen)wobei jetzt noch unklar ist, ob das "Parallellaufen" einer Prozedur wirklich soviel bringt. Parallel ist ja anscheinend dafür gedacht, mehrere Aktionen gleichzeitig laufen zu lassen. Dass es bei @dive26 klappt, liegt m.E. nämlich nur an dem Fakt, dass er als Parameter der Parallel-Invoke-Funktion nur eine Sub-Adresse übergebt. Haut man eine zweite rein, knallt es bei mir die klassische, von vielen hier erwartete threadübergreife…

Zitat von VaporiZed: „Macht er doch“war eine Reaktion auf RfGs Aussage.Zitat von Dksksm: „Nun stimmst mir ja doch zu“. Ich stimme Dir zu. Ohne wenn und aber . Hab Deinen Post nur (mal wieder) ganz effektiv übersehen. Shame! (wie ich immer die nette Dame aus GoT zitiere, nur der Handglockenschlag fehlt leider dazu)