Verständnisfrage Thread...

[calibra301]

Danke,

werde ich umbauen sobald meine Regierung mir etwas Freizeit einräumt :-)

Gruss
Calli

[calibra301]

Wird aber wohl erst morgen was...

So dankbar ich auch für eine Lösung bin, es wäre aber trotzdem
schön wenn mir jemand erklären könnte WARUM das nun plötzlich nicht mehr geht.
Nur des Verständnisses wegen..

Auch ist mir der Unterschied zwischen Start und Execute nicht klar. Viel findet man nur in
Englisch und mit mitte 60 ist das nicht so meins...
Hatte das so verstanden das mit Thread.create das Ding erstellt und und ich dann nur irgendwie meine
Schleife starten muss die im erzeugtem Thread läuft.

Gruss
Calli

[jaenicke]

Zitat:

Zitat von calibra301 (Beitrag 1393739)

Auch ist mir der Unterschied zwischen Start und Execute nicht klar. Viel findet man nur in
Englisch und mit mitte 60 ist das nicht so meins...
Hatte das so verstanden das mit Thread.create das Ding erstellt und und ich dann nur irgendwie meine
Schleife starten muss die im erzeugtem Thread läuft.

Ja, fehlende Englischkenntnisse sind nicht gerade förderlich. ;-)

Der Punkt ist, dass Execute intern quasi aus dem Thread heraus aufgerufen werden muss, damit die Befehle darin auch im Thread laufen. Wenn man selbst Execute aufruft, tut man das ja aus dem Hauptthread heraus und damit bleibt man auch im Hauptthread.

Du kannst ja mal einen Haltepunkt in das Execute setzen und einfach mal den Stacktrace anschauen. Vielleicht wird es dann klarer.

[calibra301]

Hallo,

kurze Rückmeldung von der Front :-)

Konnte es nicht sein lassen und hab selber probiert.
Vielleicht hilfts ja jemand anderem. Ich hasse Threads wo die Lösung gefunden aber
nicht dokumentiert wird..sogar für Dummy´s wie mich :-)

Der ganze OpenGL Kram im Mainthread.

Der ganze Datenkram die die einzelnen Threads sammeln kommmt in public Arrays des jeweiligem Threads.

Wenn alle Geräte abgearbeitet sind kommt ein

Synchronize(form1.updategui);

updategui holt sich dann in einer Schleife die Daten aus den Einzelthreads und
zeichnet. Gehen tuts...ob es so die "feine Englische Art" ist weiss ich nicht...

Leider hab ich noch eine Baustelle mit der ich euch gern belästigen würde.
Hab die Frage auch schon öfter gefunden , leider nur mit Antworten wie "guck da...sieht man doch..."

Es geht um die dynamische Erzeugung eines TIDUDPServers.

Delphi-Quellcode:

 try
  FSocket := TIdUDPServer.Create(nil);
  FSocket.ThreadedEvent := True;
  FSocket.DefaultPort := Artnet_Port;
  FSocket.ThreadedEvent:=true;
  FSocket.ReuseSocket:=rstrue;
//  FSocket.OnUDPRead := ReadUDP;
  FSocket.BroadcastEnabled := True;
  FSocket.Active := True;
  except

  end

Was ich nicht hinbekomme ist die eigene Deklaration der ReadUDP Prozedur sowie des
Aufrufes FSocket.OnUDPRead:= ???

Im Grunde macht es vielleicht Sinn das auch in einen eigenen Thread auszulagern
und auch mit Sycronize zu arbeiten.

Danke und Gruss
Calli

[TiGü]

Bitte erstelle für eine neue Frage, die offensichtlich nichts mit der ursprünglichen zu tun hat, ein neues Forumsthema.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1393746)

Wenn man selbst Execute aufruft

Darum ist Execute auch eigentlich PROTECTED, denn so kann man es garnicht erst von außen aufrufen.
OK strict protected wäre besser, und es wäre unklug, wenn man beim Ableiten/Überschreiben die Sichtbarkeit dieser Methode verändert. (vergisst das Protected anzugeben und es z.B. nach Public verschiebt)

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1394004)

vergisst das Protected anzugeben und es z.B. nach Public verschiebt)

So wie in diesem Fall. Beim Überschreiben macht es natürlich Sinn darauf zu achten welche Sichtbarkeit die Methoden vorher hatten. Aber wenn man nicht weiß wie es funktioniert, macht man das vielleicht ja auch absichtlich, weil man es für die richtige Vorgehensweise hält.

[Delphi-Laie]

Zitat:

Zitat von calibra301 (Beitrag 1393715)

Delphi-Quellcode:

RunActive=true

Es stirbt einfach nicht aus, es ist zum Mäusemelken: Laß das überflüssige "=true" weg!