Hallo,

ich habe eine Bibliothek geschrieben, die ich jetzt in einigen Projekten benutzen werde. Das Problem ist nur, dass die Hauptfunktion sehr rechenintensiv ist und daher das GUI des Hauptprogrammes hängt. Deswegen dachte ich mir, packe ich das ganze in einen Thread, allerdings hat die Funktion ein Ergebnis und daher muss ich irgendwie auf den Thread warten, und zwar so, dass dabei nicht wieder das GUI freezed. Die Methode darf auch nicht Application.ProcessMessages verwenden, da ich dann Forms einbinden müsste und die DLL noch aufgeblähter werden würde.

Hat jemand eine Idee?

Wie kommt man auf "Application.ProcessMessages" im Zusammenhang mit Threads?

Das geht schon mal gar nicht ... also keine Angst

Die DLL muss dem Haupt-Programm zurückmelden können, dass es jetzt fertig ist.
Suche mal nach CallBack und DLL

Zitat:

Die DLL muss dem Haupt-Programm zurückmelden können, dass es jetzt fertig ist.
Suche mal nach CallBack und DLL

Auch sowas wollte ich vermeiden, wenn es irgendwie anders geht
Es muss doch eine Möglichkeit geben, Performanceschonend zu warten oder?!

Ich würde ebenfalls eine Callback-Funktion verwenden. Also das der Thread nach dem er fertig ist eine Funktion/Procedure aufruft (die vom aufrufenden festgelegt wird) und der Funktion/Procedure das Ergebnis übergibt.
Aus welchem Grund willst du die Callback-Variante vermeiden? Wenn wir die Gründe nicht kennen wissen wir auch nicht welche Alternative für dich angebracht ist.

Zitat von WorstNightmare:

Es muss doch eine Möglichkeit geben, Performanceschonend zu warten oder?!

Ja -> Event-gesteuert -> Callback

Zitat von WorstNightmare:

Zitat:

Die DLL muss dem Haupt-Programm zurückmelden können, dass es jetzt fertig ist.
Suche mal nach CallBack und DLL

Auch sowas wollte ich vermeiden, wenn es irgendwie anders geht
Es muss doch eine Möglichkeit geben, Performanceschonend zu warten oder?!

Verstehe ich es richtig: die Funktion soll in einer DLL ausgelagert sein, da sie von vielen Anwendungen verwendet wird?

Für die Kommunikation mit der DLL gibt es neben dem Callback auch die Verwendung eines Threads in der Hauptanwendung. Denn da die Funktion einige Zeit benötigt, darf sie nicht in deren GUI-Hauptthread ausgeführt werden.

In einem eigenen Thread dagegen geht es problemlos:

markieren

Delphi-Quellcode:

...
  Result := ExecDllFunction(Params); // blockiert (den Thread) bis das Ergebnis vorliegt
  Synchronize(ShowResult)
...

Die Funktion in der DLL braucht dann auch keinen Thread zu verwenden.

Na gut, dann muss ich es eben etwas umstrukturieren.

Eigentlich wollte ich sowas (der Bequemlichkeit wegen ):

markieren

Code:

  T := TWorkThread.Create(False);
  Wait(T);
  Result := ...

@mjustin:
Dann müsste ich in jeder Anwendung diesen Thread deklarieren, deswegen wollte ich ihn gerne in der DLL haben.

Mit dem Wait gefriert doch aber auch die Anwendung. Wozu braucht man dann noch einen Thread?!