Zitat von
Sidorion:
Ist Ein Component obendrein noch ein CONTROL, so trägt es sich aus der Controls-Liste seines PARENTS aus und schreibt in die Parent-Eigenschaft aller seiner Controls ein Nil.
Soweit richtig, das passiert in
Remove (Instance).
Zitat:
Da wird nix vernichtet.
Nun wird's meiner Meinung nach falsch. Der Befehl zur Vernichtung (
Instance.Destroy) folgt direkt auf den zum Austragen, siehe Beitrag #27.
Hier ein kleiner Codeauszug zum Testen:
Delphi-Quellcode:
interface
type
TForm1 = class(TForm)
Panel1: TPanel;
Edit1: TEdit;
btnKillPanel: TButton;
btnKillEdit: TButton;
procedure btnKillEditClick(Sender: TObject);
procedure btnKillPanelClick(Sender: TObject);
procedure FormCreate(Sender: TObject);
private
EditReference : TEdit;
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.btnKillPanelClick(Sender: TObject);
begin
Panel1.Free;
end;
procedure TForm1.btnKillEditClick(Sender: TObject);
begin
EditReference.Free;
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
EditReference := Edit1;
end;
Wir haben ein Panel, auf diesem Panel liegt ein Edit-Control (Edit1.Owner = Form1, Edit1.Parent = Panel1). Mit
btnKillPanel wird nun das Panel zerstört. Kurz vor seinem Tod zerstört es das auf ihm liegende Edit-Control. Dies geschieht im Destruktor von TWinControl, wie du leicht durch Einbindung der Debug-DCUs nachvollziehen kannst. Die private Referenz
EditReference ist nun ungültig, ein anschließender Druck auf
btnKillEdit führt zur
Access Violation.
Diese kleine Simulation zeigt
eine Möglichkeit auf, wie der Fehler im Programm von
hugo1990 entstehen kann.
EditReference entspricht dem dynamischen Array,
btnKillEditClick steht für die manuelle Freigabe. Nun wäre nur noch das Gegenstück zu
btnKillPanelClick in seinem Code aufzuspüren. Aber scheinbar ist Hugos Problem ja keines mehr...
Gruß Hawkeye