Designer Integration

[theo]

Kennt sich jemand aus mit dem Anpassen von Komponenten für den Designer?

Stichworte: Componentstate (csLoading, csDesigning...), Loaded etc.

Ich habe sowas noch nie wirklich gemacht. Stelle nur fest, dass sich das nicht so verhält wie wenn man die Kompo im Code createt.
Genauer gesagt, statt meiner "gefüllten" Komponente, sehe ich nur ein graues Rechteck. Kackt nicht ab, aber zeigt auch nichts..
Die Kompo ist etwas aufwändig und benutzt CreateParams, CreateWnd, Resize etc um das ganze ins Rollen zu bringen.
Kann es sein, dass sich diese Dinge im Designer anders verhalten?
Ausserdem wird "Loaded" nicht aufgerufen. Müsste das nicht nach dem Streaming kommen?

Wenn jemand dazu etwas sagen kann, wäre ich froh.

EDIT: Akutes Problem ist gelöst. Musste in CreateWnd etwas mehr Initialisierungscode schreiben.
Dieser wird wenn die Komponente im Code erzeugt wird wahrscheinlich durch Resize oder sowas abgearbeitet, im Designer aber nicht.
Trotzdem würde es mich interessieren, wenn jemand etwas zu dem Thema sagen könnte.

[theo]

Ich sehe schon, das ist ein überaus mühsames Geschäft.

Beispiel Komponentenname setzen, so dass er beim ändern in der IDE auch gleich im Control angezeigt wird:

Code: Alles auswählen

procedure TCustomWoprControl.SetName(const Value: TComponentName);
var
  TextToName: boolean;
begin
  TextToName := (ComponentState * [csDesigning, csLoading] = [csDesigning])
    and (TrimRight(Text) = Name);
  inherited SetName(Value);
  if TextToName then
    begin
    fDoc.Clear(false,false);
    fDoc.AddParagraph.AddText(Value,FM.RequestFont);
    if fWindowCreated then UpdateAfterLoad;
    end;
end;

Das braucht's alles nur für den IDE Designer (bisschen bei Synedit abgekuckt).
Und immer muss man die IDE neu bauen um den Effekt zu sehen. Seufz....

[mse]

Das braucht's alles nur für den IDE Designer (bisschen bei Synedit abgekuckt).
Und immer muss man die IDE neu bauen um den Effekt zu sehen. Seufz....

In einem anderen Projekt mache ich das jeweils so, dass ich eine erste IDE starte, das IDE-Projekt öffne und die neue Komponente als vorerst (fast) leere Hülse mit den nötigsten published properties programmiere. F9 startet eine zweite IDE mit der eingebauten neuen Komponente.
In der zweiten IDE (die im Debugger der ersten IDE läuft) erstelle ich ein Testprojekt mit der neuen Komponente. In der zweiten IDE entwickle ich dann die Komponente anhand des Testprojektes weiter, dabei wird dan beim Start des Testprokjektes ein zweiter Debugger gestartet, der innerhalb des Ersten läuft.
Wird eine weitere published property benötigt, schliesse ich die zweite IDE, mache die Änderung in der ersten IDE, F9, mit der aktualisierten zweiten IDE weiterarbeiten.
Alfällige design time probleme der neuen Komponente mit property- und component-editors lassen sich im Debugger der ersten IDE untersuchen. Möglicherweise lässt sich dieses Konzept auch mit Lazarus durchführen.
Beim anderen System sind übrigens bei Komponenten normalerweise keine besonderen design-time Massnahmen notwendig, das streaming läuft ganz normal ab. Ich vermute, dies ist bei Lazarus genauso.

Martin

[theo]

@Martin: Danke für den Beitrag.
Du kannst übrigens schon MSEIDE sagen, wenn du MSEIDE meinst.

Mein Problem liegt aber nicht so sehr im Debugging, sondern eher beim Anpassen der Komponente für den Designer.
Da treten viele Sachen zum Vorschein, die als einfache Klasse kein Problem sind, bzw an die ich nicht gedacht hatte.
Mal abgesehen von gewissen Verhaltensunterschieden, z.B. das man kein Caret im Designer haben will etc. ,
gibt es auch im Bereich der Aktualisierung Sachen, die so bisher kein Problem waren.

Beispiel: Ich habe eine solche Hierarachie: Control.Document.PageSettings.PageWidth
Bisher war PageWidth ein Property ohne Getter/Setter.
Der Wert wurde einfach von einer nachfolgenden Aktualisierung angewandt. (z.B. schliesse den PageDialog und Refresh mal alles).
Wenn ich nun PageWidth im OI ändere, passiert nat. gar nix sichtbares.
Also muss ich für alle published Properties in PageSettings Setter einrichten, welche Events auslösen, damit erstmal das Document und dann das Control Wind davon bekommen und updaten können.
Wahrscheinlich brauche ich auch noch Begin- Endupdate, damit wenn man viele Eigenschaften im Code in einem Rutsch updaten will nicht jedesmal das ganze Tamtam ausgelöst wird.

Das ist alles kein Problem, nur viel Arbeit an die ich bisher nicht gedacht, bzw. die ich verdrängt hatte.

[mse]

Wahrscheinlich brauche ich auch noch Begin- Endupdate, damit wenn man viele Eigenschaften im Code in einem Rutsch updaten will nicht jedesmal das ganze Tamtam ausgelöst wird.

Für Layoutberechnungen und dergleichen verwende ich meistens eine andere Vorgehensweise. Die setter Proceduren und andere Vorgänge, welche das Layout beeinflussen, löschen ein "Layout gültig Flag" in einem Status set der Komponente. Die Berechnung des Layout wird erst durchgeführt, wenn das Layout benötigt wird und nur dann, wenn das gültig Flag nicht gesetzt ist. Nach erfolgter Layoutberechnung wird das Flag gesetzt. Dadurch ersparst du den Anwendern deiner Komponenten sich um das korrekte beginupdate/endupdate mit endsprechendem try-finally block kümmern zu müssen.

[theo]

Die Berechnung des Layout wird erst durchgeführt, wenn das Layout benötigt wird und nur dann, wenn das gültig Flag nicht gesetzt ist.

Die Frage ist nur, wann das ist. Bei der Änderung im OI muss direkt upgedatet werden, ich kann also nicht auf irgend ein Ereignis "hoffen".
Ich weiss schon wie du da meinst, aber ich glaube nicht, dass das in mein "Modell" sehr gut reinpasst.

[mse]

Die Frage ist nur, wann das ist. Bei der Änderung im OI muss direkt upgedatet werden, ich kann also nicht auf irgend ein Ereignis "hoffen".

Falls eine Änderung an einer Property etwas sichtbares verändert, muss im setter zusätzlich invalidate oder invalidaterect aufgerufen werden. Die Neuberechnung aller notwendigen Teile geschieht dann in der paint procedure.