Alternative zu Sleep

[EWeiss]

Hällöschen

Wieder mal mein leidiges problem mit Threads und darauf warten das sie abgearbeitet wurden.

In meinen Sample für BassVis muss ich einigemale die Anweisung Sleep verwenden.
Leider habe ich festgestellt das man sich darauf nicht verlassen kann.
Mal werden in der Form die Bitmaps richtig gezeichnet mal nicht.

Irgendwie kann das doch nicht das wahr sein.

Gibt es eine gute alternative bei der man sicher sein kann das der aktuelle thread beendet wurde
bevor eine neue funktion abgearbeitet wird?

Und das ohne Sleep?

Beispiel:

Delphi-Quellcode:

procedure TfrmMain.optDefaultClick(Sender: TObject);
begin
  // Terminate Plugin
  frmMain.Button2Click(Sender);
  Sleep(200);

  // Plugin initialized
  frmMain.Button1Click(Sender);
  Sleep(200);

  // Play
  frmMain.Button6Click(Sender);
end;

Ohne die Sleeps rennt das teil weiter das nächste Plugin wird initialisiert bevor das vorherige Plugin beendet wurde
das kann es irgendwo nicht sein.

Bei bedarf sende ich nochmal den Source.

gruß

[ManuMF]

Delay revisited ist meine Empfehlung, weiß aber nicht, ob das speziell auch bei Threads so gut funktioniert.

[Michael Habbe]

Hi.

Wenn Du ein Sleep in der Hauptanwendung aufrufst, bleibt dann nicht die ganze Anwendung incl. Threads für diese Zeit stehen?
Schon mal daran gedacht, eine Variable zu benutzen, die vom Thread geändert wird, wenn dieser sich terminiert? Und dann vielleicht in dieser Form prüfen:

Delphi-Quellcode:

while ThreadNotTerminated do Application.ProcessMessages

Wo werden denn die Bitmaps gezeichnet? Auf dem Formular? Dann musst Du es mal mit "Repaint" versuchen, um das Formular neu zu zeichnen.


mfg

[EWeiss]

Zitat:

Zitat von ManuMF

Delay revisited ist meine Empfehlung, weiß aber nicht, ob das speziell auch bei Threads so gut funktioniert.

Würde aber doch im grunde das gleiche sein..
Müßte dann an den stellen wo Sleep steht die Delay Funktion aufrufen.

Eigentlich sollte doch bei einen klickevent dieses erst abgearbeitet werden
bevor die neue ausgeführt wird.

Warum hat Delphi(Ich) da solche Probleme mit.

gruß

[EWeiss]

Zitat:

Zitat von Michael Habbe

Hi.

Wenn Du ein Sleep in der Hauptanwendung aufrufst, bleibt dann nicht die ganze Anwendung incl. Threads für diese Zeit stehen?
Schon mal daran gedacht, eine Variable zu benutzen, die vom Thread geändert wird, wenn dieser sich terminiert? Und dann vielleicht in dieser Form prüfen:

Delphi-Quellcode:

while ThreadNotTerminated do Application.ProcessMessages

Wo werden denn die Bitmaps gezeichnet? Auf dem Formular? Dann musst Du es mal mit "Repaint" versuchen, um das Formular neu zu zeichnen.


mfg

In einem neuen Formular welche aus frmMain aufgerufen wird.

Sieht so aus das wenn andere Anwendungen laufen es vorkommen kann das die Bitmaps nicht mehr zeichnen
abhängig von der CPU auslastung.
Kann aber doch nicht mit Sleep experimentieren das sieht ja dann bei schnelleren Prozessoren wieder
anders aus.

Hänge mal den Quelltext an.

gruß

[Luckie]

Lass deinen Thread doch ein Ereignis auslösen, wenn er fertig ist. Oder wenn du nicht mit dem VCL Thread-Objekt arbeitest, lass dir eine Nachricht schicken, auf die du reagierst.

[EWeiss]

Zitat:

Zitat von Luckie

Lass deinen Thread doch ein Ereignis auslösen, wenn er fertig ist. Oder wenn du nicht mit dem VCL Thread-Objekt arbeitest, lass dir eine Nachricht schicken, auf die du reagierst.

habe ich schon versucht ;)
Leider ohne erfolg :wall:

irgendwas stimmt da nicht kann trotz debugen den Fehler nicht erkennen
das es mal geht und dann wieder nicht.
Kommt auch keine Fehlermeldung.

gruß

[Sunlight7]

Hallo Emil!

Kann das sein, das Dich Delphi mit dem Handlegewechsle nervt?
Nach Deiner Beschreibung sind mir die Symptome bekannt, das die Bitmaps in Threads "verschwinden" weil sich die Handles ändern.

Ich nehme in Thrads immer die API funktionen um mir ein Bitmaps zu erstellt und damit herum zu spielen, da nervt mich Delphi dann net.

Muß net Dein Problem sein, wollt nur drauf hinweisen.

Grüßle!

[EWeiss]

Zitat:

Zitat von Sunlight7

Hallo Emil!

Kann das sein, das Dich Delphi mit dem Handlegewechsle nervt?
Nach Deiner Beschreibung sind mir die Symptome bekannt, das die Bitmaps in Threads "verschwinden" weil sich die Handles ändern.

Ich nehme in Thrads immer die API funktionen um mir ein Bitmaps zu erstellt und damit herum zu spielen, da nervt mich Delphi dann net.

Muß net Dein Problem sein, wollt nur drauf hinweisen.

Grüßle!

Dürfte eigentlich nicht anders sein wie bei deinen Spiel was du geschrieben hast.
Ich benutzt die API BitBlt um teilbereiche aus einem Bitmap in ein Image zu kopieren.

Das funktioniert ja auch alles wenn das Projekt Gen Delphi alleine ausgeführt wird.
Aber in verbindung mit BassVis und den start aus einer anderen Form heraus macht es probleme.
Da ist die Frage liegt es nun an den Threads an der reihenfolge wie die Form gestartet wird
oder an was sonst.

gruß

[sirius]

Ich hätte jetzt mal spontan auf waitforsingleobject getippt

[EWeiss]

PUSH .. Sorry ja ich weiss

Was mich an der ganzen sache doch sehr verwundert.
Das fast gleiche Projekt in Visual Basik/Delphi geschrieben
Visual Basik macht keine thread probleme ist um ein vielfaches schneller was den aufbau der Bitmap
Container Form für die Winamp Visualisierung angeht.
In Delphi kann ich sehen wie träge sich die Form beim aufbau verhält.

Eigentlich sollte das umgekehrt sein da die DLL und das Projekt in Delphi geschrieben sind.

[EWeiss]

Zitat:

Zitat von sirius

Ich hätte jetzt mal spontan auf waitforsingleobject getippt

Werde das mal testen und an stelle von Sleep verwenden...

gruß

[alzaimar]

Hi

Ich vermute, Du hast einen 'Denkfehler': Du kannst doch nicht irgendwie eine konstante Zeit warten, bis jemand anderes mit seiner Arbeit fertig ist. Ich meine, natürlich kannst Du das, aber das ist eben nicht richtig.
Ebensowenig, wie in der Hauptanwendung 'sleep' aufzurufen.

Na gut, im Prinzip benötigst Du so etwas:

Code:

...
  Task1;
  Wait Until Task1 is finished;
  Task2;
  Wait Until Task1 is finished;
...

Verstehe ich das richtig? Und die Tasks sind einzelne Threads, richtig?

Du könntest eine Kette einrichten, sodaß Task1 über sein 'OnTerminate'-Ereignis Task2 anstößt, der wieder Task3 usw.

Dann musst Du nur Task1 starten und die Welt ist 'vordergründig' in Ordnung, denn alle Tasks laufen ja im Hintergrund (wenn die Tasks als Threads deklariert sind).

Ansonsten gäbe es noch die Möglichkeit, die Synchronisation der Tasks/Threads mit Events zu steuern. Das empfiehlt sich dann, wenn die Threads zwischendurch mal eine Teillösung fertig gestellt haben, und einem anderen Thread mitteilen sollen, das der jetzt weitermachen kann.

[negaH]

Ich schließe mich Alzaimar an.

DU machst einen Denkfehler, bzw. gleich mehrere

1.) du meinst das Delphi an einer Sache Schuld ist die es nicht verzapft hat, Windows ist Ereignisorientiert wie auch Linux und da kann man nicht einfach mal so eine Zwangspause per Sleep() einlegen. Bzw. man kann es es ist aber absolut kontraproduktiv. Man nimmt dann einen Timer -> Ereignisorientiert
Du beschwerst dich also über eine Funktionsweise die absolutes Grundlagenwissen ist heutzutage.

2.) Wenn du denoch eine Zwangspause einlegen möchtest und mit "Delay revisited" die Anwendung nicht einfrieren lässt, was du ja auch haben möchtest, dann sind alle Ereignisbasierten Methoden, also auch .OnClick() NICHT mehr reentrant. Sie können also "verschachtelt" aufgerfuen werden wärend sie mit Delay() noch warten. Auch dies ist eine Folge eines Ereignisorientierten Systemes und ganz normal. DU hast dich also darum zu kümmern das der Aufruf von Delay() wieder reentrant wird, wenn du das schon benutzen möchtest. Dazu legst du eine Variable in deinem Form an, einen Zähler den du inkrementiert vor Delay() und dekrementierst nach Delay(). Solange dieser Zähler gleich Null ist darfst du Delay() aufrufen ansonsten kehrt deine OnClick() Methode ohne Aktionen sofort zurück. Noch besser ist es aber den Button der das OnClick() aufruft zu disablen, vergiß auch nicht das OnClose() des Form zu berücksichtgen.

Ergo: möchte man warten und das dabei die Anwendung nicht einfriert so muß man asynchron zum Normalablauf des Programmes Application.ProcessMessages aufrufen. Wenn man dies tut so muß man damit leben das alle Botschaftsorientierten Methoden auch nicht mehr Reentrant sind, das betrift auch die Freigabe der Formulare (hier sind bei falscher Anwendung Exceptions zu erwarten).

Das Grundproblem beginnt aber schon damit das der Programmierer in einem Ereignisorientiertem System innerhalb einer Eregnismethode eine Zwangspause einlegen möchte. Diese Sichtweise ist falsch.

Gruß Hagen

[EWeiss]

@Sirius

Zitat:

Werde das mal testen und an stelle von Sleep verwenden...

Ja so läuft es besser zumindest geht der aufbau der Form schneller von statten.

@alzaimar
Task/Thread das ist die Frage und ob ich warten muss oder nicht.
Theoretisch brauchte ich das nicht.

Delphi-Quellcode:

procedure TfrmMain.optGenClick(Sender: TObject);
begin
  // Terminate Plugin
  frmMain.Button2Click(Sender);
  // Wait befor new Plugin run.
  Delay(200);

  frmMain.Button1Click(Sender);
  // Wait new Plugin initialized
  Delay(200);
  // Play
  frmMain.Button6Click(Sender);
end;

Wenn ich das Button2Click event auslöse kann und muss ich davon ausgehen das dieses erst abgearbeitet wird bevor
das Button1Click event ausgelöst wird.
Allerdings arbeitet das Plugin BassVis immer noch im Hintergrund und ist mit der terminierung des Winamp Plugin beschäftigt.
Deshalb das Delay hinter Button2Click.

Das bedeutet!
Ist der Thread in BassVis nicht beendet und ich führe eine neue Funktion aus dann kommt es zu problemen
Aber ob das nun mit dem zeichnen der Bitmaps etwas zu tun hat das ist die Frage.
Dürfte es eigentlich nicht.

Der Fehler ist wieder aufgetreten in dem Moment wo ich den RenderTimer für die Winamp Plugins erhöht habe.
Sehr seltsam das ganze.
In VB habe ich die Probleme alle nicht. (Soll jetzt kein vergleich mit Delphi sein) sondern lediglich
ein Hinweis das es dort geht und in Delphi nicht.

Habe das project ja gestern hochgeladen.. hat aber nur 1 geladen.
Nur wie will jemand helfen wenn er sich nicht mal das Project läd und es sich anschaut. :cry:

So sieht es nun aus.
Wenn Timing probleme auftreten.

gruß

[EWeiss]

@Hagen

Zitat:

du meinst das Delphi an einer Sache Schuld ist die es nicht verzapft hat

Nein! Ganz deutlich nochmal falls da etwas verkehrt herübergekommen ist.

Mir geht es nicht darum wer das problem verursacht
sondern darum warum es auftritt.
Deshalb hatte ich ja auch den Source gestern hochgeladen damit es sich jemand anschauen kann.

Es geht auch jetzt nicht um Delphi/Vb sondern darum das es auf der einen Seite geht und auf der anderen nicht.
Obwohl die gleiche DLL das gleiche Plugin und die gleichen Routinen(in etwa) verwendet werden.

Das begreife ich nicht.

gruß

[alzaimar]

Zitat:

Zitat von EWeiss

Habe das project ja gestern hochgeladen.. hat aber nur 1 geladen.
Nur wie will jemand helfen wenn er sich nicht mal das Project läd und es sich anschaut. :cry:

Ich bin blind. Wo denn?

[EWeiss]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von EWeiss

Habe das project ja gestern hochgeladen.. hat aber nur 1 geladen.
Nur wie will jemand helfen wenn er sich nicht mal das Project läd und es sich anschaut. :cry:

Ich bin blind. Wo denn?

Hat sich erledigt habe den Fehler gefunden was die Bitmaps angeht.

gruß

[Michael Habbe]

Zitat:

Zitat von EWeiss

Hat sich erledigt habe den Fehler gefunden was die Bitmaps angeht.

gruß

Und? Was wars???

[EWeiss]

Zitat:

Zitat von Michael Habbe

Zitat:

Zitat von EWeiss

Hat sich erledigt habe den Fehler gefunden was die Bitmaps angeht.

gruß

Und? Was wars???

Der unterschied zwischen VB und Delphi ist das VB bei der initialisierung der Form automatisch in die
FormResize event springt bei Delphi ist das nicht so.
Deshalb fehlten mir die coordinaten der Bitmaps die dann nicht auf die richtige position gesetzt wurden.
Habe es nun umstruckturiert so das Delphi dazu gezwungen wird in diese procedure zu springen.

Seltsamerweise funktionierte es ja ab und zu.
Frag mich jetzt nicht warum .. KA

Hier ist der Source und ein Pic
Für verbesserungs vorschläge bin ich immer zu haben. :mrgreen:

gruß