Danke für Eure Antworten!
Das Problem ist jetzt so gelöst:
Delphi-Quellcode:
procedure TForm1.ThreadEnde(ID: Integer);
Var
I: Integer;
begin
I:=0;
while (I < fObjectList.Count) do
begin
if (TMyObject(fObjectList[I]).ID = ID) then break;
Inc(I);
end;
if (I < fObjectList.Count) then // Wäre so, wenn ID nicht gefunden würde.
begin
TMyObject(fObjectList[I]).PNGStream.SaveToFile('bild.png');
TMyObject(fObjectList[I]).JPGStream.SaveToFile('bild.jpg');
Memo1.Lines.Append('... all done - object ID is ' + IntToStr(ID));
end
else Memo1.Lines.Append('ERROR: ID ' + IntToStr(ID) + ' not found!');
Button1.Enabled:=true;
end;
Hintergrund der IDs hatte ich versucht zu erklären. Es kommen so ca. 50 Seiten/min. vom Scanner. Das soll in etwa auch so bleiben. Ich habe daher (neben dem Haupt-Thread der
VCL) einen Thread gebaut, der in
tpIdle
rumdümpelt und nichts anderes tut, als eine Liste mit den Bildcontainern zu verwalten. Er sorgt auch für einen geordneten Ablauf der Kompression, Kontrastanpassung etc. pp.
Die Benutzer können aber - weil Thread - die Bilder schon während des Scannens aussortieren (=löschen). Das bringt dann den Index der Liste durcheinander und da habe ich mir eben über die ID geholfen. Dass es im ursprünglichen Code beim 3. Mal "knallt", war dem Umstand geschuldet, dass ich das
TMemoryStream.Save();
als Fehlerquelle ausgemacht hatte und grundsätzlich erstmal sehen wollte, ob die Procedure überhaupt bis zum Ende durchläuft...
Stichwort
threadsichere Komponenten. Was versteht man darunter und wie finde ich es raus. Ich dachte, mit CriticalSections zu arbeiten, würde bzgl. Threads schon ausreichend sein. Da der HauptThread die Kommandos für das Packen verwaltet und den Container entsprechend mit einem TAG versieht, sollte also alles im Lot sein.