Ich habe mir schon gedacht, dass die TListView direkt kein Assign() implementiert. Die TListItems tun dies aber. Somit bei den beiden Assign() Aufrufen einfach zuvor noch ein Items. einfügen. Im Endeffekt sollte es dann so aussehen:
Delphi-Quellcode:
function TForm2.ShowModal (l: TListView): Integer;
begin
lModal.Items.Assign (l);
result := inherited ShowModal;
if result = mrOk then
l.Items.Assign(lModal);
end;
Aber grundlegend muss ich allen zustimmen, dass eine Arbeit mit einer visuellen Komponenten zur Datenhaltung wirklich schlechter Stil ist. Hier liegt eindeutig keine Trennung von Oberflächen und Daten vor. Im Normalfall sollte dein Programm eine nicht visuelle Liste haben, welche alle Daten entsprechend hält. Die Oberfläche kann dann mit Nutzung der Liste die Oberfläche befüllen (hier: das ListView). Wenn du nun einen zweiten Dialog hast der die Liste bearbeitet, dann sollte diesem nur diese nicht visuelle Liste übergeben werden und dann kann sie dort bearbeitet werden. Danach kann Form1 seine Oberfläche an den veränderten Listinhalt anpassen. Diese Trennung von Oberfläche und Daten ermöglicht mehr Freiheiten beim gestalten der Oberfläche. So kann die Oberfläche die gleichen Daten auch später z.B. in einem VST darstellen, ohne das die Datenverwaltung umgestellt werden muss. Oder wenn der Kunde eine Spalte in der ListView einfach nicht mehr sehen will, dafür aber beim Bearbeiten im Form2-Dialog. So hättest du z.Z. mit deinem Aufbau keine Chance diese Änderung einfach zu machen, da dir dann die Daten der Spalte in Form1 definitv fehlen. Bei der Trennung der Daten ist es nur eine Zeile beim befüllen der ListView für Form1.