"Unendlicher Progressbar"

[himitsu]

Eventuell auch ab und man mal sowas wie ProgressMessages, denn Update zeichnet nur neu, aber die Messsages hägnen dennoch und sobald das "ragiert nicht" auf taucht, helfen auch keine Updates mehr.

Bei ProgressMessages aber unbedingt Doppel-/Fehlbedienung unterbinden, z.B. indem alles/bestimmtes Disabled wird, bzw. in der Schleife auch auf Application.Terminated reagieren.

[Benmik]

Also, ich weiß nicht, warum diese Ablehnung von Threads. Wenn man langwierige Aufgaben parallelisieren kann, dann führt doch sowieso kein Weg am Multithreading vorbei, und auch da muss man den Anwender informieren. Wenn hier nicht parallelisiert werden kann - wie dies hier angenommener Weise der Fall ist - dann würde ich doch nicht zu so komplizierten Lösungen greifen. Ich würde den MainThread nur für die VCL (Fortschrittsanzeige) benutzen, die Arbeit in einem Parallelthread verrichten und in geeigneter Weise (abhängig von Zeit oder Fortschritt) den Anwender im MainThread informieren. Damit der Anwender nicht dazwischenfuhrwerkt, kann man ja notfalls die ganze Form sperren oder ihn sonstwie einhegen.
Ich führe hier mal das Beispiel von Andreas Hausladen an, das scheint mir doch wie geschaffen für den vorliegenden Fall:

Delphi-Quellcode:

 procedure TForm1.MainProc;

  procedure DoSomething;

    procedure UpdateProgressBar(Percentage: Integer);
    begin
      ProgressBar.Position := Percentage;
      Sleep(20); // This delay does not affect the time for the 0..100 loop
                 // because UpdateProgressBar is non-blocking.
    end;

    procedure Finished;
    begin
      ShowMessage('Finished');
    end;

  var
    I: Integer;
  begin
    for I := 0 to 100 do
    begin
      // Do some time consuming stuff
      Sleep(30);
      LocalAsyncVclCall(@UpdateProgressBar, I); // non-blocking
    end;
    LocalVclCall(@Finished); // blocking
  end;

var
  a: IAsyncCall;
begin
  a := LocalAsyncCall(@DoSomething);
  a.ForceDifferentThread; // Do not execute in the main thread because this will
                          // change LocalAyncVclCall into a blocking LocalVclCall
  // do something
  //a.Sync; The Compiler will call this for us in the Interface._Release method
end;

[Uwe Raabe]

Zitat von Benmik:

Also, ich weiß nicht, warum diese Ablehnung von Threads.

Erfahrung.

[stahli]

@Benmik

Zitat von skoschke:

Die langwierige Aufgabe ist die Erzeugung von Komponenten und das Laden von denen mit Inhalt.

Irgendwie sehe ich da Probleme das in einen Thread auszulagern?
Da müsste der Thread ja im MainForm Konmponenten erzeugen und füllen, macht man so etwas?

Ciao
Stefan

In dem Thread würden wohl vorrangig Tätigkeiten ausgeführt, die die VCL betreffen.
Da müsste dann jeder Schritt synchronisiert werden.
Das macht keinen Sinn.

Mich würde ja nochmal eine genauere Aussage interessieren, was da aufgebaut wird, woher die Daten geholt werden und wie lange das dauert.

Ich denke immer noch, gelegentliche Zwischenstände während des Prozesses (innerhalb des Mainthreads) auszugeben, ist der einfachste und sinnvollste Weg.

[Benmik]

Zitat von Uwe Raabe:

Erfahrung.

Nach meinen Verzweiflungsphasen mit Threads kann ich dir nur sagen: Das glaube ich dir!

Aber es hilft ja nichts. Auch du musst mit Threads arbeiten.

[Benmik]

Zitat von stahli:

In dem Thread würden wohl vorrangig Tätigkeiten ausgeführt, die die VCL betreffen.

Oh Mist, das hatte ich nicht mehr auf dem Schirm.
Dann würde ich einfach immer wieder in dem VCL-Thread Nachrichten an den Anwender einbauen.

[philipp.hofmann]

Vielleicht eine andere Lösung: In meiner App läuft eh im Hauptthread ein Timer mit, der eine Uhr laufen lässt.
Wenn ich im Thread etwas mache, wo ich den Fortschritt anzeigen möchte, dann setze ich dazu Werte in einem Objekt, auf das auch der Hauptthread Zugriff hat (hat auch ein toUpdate-boolean als Trigger).

Der Hauptthread schaut nun im Timer alle 250ms, ob toUpdate=true ist und aktualisiert dann die darin stehenden Werte [z.B. eine Liste von TLabel-Objekten mit dem anzuzeigenden Wert). Das funktioniert soweit gut und ist (in meinem Fall) kein Overhead, weil ich den Timer ja eh schon habe. Damit brauche ich auch keinerlei Synchronisationen.

[skoschke]

Zitat:

Ich würde den MainThread nur für die VCL (Fortschrittsanzeige) benutzen, die Arbeit in einem Parallelthread verrichten und in geeigneter Weise (abhängig von Zeit oder Fortschritt) den Anwender im MainThread informieren

Die Arbeit besteht aber aus Komponentenerzeugung und füllen derselben, das kann nicht in einen Thread ausgelagert werden.

Ich verwende die LMDTools, speziell das LMD-Panel, welches ganz schick per Maus aus dem Hauptformular ausgedockt und frei auf dem Bildschirm positioniert werden kann.
Davon gibt es mehrere und die laden in enthaltene WPTools-Richtexts Dokumente.
Und das braucht leider etwas Zeit und während der Erzeugung eines solchen Panels und Laden desselben mit Daten wird mein Fortschritts-Thread blockiert bzw. ein auf dem Hauptformular befindliches Label nicht aktualisiert...

Ciao
Stefan

[himitsu]

Joar, Erstellen geht nur im richtigen Thread (MainThread, wo auch die VCL oder FMX läuft),

das holen der Daten ginge im Thread (bei Datenbanken und Dergleichen aber aufpassen, dass man die Connecion und Query dort erzeugt hat oder ob sie z.B. ein ThreadPooling unterstüzen)

das befullen kommt drauf an
> Edits, CheckBoxen und Dergleichen da ist das Befüllen via SendMessage threadsave
> bei ListBoxen und Grids kann man teilweise mit BeginUpdate den Haupthtread vom Update abhalten und so lange im Thread arbeiten





"kann" im Thread arbeiten = aber muß man nicht

Wenn man im Haupthtread arbeiten muß/will, dann muß man eben selbst für die regelmäßige Aktualisierung sorgen.

[Uwe Raabe]

Zitat von skoschke:

Davon gibt es mehrere und die laden in enthaltene WPTools-Richtexts Dokumente.

Falls nicht schon geschehen kannst du mal wpInstantDisplayAfterLoad aus ViewOptionsEx entfernen. Vielleicht hilft das ja etwas.