Deine _ThreadFunc ist eine lokale Funktion und keine TThreadFunc wie von BeginThread erwartet. Die Notwendigkeit des @-Operators um den Compiler zu besänftigen sollten schon ein Warnsignal gewesen sein, daß das vielleicht nicht ganz richtig sein könnte.

markieren

Delphi-Quellcode:

type
  TThreadFunc = function(Parameter: Pointer): Integer;

...
function BeginThread(SecurityAttributes: Pointer; StackSize: LongWord;
  ThreadFunc: TThreadFunc; Parameter: Pointer; CreationFlags: LongWord;
  var ThreadId: TThreadID): THandle;

Du musst also eine globale Funktion mit dieser Signatur übergeben. In dem Parameter könntest du den Pointer auf die Objekt-Instanz mitgeben, womit du dann auf DoStarted und DoFailed zugreifen könntest (bei geeigneter Sichtbarkeit). Leider bleibt dir der Zugriff auf die lokale Variable Status aber trotzdem verwehrt. Das ist aber auch gut so, da diese ja nach dem Verlassen von Produce auch nicht mehr existiert (und dann läuft dein Thread vermutlich noch).

Ich verstehe aber wirklich nicht, warum du den definitiv schwierigsten Weg wählst, um dich mit Threading zu beschäftigen, anstatt eine wenigstens halbwegs brauchbare fertige Kapselung zu verwenden. Das obige Problem ist eine direkte Folge dieser Herangehensweise. Wollte man das auch rein mit Delphi Bordmitteln erledigen, wären Anonyme Methoden und TThread oder TTask die bessere Wahl. Ist mir auch egal, ob du das nun hören willst oder nicht.

Wenn man schon auf die Nase fällt, dann wenigstens mit ordentlich Anlauf

Wie gesagt, das basiert auf einer (für meine Einsteiger-Verhältnisse) relativ komplexen Demo. Diese wurde offensichtlich für C++ gestrickt und dann quasi 1:1 für Delphi angepasst.

Ich habs jetzt auf TThread umgestrickt. Dort habe ich aber ähnliche Probleme. Variablen, die im Interface-Private des TThread-Objektes definiert sind, ändern sich völlig willkürlich. Deklariere ich sie Unit-global im Interface-Teil, dann funktioniert es, obwohl ich KEIN CriticalSection verwende (was ich eigentlich erwartet hätte dass dann umso mehr Probleme auftauchen müssten).

Threadprogrammierung ist schon sehr verwirrend ^^ Ein andermal mehr, morgen ist wieder Arbeit angesagt...

Zitat von uwe raabe:

aus den slides meines vortrags auf den delphi-tagen 2013:

Zitat von danny thorpe:

new programmers are drawn to multithreading like moths to flame,
with similar results.

( ͡° ͜ʖ ͡°)

Zitat von Codehunter:

Wenn man schon auf die Nase fällt, dann wenigstens mit ordentlich Anlauf

Wie gesagt, das basiert auf einer (für meine Einsteiger-Verhältnisse) relativ komplexen Demo. Diese wurde offensichtlich für C++ gestrickt und dann quasi 1:1 für Delphi angepasst.

Ich habs jetzt auf TThread umgestrickt. Dort habe ich aber ähnliche Probleme. Variablen, die im Interface-Private des TThread-Objektes definiert sind, ändern sich völlig willkürlich. Deklariere ich sie Unit-global im Interface-Teil, dann funktioniert es, obwohl ich KEIN CriticalSection verwende (was ich eigentlich erwartet hätte dass dann umso mehr Probleme auftauchen müssten).

Threadprogrammierung ist schon sehr verwirrend ^^ Ein andermal mehr, morgen ist wieder Arbeit angesagt...

Man braucht halt einen anderen mindset als für die klassische RAD-"Programmierung". Wenn Du einigermaßen Fit in Englisch bist lies Dir bei Gelegenheit mal das hier durch: http://sklobovsky.nstemp.com/communi...threadmare.htm