Einfrieren von Form verhindern

PlatinSecurity schrieb:

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.

@PlatinSecurity

Ich habe auch heute das erste Mal mit ASYNC gearbeitet und es war eine harte Nuss bis ich verstanden habe wie es funktioniert. War aber für meinen Anwendungfall erforderlich (Email-Abruf im Hintergrund während der User andere Sachen in der Software erledigen kann).

Jedoch stellt sich die Frage ob Du für Deine Aufgabe überhaupt ASYNC brauchst oder ob das nur unnötiger Balast und Fehlerquellen sind.
Wenn Du während der Ausführung des Konvertierungsprozesses parallel etwas machen lassen möchtest, dann kommst um ASYNC nicht herum.

Wenn Du aber eigentlich nur verhindern möchtest, dass während der Konvertierung die Form einfriert und der User ohnehin die Konvertierung abwarten muss, dann verwende einfach application.doevents().

Beispiel:



Wenn Du mit ASYNC arbeiten möchtest, dann musst Du verstehen, dass man aus einem als ASYNC aufgerufenen Methode keine Ausgaben in die Form oder andere Controls machen kann. Ich speichere zu übergebende Daten (Statusmeldungen, Zähler) in globalen Variablen DIM GlobalStatusMeldung as STRING und lese diese Variable einfach in einem Timer-Element aus. Das Timer-Element selbst kann dann die Statusmeldung in der Form oder auf einem Control ausgeben. Ich weis zwar nicht ob das die "feine englische Art" ist, aber so funktionierst bei mir.

Also ich habs so verstanden (Beispiel:)



(habe den Code gerade so aus dem FF hier reingeschrieben - sollte aber so in etwa passen)

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.

Nachdem nun alles zu des TEs Zufriedenheit funktioniert (aber noch nirgends der nun funktionierende Code zu sehen ist) kann ich ja mal anmerken, dass das hier mir überkompliziert erscheint:

PlatinSecurity schrieb:

VB.NET-Quellcode

1. Public Sub longLoad()
2. Using ConsoleProcess As New Process
3. ConsoleProcess.StartInfo.CreateNoWindow = True
4. ConsoleProcess.StartInfo.FileName = "cmd.exe"
5. ConsoleProcess.StartInfo.RedirectStandardOutput = True
6. ConsoleProcess.StartInfo.RedirectStandardInput = True
7. ConsoleProcess.StartInfo.UseShellExecute = False
8. ConsoleProcess.Start()
10. ConsoleProcess.StandardInput.WriteLine("D:\meine.exe -i " + TextBox1.Text + " " + TextBox2.Text)
11. 'Label3.Text = ConsoleProcess.StandardOutput.ReadLine()
12. ConsoleProcess.StandardInput.WriteLine("exit")
13. ConsoleProcess.WaitForExit()
14. MsgBox("Tadaaaa... Wirklich Fertig!", MsgBoxStyle.Exclamation) 'Das kommt zu erst und dann das eigentliche "Fertig" wenn man bei der MsgBox auf OK klickt.
15. End Using
16. End Sub

Da wird die cmd.exe gestartet, und dort wird dann eine Kommandozeile für meine.exe eingegeben.
Jo, da kannste die cmd doch weglassen, und meine.exe gleich per Process starten. Die Kommandozeile übergibste dabei zB im ProcessStartInfo.

PlatinSecurity schrieb:

Keine Ahnung ob das deine Frage beantwortet

Die Antwort findest Du hier:

=====
@dive26 Dein Snippet würde ich nicht in einen Task auslagern, sondern parallelisieren (sofern möglich), wobei alle verfügbaren Prozessoren eingesetzt werden:
Die ProgressBar müssste dann per Event inkrementiert und upgedatet werden.
Application.DoEvents() sind da ein NoGo.

@RodFromGermany

Parallel.For(1, 1001, berechne) Danke, wieder etwas neues gelernt.

Habs gerade mit einer rechenintensiven Schleife ausprobiert.

4-Kern Core i5:
Bei einer normalen For i Schleife wird ein Prozessorkern verwendet (25% Auslastung im Taskmanager)
Bei einer Parallel.For Schleife werden alle 4 Kerne verwendet (100% Auslastung im Taskmanager).
Dauer normale For i Schleife ca. 40000 ms.
Laut Zeitmessung ist die Parallelverarbeitung ca. 25 % schneller.

8-Kern Core i7:
Bei einer normalen For i Schleife wird ein Prozessorkern verwendet (16,7% Auslastung im Taskmanager)
Bei einer Parallel.For Schleife werden alle 8 Kerne verwendet (100% Auslastung im Taskmanager).
Dauer normale For i Schleife ca. 43000 ms.
Laut Zeitmessung ist die Parallelverarbeitung ca. 30% schneller.

Wenn man wirklich zeit- und rechenkritische Aufgaben hat, die über einen längeren Zeitraum berechnen und wo es auf jede Millisekunde ankommt, dann ist das eine super Sache. Ich für mich werde dies aber in meinen "Destop Business Anwendungen" niemals benötigen, da ich nirgends so rechen- oder zeitintensive Aufgaben zu erledigen habe. Für Spiele oder Grafik- und Videosoftware ist das aber klarerweise passend.

EDIT und NACHTRAG:
Ich nehme meine Meinung oben zurück.
Habe gerade mal ausprobiert die 4 Datenbanken, die ich bei Programmstart lade einmal normal und einmal mit Parallel zu laden und die Zeit gemessen. Da ist sehr wohl noch Luft nach oben. Aber bevor ich jetzt meine Software umbaue und mir Fehler einbaue, eine Frage. In der Sub "BefuelleAuftragsListe" befülle ich ein Listview und ein paar Controls mit Informationen. Wenn ich das nun statt "normal" mit Parallel.Invoke ausführe, kann das irgend welche ungewollten Ergebnisse bringen?

ja, weil auf Controls - auch auf LIstviewItems kann man aus einem Nebenthread nicht zugreifen - kriegst dann eine Exception.

ErfinderDesRades schrieb:

ja, weil auf Controls - auch auf LIstviewItems kann man aus einem Nebenthread nicht zugreifen - kriegst dann eine Exception.

Leider kann ich Deine Antwort nicht einordnen.

Ja, geht oder Ja, geht nicht bzw. macht Probleme?

Ich habe testweise alle Aufrufe von Subs in meiner Anwendung umgestellt und bis jetzt keine negativen Auswirkungen feststellen können. Die mit Parallel.Invoke gestarteten Subs greifen genauso auf alle Controls zu und befüllen das was sie sollen.

dive26 schrieb:

Wenn ich das nun statt "normal" mit Parallel.Invoke ausführe, kann das irgend welche ungewollten Ergebnisse bringen?

ja, es wird ungewollte Ergebnisse bringen

ErfinderDesRades schrieb:

weil auf Controls - auch auf LIstviewItems kann man aus einem Nebenthread nicht zugreifen - kriegst dann eine Exception.

ja, es wird ungewollte Ergebnisse bringen

Ich hab deshalb gefragt, weil bei mir das Listview auch vom Parallel.Invoke (AddressOf machirgendwasundbefuellelistview) ohne Exceptions befüllt wird.

Also bei mir funktionierts und Du sagtst es funktioniert nicht. Was nun ?
Oder meinst Du mit "Nebenthread" nicht Parallel.Invoke (AddressOf machirgendwasundbefuellelistview) sondern das Await Task.Run ?

Tja, weiss ich auch nicht.
Aber egal - wenns bei dir doch funzt, dann ist dein Code wohl was besonderes.

ErfinderDesRades schrieb:

Aber egal - wenns bei dir doch funzt, dann ist dein Code wohl was besonderes.

Ist jetzt nicht Dein ernst? Ich möchte niemanden verarschen.
Ich möchte es wirklich nicht besser wissen. Aber der Code funktioniert so bei mir.

Hier ein Ausschnitt aus meinem Code:



LadeAlleEmailsOhneBody lädt die Email-Daten aus der Datenbank (kein Zugriff auf irgend ein Control in dieser Routine)
ZeigeEmailsInListview gibt die Daten in einem Listview aus (unten ein Teil von ZeigeEmailsInListview)

Arbeitest du Option Strict Off?
-> Emails(Listindex).MailOrdner <> sender.Text

@mrMo

mrMo schrieb:

Arbeitest du Option Strict Off?
-> Emails(Listindex).MailOrdner <> sender.Text

Ja , aber nicht vom Thema ablenken.
Habs oben gleich ausgebessert ;-). Danke für den Hinweis.

Ich schreibe nicht in VB und habe auch das Parallel.Invoke noch nie benutzt. Aber wo im Paralell.Invoke sind die parallelen Funktionsaufrufe?
Wenn ich das richtig sehe, dann läuft da nichts paralell, kann auch nicht bei der Logik, weil du ja erst die EMails laden musst bevor du sie in die Listview schreiben kannst.

Aber wie gesagt, ich habe damit eh noch nie gearbeitet.

Dksksm schrieb:

Aber wo im Paralell.Invoke sind die parallelen Funktionsaufrufe?

Das Parallel bezieht sich darauf, dass die Routinen mit mehreren Prozessorkernen parallel abgearbeitet werden. Man muss zwar noch immer abwarten bis die Routine fertig ist, aber durch die Parallelverarbeitung mit mehreren Prozessorkernen dauert es nicht mehr ganz so lange. Parallel ist nicht Multithreading.

dive26 schrieb:

Parallel ist nicht Multithreading.

Doch.
Probierma, aus der parallelisierten Prozedur schreibend auf ein GUI-Control zuzugreigen.

Macht er doch in Post#33, z.B. Zeile#20:
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übergreifende-Prozess-Exception.

VaporiZed schrieb:

Macht er doch in Post#33, z.B. Zeile#20:
Parallel.Invoke(AddressOf ZeigeEmailsInListview)

Eben nicht, es gibt nur einen Funktionsaufruf, keine Liste fon Funktionsaufrufen, also nix mit Paralell. Und genau da smeinte ich im Post #36.

VaporiZed schrieb:

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übergreifende-Prozess-Exception.

Nun stimmst mir ja doch zu.