readcomponent(ResFile) "heckt" Subkomponenten

[DrUArn]

Hi, comm.,

habe ein Problem beim Schreiben/Lesen neuer Komponenten

Delphi-Quellcode:

 TTestpanel = class(Tpanel)
  private
    FcheckA: TCheckBox;
    Fted: TEdit;
    { private declarations }
  protected
    { protected declarations }
  public
    { public declarations }

  published
    { published declarations }
    property checkA: TCheckBox read FcheckA write Fchecka;
    property ted: TEdit read Fted write Fted;
    constructor create(AOWNER:tcomponent);override;
  end;

constructor TTestpanel.create(AOWNER: tcomponent);
begin
  inherited;
  FcheckA:=tcheckbox.Create(self);
  FcheckA.Caption:='A';
//  FcheckA.name:='checkA';
  InsertControl(FcheckA);
  fchecka.SetSubComponent(true);
  fted:=TEdit.Create(Self);
  Fted.parent:=self;
//  fted.name:='ted';
  Fted.Top:=25;
  Fted.SetSubComponent(true);
  AutoSize:=true;
end;


//....
RegisterClasses([TTestpanel]);

im Formular z.B. mit Buttons:

schreiben:

Delphi-Quellcode:

writeComponentResFile('d:\testpanel.tmp',testpanel1);
//oder auch:fstream.WriteComponent(testpanel1); (fstream:tfilestream)
FreeAndNil(testpanel1);

lesen:

Delphi-Quellcode:

testpanel1:=ttestpanel.create(self);
ReadComponentResFile('d:\testpanel.tmp',testpanel1);
//oder auch:fstream.readComponent(testpanel1); 
//oder ohne testpanel1:=ttestpanel.create(self): testpanel1:=
// ReadComponentResFile('d:\testpanel.tmp',NIL);
//bzw. tespanel1:= fstream.readComponent(NIL); 


InsertControl(Testpanel1);

Die Probleme:

1. gebe ich den Subkomponenten in ttestpanel.create einen namen,
kommt beim Lesen die Fehlermeldung: "Komponente mit der Bezeichnung 'Name' existiert bereits!"

2. bei namenlosen Subkomponenten erhöht sich die Anzahl der im Panel vorhanden Subkomponenten um 1 - d.h. nach dem ersten schreiben/lesen gibt es zwei tedit's und 2 tcheckboxes usw..


Das liegt daran, daß beim Lesen ttestpanel.create aufgerufen wird - damit auch die beiden Subkompontenten erzeugt werden und dann noch einmal eingelesen werden - haben Sie Namen, geht's schief, haben sie keinen Namen, 'vermehren' sie sich!

Wo liegt der Fehler - eigentlich will ich meine neue Komponente nur speichern und wieder einlesen?!

Die verschiedenen Varianten des Einlesens haben das gleiche, unerwünschte Ergebnis.

Bin gespannt!

MfG Uwe

[DrUArn]

Hi,
tschuldigung, eine Berichtigumg noch,
beim Lesen muß es richtig heißen:

Delphi-Quellcode:

testpanel1:=readComponentResFile('d:\testpanel.tmp',nil) as TTestpanel;
//bzw.
testpanel1:=fstream.readComponent(nil) as TTestpanel;

man könnte zwar nach Create die subkomponenten löschen

Delphi-Quellcode:

testpanel1.create(self);
Testpanel1.ted.Free;
Testpanel1.checkA.free;
readComponentResFile('d:\testpanel.tmp',TTestpanel);

Dann sieht ddie Komponente aus, wie erwartet incl. der Eigenschaften der Subkomponenten.
Aber dies ist wohl nicht der Sinn vom Speichern und Lesen von Komponenten!


MfG Uwe

[einbeliebigername]

Hallo,


wenn man deine TTestPanel in einen Stream schreibt und diesen in Text umwandelt bekommt man dies:

Code:

object TTestPanel
  Left = 0
  Top = 0
  Width = 123
  Height = 51
  AutoSize = True
  TabOrder = 0
  checkA.Left = 1
  checkA.Top = 1
  checkA.Width = 97
  checkA.Height = 17
  checkA.Caption = 'A'
  checkA.TabOrder = 0
  ted.Left = 1
  ted.Top = 26
  ted.Width = 121
  ted.Height = 24
  ted.TabOrder = 1
  object TCheckBox
    Left = 1
    Top = 1
    Width = 97
    Height = 17
    Caption = 'A'
    TabOrder = 0
  end
  object TEdit
    Left = 1
    Top = 26
    Width = 121
    Height = 24
    TabOrder = 1
  end
end

Wie man sieht sind CheckBox und Edit zweimal enthalten. Einmal als SubComponent, wie gewünscht, und einmal als Children, wo das Problem liegt. Ich habe ein Testprogramm angehangen, welches dies zeigt.

Das Problem mit den Childrens liegt in der Kombination Owner der SubComponents, Root beim Speichern in den Stream und dem TWinControl.GetChildren . Der Root beim Speichern ist dein TestPanel, genauso wie der Owner der SubComponents. Und TWinControl.GetChildren gibt alle Kinder wieder, wo der Owner derselbe wie der Root ist.
Um das zu lösen entweder den Owner von den SubComponents auf NIL setzen oder die Methode GetChildren überschreiben. Die meiner Meinung nach beste Variante des Überschreibens habe ich im angehängten Testprogramm umgesetzt. Das {$DEFINE WithFilter} in Zeile 24 ein kommentieren.

einbeliebigername.

[DrUArn]

Hi,

@ einbeliebigernameanke für umfängliche Antwort. Das muß ich mir gaaanz langsam durchlesen. Klingt kompliziert.

Owner der Subkomponenten auf nil setzen?

z.b. testpanel.ted.owner:=nil ist verboten - nur-Lesen-Eigenschaft!


habe die {$IFDEF WithFilter} Methoden auf meine Komponente (ohne zu verstehen) angewendet - funktioniert.

Muß man eigentlich die Subkompenenten alle ausschließen?

So geht's in meinem Beispiel auch:

Delphi-Quellcode:

procedure TTestPanel.FilterGetChildren(Child: TComponent);
begin
//  if (Child<> Fted) and (Child<> FcheckA) then
//    fFilterGetChildrenProc(child);
end;

Allerdings werden auch mit dem Original-Code die Eigenschaften fcheckA.Checked bzw. ted.text NICHT mitgespeichert!
(In einer anderen Komponente mit noch verzwickteren Childabhängigkeiten geht's dann aber wieder - da muß ich eben gaaanz lange drüber nachdenken)


MfG Uwe

[DrUArn]

Hi,

muß wohl doch ein Fehler im Package gewesen sein - auch das speichern von checked bzw. text geht nun.

Damit wäre das wohl eine Lösung, die man in jede neue Komponente mit einbauen muß, wenn man wincontrols als properties benutzt.

Gruß Uwe

[einbeliebigername]

Hallo,

Zitat von DrUArn:

z.b. testpanel.ted.owner:=nil ist verboten - nur-Lesen-Eigenschaft!

Ne, ich meinte er so tcheckbox.Create(nil); statt so tcheckbox.Create(self); .

Zitat von DrUArn:

habe die {$IFDEF WithFilter} Methoden auf meine Komponente (ohne zu verstehen) angewendet - funktioniert.

Naja, GetChildren wird vom Streamingsystem aufgerufen und soll für jedes Kind der Komponente die im Parameter Proc angegebene Methode Aufrufen. Diese Methode speichert dann das Kind innerhalb der Komponente. Beim laden werden diese Kinder mittels Create wieder erzeugt.

Zitat von DrUArn:

Muß man eigentlich die Subkompenenten alle ausschließen?

Eigentlich nein, es reicht nur die SubComponents auszuschließen wo der Owner derselbe ist wie die Root-Komponente beim speichern. Aber es ist nicht schädlich einfach alle SubComponents auszuschließen.

Zitat von DrUArn:

So geht's in meinem Beispiel auch:

Delphi-Quellcode:

procedure TTestPanel.FilterGetChildren(Child: TComponent);
begin
//  if (Child<> Fted) and (Child<> FcheckA) then
//    fFilterGetChildrenProc(child);
end;

Ja, aber dadurch werden jetzt gar keine Kinder mehr gespeichert. Wenn man dein Panel im Designer auf ein Formular setzen würde und dann noch zusätzlich per Designer ein Button in diese Panel setzt, würde beim Speicher dieser Button nicht gespeichert werden. Er wäre dann einfach beim Laden weg. Die leer TTestPanel.FilterGetChildren wäre dasselbe wie:

Delphi-Quellcode:

procedure TTestPanel.GetChildren(Proc: TGetChildProc; Root: TComponent);
begin
end;

Aber meinen Code kann man ja noch vereinfachen bzw. verallgemeinern.

Delphi-Quellcode:

procedure TTestPanel.FilterGetChildren(Child: TComponent);
begin
  if not csSubComponent in Child.ComponentStyle then
    fFilterGetChildrenProc(child);
end;

Damit würde man alle SubComponents ausschließen. Diesen Code könnte man bedenkenlos in jeder Komponente Platzieren, da ja SubComponents niemals als Kind, sonder über ein published Property gespeichert werden.

Und wenn man sich das ganze nochmal durch den Kopf gehen lässt, wäre damit eigentlich die Implementierung von GetChildren in TWinControl fehlerhaft.

einbeliebigername.

[DrUArn]

Hi,

schnell ein Test - nicht viel Zeit!
Ich habe erstmal die Procedure wiederhergestellt:

Delphi-Quellcode:

procedure TTestpanel_UA.FilterGetChildren(Child: TComponent);
begin
  if (Child<> Fted) and (Child<> FcheckA) then
    fFilterGetChildrenProc(child);
end;

und im Formulardesigner eine weitere Tcheckbox im tpanel plaziert:
Diese wird nicht (!) gespeichert.

Vieleicht wegen ...as ttestpanel_UA?

Gruß Uwe

[einbeliebigername]

Hallo,

Zitat von DrUArn:

und im Formulardesigner eine weitere Tcheckbox im tpanel plaziert:
Diese wird nicht (!) gespeichert.

Wo wird die weitere CheckBox nicht gespeichert? Im Formular an sich (Formular Speichern, Schließen und wieder Öffnen -> weitere CheckBox weg) oder beim Speichern und Laden des Panels zur Laufzeit?

Beim ersteren sollte mit entweder

Delphi-Quellcode:

procedure TTestPanel.FilterGetChildren(Child: TComponent);
begin
  if (Child<> Fted) and (Child<> FcheckA) then
  fFilterGetChildrenProc(child);
end;

oder

Delphi-Quellcode:

procedure TTestPanel.FilterGetChildren(Child: TComponent);
begin
  if not csSubComponent in Child.ComponentStyle then
    fFilterGetChildrenProc(child);
end;

die weitere CheckBox im Formular gespeichert werden und mit

Delphi-Quellcode:

procedure TTestPanel.FilterGetChildren(Child: TComponent);
begin
// if (Child<> Fted) and (Child<> FcheckA) then
// fFilterGetChildrenProc(child);
end;

oder

Delphi-Quellcode:

procedure TTestPanel.GetChildren(Proc: TGetChildProc; Root: TComponent);
begin
end;

die weitere CheckBox nicht im Formular gespeichert werden.

Beim zweitem wird die weitere CheckBox nie gespeichert, da der Owner dieser das Formular ist und der Root beim Speichern das Panel ist.

einbeliebigername.

[DrUArn]

Hallo,

@einbeliebigerName: alles so, wie oben beschrieben, hatte nicht geschnallt, daß es in dem einen Fall um's Speichern in's Formular ging.

Interessant ist, daß wenn man in der IDE-Umgebung

Delphi-Quellcode:

procedure TTestpanel_UA.FilterGetChildren(Child: TComponent);
begin
end;

wieder auskommentiert, auf dem Formular die zusätzliche Checkbox erhalten bleibt, zur Laufzeit ist sie dann weg - und erst recht, wenn das Formular gespeichert wurde.

Problem gelöst - danke an einbeliebigerName!


Nebenher - beim Programmieren von Objekten taucht einem ja ständig nach der einen die nächste Frage vor den Füßen auf:

Delphi-Quellcode:

{...}
  published
    { published declarations }
    property checkA: TCheckBox read FcheckA write Fchecka;
    property ted: TEdit read Fted write Fted;
    constructor create(AOWNER:tcomponent);override;


 {!}   procedure oncheckboxclick(Sender: TObject);virtual;


constructor TTestpanel_UA.create(AOWNER: tcomponent);
begin
  {...}
  FcheckA.OnClick:=oncheckboxclick;
  AutoSize:=true;
end;


procedure TTestpanel_UA.oncheckboxclick(Sender: TObject);
  var oldss,oldsell:integer;
begin
  try    //geht hier bei der Initialisierung noch schief, da noch kein Fenster da ist
  with Fted do begin
  oldss:=SelStart;oldsell:=sellength;
  setfocus;
  selstart:=oldss;  SelLength:=oldsell;
  end;
  except
  end;
 end;

Also als Reaktion auf Checkboxclick wieder zu Ted zurückkehren und alte Verhältnisse wieder herstellen.

Ist fcheckA.checked=TRUE und speichert man zur Laufzeit testpanel ab und lädt es dann wieder, so geht das
ohne try except schief mit der Meldung: "Fehler beim Lesen von testpanel_ua1.checka.checked: Element Testpanel_ua1 hat kein übergeordnetes Fenster."

Wie kann man ermitteln, wann das übergeordnete Fenster da ist, um soche Ausnahmen zu verhindern?


Ich würde den eigentlich Thread eigentlich als beantwortet markieren wollen - dank der Arbeit von einbeliebigerName, finde aber 'grad nicht, wo das passieren kann ...

Gruß Uwe

[einbeliebigername]

Hallo,

mach mal bitte dazu ein neues Thema auf. Das wird hier nicht gern gesehen, denn es ist ein neues Problem und hat mit den SubComponents nichts zu tun. Im Moment habe ich da auch noch keine Idee.

einbeliebigername.