Einzelnen Beitrag anzeigen

Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.063 Beiträge
 
Delphi 12 Athens
 
#3

AW: Leere VCL-Komponente zur freien Benutzung

  Alt 5. Aug 2011, 23:46
Delphi-Quellcode:
begin
  inherited;
end;
Leere Methoden sind eher unschön und stellen nur einen unnötigen Overhead dar.
Aber OK, da dieses als Vorlage für eine Erweiterung dient, könnte man es nochmal durchgehn lassen, da hier ja geplant ist, diesen Code direkt zu erweitern und nicht durch Vererbung.

if value <> FColor then .
Wieso prüfst du in manchen Settern auf eine Veränderung und in Anderen nicht?

Delphi-Quellcode:
with canvas do
begin
  ...
  canvas.xyz
Wieso wird in dem WITH eigentlich nochmal namentlich darauf zugegriffen?

TVCL_COMPONENT .
Finde ich als Namen etwas unglücklich gewählt:
- einmal die etwas delphi-untypische Schreibweise ... CamelCase ist da verbreiteter
- und dann ist ist dieses ja nicht die einzige VCL-Komponente

Wenn man hier auch noch den OOP-Gedanken etwas mehr durchsetzt (vorallem die Vererbung), dann wäre TBaseVisualComponent ("Basis" für Grundkomponente) doch passender?

Delphi-Quellcode:
canvas.font.Assign(Font);
canvas.brush.style := bsClear;

//besser (da es so auch deklariert wurde)
Canvas.Font.Assign(Font);
Canvas.Brush.Style := bsClear;
Ansonsten kann es nie schaden, wenn man sich beim Schreiben an die Schreibweise der Deklarationen hält bzw. einen einheitlichen Schreibstil nutzt. (vorallem für solche Vorlagen)
OK, wenn man schon alles kleinschreiben will, wieso tanzt dann Assign aus der Reihe?

Eine ordentliche Codeformatierung erübrigt solche Kennzeichnungen ala //________________________ .

// Hier Code einfügen .
Diesen Teil in eine eigene virtuelle protected Pethode ausgelagert und man kann der OOP folgend von der Basiskomponente ableiten und seinen Code durch überschreiben (override) hinzufügen.
Da man eventuell sowieso das Zeichnen noch implementieren "muß", könnte man dieses auch noch als Abstract deklarieren.

Es kann auch nicht schaden, wenn solche eingebetteten Prozeduren, wie drawcaption und drawframe ( Schreibweise? ) ebenfalls als Private oder Protected in die Klassendeklaration auslagert.

Delphi-Quellcode:
  ...
  canvas.pen.style:=psclear;
  drawframe;
end;
DrawComponent > die virtuelle Methode, zum Überschreiben/Einfügen des Zeichencodes
DrawCaption > wird ja eh ganz am Ende von DrawFrame aufgerufen, warum also soein verschachtelter Aufruf, wo es auch direkt geht
Delphi-Quellcode:
  ...
  Pen.Style := psClear;
  DrawFrame;
  DrawComponent;
  DrawCaption;
end;
canvas.font.color := Canvas.Font.Color; .
Sieht zwar unterschiedlich aus, aber eigentlich macht dieser Code nicht wirklich was.
Font.Color := Font.Color; // ohne Canvas, da doch im WITH drin .

In deinem Code entsteht vermutlich nicht gleich eine Exception, aber für den Code der Anderen, welcher hier ja noch eingefügt werden soll, kann man sowas nicht wirklich sicherstellen,
daher würde ich noch einen Resourcenschutzblock empfehlen (vorallem für rgn).
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.

Geändert von himitsu ( 6. Aug 2011 um 00:05 Uhr)
  Mit Zitat antworten Zitat