Procedure Regelmäßig ausfühen

[ts-soft]

Ist eigentlich einfach zu verstehen, das warum Threads für Anfänger nicht empfohlen werden. Anfänger nutzen
Try & Error zur Fehlerfindung, was ja auch nicht verkehrt ist. Bei Threads muß ich aber wissen, wie diese richtig
abgesichert werden, weil Testen kann ich tausend mal ohne das ein Fehler auftritt. Wenn ich die Theorie dazu nicht
verstanden habe und nicht umsetzen kann, wird das nichts mit Threads. Fehler lassen sich in Threads nicht einfach
so Testen, nach dem Motto läuft, dann läufts auch immer.
Ohne Threads gibt es wesentlich seltener unvorhersehbare Situationen, die nicht immer auftreten. Da fällt mir nur
die Division by Zero ein, die evtl. beim Testen nicht zum tragen kommt, weil nicht mit 0 getestet wird.

Threads sind kein absolutes MUSS und Anfänger können getrost drauf verzichten.

[stab]

Hallo,

ich bin hier auf dieses Thema gestoßen, als ich nach "AddWindowTimer" gesucht habe.

Die Diskussion verstehe ich nicht ganz.
Ich bin Gelegenheitsprogrammierer, zwar schon lange, aber würde mich vom Niveau her noch als Anfänger bezeichnen.
Nach Jahren überarbeite ich jetzt ein Projekt und stelle einige zeitintensive Prozeduren auf Threads um.
Macht auch richtig Spaß zu sehen, wie die jetzt im Hintergrund laufen. Ich denke, das PureBasic Beispiel, den Thread example file Thread.pb, kann man auch als Anfänger verstehen.

Schwierig wurde es für mich, meine vorhanden Prozeduren, die ich mit etlichen Parametern aufgerufen habe, als Thread laufen zu lassen. Um die Parameter zu übergeben, musste ich dann mit Zeigern auf Strukturen arbeiten. Fragen dazu würde ich aber immer wieder im Anfängerbereich stellen, in der Hoffnung, von den Profis ein kurzes Beispiel für Dummies zu erhalten und nicht gleich seitenweise Code, so gut das auch gemeint ist.

Zurück aber zu meinen Fragen:

1. Bei BindEvent(#PB_Event_Timer, @hallo()) kann ich scheinbar keine Parameter übergeben. Stimmt das?

2. Wenn ich folgende Anwendung habe:

Code: Alles auswählen

Procedure hallo()
  Debug "Hallo"
EndProcedure

OpenWindow(0,0,0,20,20,"Hallo")
AddWindowTimer(0,0,1)
BindEvent(#PB_Event_Timer, @hallo())

Repeat:Until WaitWindowEvent()=#PB_Event_CloseWindow

muss ich beim Start erst den Timeout abwarten, bis das erste "Hallo" erscheint.
Spricht etwas gegen das einfache überschreiben des vorhandenen Timers wie etwa so?

Code: Alles auswählen

Procedure hallo()
  Debug "Hallo"
  AddWindowTimer(0,0,5000)
EndProcedure

OpenWindow(0,0,0,20,20,"Hallo")
AddWindowTimer(0,0,1)
BindEvent(#PB_Event_Timer, @hallo())

Repeat:Until WaitWindowEvent()=#PB_Event_CloseWindow

Gruß stab

[Kiffi]

2. Wenn ich folgende Anwendung habe:

Code: Alles auswählen

Procedure hallo()
  Debug "Hallo"
EndProcedure

OpenWindow(0,0,0,20,20,"Hallo")
AddWindowTimer(0,0,1)
BindEvent(#PB_Event_Timer, @hallo())

Repeat:Until WaitWindowEvent()=#PB_Event_CloseWindow

muss ich beim Start erst den Timeout abwarten, bis das erste "Hallo" erscheint.

wie wäre es hiermit?

Code: Alles auswählen

[...]
BindEvent(#PB_Event_Timer, @hallo())
hallo() ; <-- einmaliger 'manueller' Aufruf
[...]

[stab]

Ja, ich könnte aber auch das ganze etwas flexibler gestalten wollen

Code: Alles auswählen

Global t = 5000
Global w

Procedure hallo()
  Debug "Hallo"
  AddWindowTimer(0,0,t)
  w +1
  If w = 2: t = 1000: EndIf
  
EndProcedure

OpenWindow(0,0,0,20,20,"Hallo")
AddWindowTimer(0,0,1)
BindEvent(#PB_Event_Timer, @hallo())

Repeat:Until WaitWindowEvent()=#PB_Event_CloseWindow

Ich frage nur, weil das nicht dokumentiert ist und ich nicht will, dass sich nach Stunden mein Programm aufhängt.