Brauche Hilfe bei Delphi Bug in nested Forms / Childforms

[Assertor]

Hallo,

ich habe etliche Probleme, sobald ein Form in einem Panel eines anderen Forms liegt. Es kommt teilweise zu verzögerten oder nicht ausgeführten Repaints und etlichen OnChange Events obwohl Daten nicht geändert wurden.

Ich habe die Probleme isoliert und kann Sie definitiv auf das "Andocken" im MainForm zurückführen.

Threads zu den Problemen:
Repaint Problem
RichEdit Problem

Ich brauche keine Hilfe zu den Controls. Das Problem taucht auch auf, wenn ich statt "nested Forms" die Möglichkeit der DockSite und DragMode von Delphi verwende.

Die Controls/Componenten funktionieren im Undocked Mode der DockSite auch einwandfrei. Sobald diese gedockt sind, gehen die Probleme los.

Weiß hier einer eine Lösung, kennt einen QC Eintrag oder eine andere Art nesten Forms zu nutzen (mit Frames bin ich nicht so vertraut, meine aber diese sind für Mehrfachvererbungen: Ich habe aber nur 3 verschiedene Forms die gedockt werden sollen und sich total unterscheiden).

Vielen Dank für Eure Hilfe im Voraus!
Gruß winkel79

[jbg]

Hast du es schon mal mit einer überschriebenen CreateParams Methode probiert:

Delphi-Quellcode:

type
  TMyChildForm = class(TForm)
  protected
    procedure CreateParams(var Params: TCreateParams); override;
  end;

procedure TMyChildForm.CreateParams(var Params: TCreateParams);
begin
  inherited CreateParams(Params);
  Params.Style := Params.Style or WS_CHILD;
end;

[Assertor]

Hallo jbg,

gleicher Fehler. Geht wirklich in Richtung VCL-Bug scheint mir.

Hier jetzt mal ein Demoprojekt, welches den einen Fehler zeigt und erklärt (benötigt nur Delphi, Exe auch dabei für die Eiligen).

Gruß winkel79

[Edit: Tipp nun ausprobiert]
[Edit: Das Problem tritt auch ohne PageControl auf. Also auf Form2 nur das TRichEdit]
[Edit: Das Problem tritt auch bei manuell erzeugten Forms, ohne Application.CreateForm in der .dpr auf;
ebenso bei Forms mit CreateParented(hwnd);]

[Assertor]

Hallo,

es sieht so aus, als ob dieser Fehler mit dem RichEdit sich nicht beheben läßt.

Mit einem TMemo klappt es fehlerfrei, jedoch fehlen dem TMemo die Scrollbars ssBoth mit Autohide...

[marabu]

Hallo,

nimm mal die Vorbelegung deines RichEdit weg, die wird beim Laden des Controls aus der DFM-Resource übernommen und triggert das Ereignis OnChange().

Freundliche Grüße

[Assertor]

Hi Marabu,

Zitat von marabu:

nimm mal die Vorbelegung deines RichEdit weg, die wird beim Laden des Controls aus der DFM-Resource übernommen und triggert das Ereignis OnChange().

Stimmt. Aber ganz so einfach ist es nicht:

Wenn ich die Vorbelegung entferne und das RichEdit 1x im nested Form angezeigt wird stimmt alles. Wir das Form nun nochmal als "eigenständiges Form" angezeigt, wird wieder der OnChange getriggert...

[marabu]

Hallo,

durch den Wechsel des Parent wird das RichEdit neu erzeugt und dabei wird unbedingt ein OnChange() gefeuert. Das ist so gewollt. Als work-around kann ich dir folgendes anbieten:

Delphi-Quellcode:

procedure TForm2.RichEdit1Change(Sender: TObject);
begin
  if not (fsCreating in FormState) then
    ShowMessage('OnChange');
end;

Freundliche Grüße

[Assertor]

Hallo,

Zitat von marabu:

durch den Wechsel des Parent wird das RichEdit neu erzeugt und dabei wird unbedingt ein OnChange() gefeuert. Das ist so gewollt.

Warum ist das so gewollt? Ich kann ich mir das nicht wirklich vorstellen. Gegenbeispiel: TEdit, TMemo, TMaskEdit - da wird überall kein OnChange getriggert beim Parent-Change.

Der Workaround geht bei mir leider nicht, gerade ausprobiert (siehe neues Demobeispiel).

Gibt ja einige Probleme mit RichEdit, welche QC-Einträge haben: z.B. (Auszug)
RichEdit DoubleBuffered geht nicht
RichEdit lädt Defaults aus DFM, wenn BorderStyle geändert wird (und verliert neuen Text)
RichEdit zeigt Text im Frame nicht richtig an

Gibt es einen Ersatz mit einem Memo, welches automatisch verschwindende Scrollbars hat (nur dafür brauch ich die RichEdits)?

Aber imho ist das Verhalten des OnChange beim RichEdit nicht konform mit den anderer VCL Controls...

Gruß winkel79

Edit: Der Erklärungstest auf dem Demo ist noch der alte Text. Nicht irritieren lassen

[marabu]

Hallo,

beim Tracing habe ich festgestellt, dass ein Statement, welches ich irrtümlich für den Auslöser des Events (deshalb meine Unterstellung es sei so gewollt) gehalten hatte, lediglich eine EventMask gesetzt hat. Der Auslöser für das ungewollte Triggern von OnChange() ist aber nach meinem jetzigen Kenntnisstand kein Mangel des Rich Edit Common Controls, sonder ein Lapsus der VCL-Entwickler. Diese erzeugen in der Prozedur TCustomRichEdit.DestroyWnd() eine Objektvariable FMemStream, die sie nach der Verwendung nicht freigeben. Fatalerweise wird aber in CreateWnd() diese Variable geprüft und wenn das Objekt existiert, dann führt das am Ende zur Auslösung des Ereignisses OnChange().

Bei meinem Test trat dieses Verhalten zum Schluss nicht mehr auf, da ich aus bestimmten Gründen mit einer eigenen Form und nicht mit deiner Form2 getestet habe und aus Dusseligkeit auf Button1 meine und auf Button2 deine Form2 gelegt hatte. Sorry.

Freundliche Grüße

[Assertor]

Hallo marabu,

Danke für Deine intensive Mithilfe (auch schon im anderen Thread)!

Ich werde Dein ChildForm Beispiel nachher mal ausprobieren. Muß ich irgendwas beachten dabei? Oder kann ich dieses dann als Basis für meine eingehängten Forms verwenden? Aufruf und Erzeugungskonventionen egal? - will sagen können die Unter-Forms weiterhin per Application.CreateForm in der dpr mit Visible=false erzeugt werden?

Ich prüfe gerade auch die Möglichkeit das ganze in Frames zu machen, wobei hier ja der OnCreate fehlt. Da könnte ich aber ja den Klassen-Create überschreiben...

Wobei welchen Sinn haben Frames, wenn man jedes nur 1x erstellt und nutzt - also nicht noch in anderen Forms oder Anwendungen braucht?!? Ich dachte die wären besser dafür gedacht.

Gruß und Danke
winkel79