THyperLinkLabel - Verständnisfrage

[scrat1979]

Hallo Zusammen,

da ich mich im Moment etwas mit der Komponentenentwicklung beschäftige, habe ich o.g. Komponente erstellt. Als Vorlage habe ich im Internet verfügbare Komponenten ähnlicher Art genommenm um ggf. meine Fehler (besser) erkennen zu können. Dabei sind mir einige Dinge aufgefallten ,welche ich fürs Verständnis von jemandem Erfahreren erklärt bekommen möchte. Wäre nett,wenn der ein oder andere ein paar Zeilen schreiben würde! So viel vorab: Die Komponente funktioniert problemlos und basiert auf TLabel.

1.) Obwohl ich die vererbten Eigenschaften (z.B. Wordwrap) nicht explizit in der published-Rubrik übernommen habe (wie es
die meisten anderen autoren machen), erscheinen sie und funktionieren. Was für ein Vorteil haben die anderen Autoren
dadurch (ausser mehr Arbeit )?

2.) Es gibt bei TLabel das Event OnMouseEnter. Warum lässt sich die eigene aufgerufene Prozedur (z.B. OnMouseEnter) nicht mit
override erweitern. Statt dessen muss man die Messages CM_MOUSEENTER etc. erneut abfangen. Bei OnEnter der TEdit-Komponenten
funktionert das ja auch (habe ich schon bei meiner 1. Komponente gemacht -> nur zahlen können eingegeben werden)

3.) Was ist denn der Unterschied zwsichen TLabel und TCustomLabel bzw. allgemein zwischen den "Custom"-Komponenten und den
"normalen" Komponenten. Eignet sich die eine Gruppe mehr zum "Ableiten" einer neuen Komponente?

Vielen Dank im voraus,

SCRaT

[Muetze1]

Zitat von scrat1979:

1.) Obwohl ich die vererbten Eigenschaften (z.B. Wordwrap) nicht explizit in der published-Rubrik übernommen habe (wie es die meisten anderen autoren machen), erscheinen sie und funktionieren. Was für ein Vorteil haben die anderen Autoren dadurch (ausser mehr Arbeit )?

Dann waren die Eigenschaften in der Basisklasse schon published. Sprich: du hast von TLabel und nicht TCustomLabel abgeleitet (wie die anderen). Mehr dazu in 3.

Zitat von scrat1979:

2.) Es gibt bei TLabel das Event OnMouseEnter. Warum lässt sich die eigene aufgerufene Prozedur (z.B. OnMouseEnter) nicht mit override erweitern. Statt dessen muss man die Messages CM_MOUSEENTER etc. erneut abfangen. Bei OnEnter der TEdit-Komponenten funktionert das ja auch (habe ich schon bei meiner 1. Komponente gemacht -> nur zahlen können eingegeben werden)

Ich versteh nicht so ganz wie du das versucht hast, bzw. gemacht hast. Könntest du den Teil der Kompo mit diesem Event bzw der Methode oder aber wie du es machen wolltest, mal kurz posten?

Zitat von scrat1979:

3.) Was ist denn der Unterschied zwsichen TLabel und TCustomLabel bzw. allgemein zwischen den Custom"-Komponenten und den "normalen" Komponenten. Eignet sich die eine Gruppe mehr zum "Ableiten" einer neuen Komponente?

TCustomXXX dient als Basis für Ableitungen. In diesen Komponenten ist das komplette Verhalten etc implementiert, aber sie veröffentlichen nicht ihre Eigenschaften und Events. Daher ist es demjenigen überlassen welcher ableitet, ob und welche Eigenschaften und Events seine Komponente haben kann/soll. Bei einer Ableitung von TLabel ist es schwierig (bzw. kein sauberer Weg) die schon von TLabel veröffentlichten Eigenschaften und Events wieder zu verstecken. Daher haben die anderen Autoren auch immer nochmals im Published Bereich die Properties veröffentlicht (Property WordBreak.

[scrat1979]

Vielen Dank schon einmal, nach einem kurzen Test ist mir der Unterschied von 3.) klar geworden (und damit auch von 1.). Was ich noch nicht ganz verstehe ist der 2. Punkt:

Hier mal ein kurzer Ausschnitt aus dem Code - GEHT!!! :

Delphi-Quellcode:

  private
    procedure CMMouseEnter(var Message: TMessage); message CM_MOUSEENTER;
    procedure CMMouseLeave(var Message: TMessage); message CM_MOUSELEAVE;
  protected
    { Protected-Deklarationen }
    procedure Click; override;

Dazu folgende Frage: In TLabel sind z.B. die Events OnMouseEnter sowie OnClick da. So weit so gut. Nun kann man die Prozedur, welche beim Ereignis OnClick ausgeführt wird überschreiben (procedure Click; override). Hoffe das ist so weit korrekt. Nun die Frage: Warum lässt sich nicht das selbe für die o.g. Ereignisse CMMouseEnter durchführen, indem man die beiden Zeilen herausnimmt und eine analoge Procedure einfügt (procedure MouseEnter; override? . Also so:

Delphi-Quellcode:

  private
    // fällt weg
  protected
    { Protected-Deklarationen }
    procedure Click; override;
    procedure MouseEnter; override;
    procedure MouseLeave; override;

Damit hatte ich leider keinen Erfolg. Worin liegt der Unterschied? Onclick und OnMouseEnter sind doch beides Events, den EventHandler (z.B. OnClick) kann man (ich?) aber nur bei OnClick (-> procedure Click) überschreiben.

SCRaT

[Hansa]

Muetze hat ja das meiste schon gesagt. Aber noch was zu dem hier (geht im Prinzip um Deinen Punkt 3. mit dem Custom):

Zitat von scrat1979:

Was für ein Vorteil haben die anderen Autoren dadurch (ausser mehr Arbeit )?

Du musst Dir mal überlegen, was es heißt, von TLabel abzuleiten oder von TCustomLabel. Erstere haben deutlich weniger Arbeit. Muss ein Bespiel konstruieren : irgendeiner braucht 1000 Labels und zwar grüne. Der erste, der das machen soll, der geht hin und legt 1000 Labels auf die Forms und geht 1000 mal in den OI und klappt das + bei Font auf, sucht sich grün raus usw. Alle Arbeitsschritte 1000 mal. Der nächste hat schon was von TComponent gehört und baut sich ein komplett neues Label. Der erfindet das Rad erst mal komplett neu. Dauert zwar ewig, aber theoretisch wäre es machbar. Gespart hätte er das setzen der grünen Farbe.

Jetzt kommen noch zwei andere, die wissen, dass die VCL hierarchich aufgebaut ist. Sie suchen nach irgendeinem schon vorhandenen Label als Vorfahr. Der eine findet das TCustomLabel. Der ist zwar schon wesentlich besser dran als der mit dem TComponent, aber er muss einen Haufen an Prozeduren mit Leben erfüllen. Er wird auch viel Arbeit haben. Es wird vermutlich abstrakte Fehler erhalten und ganz seltsame Effekte. Jetzt noch der mit dem TLabel, der schon längst fertig ist. Er schreibt 2 relevante Zeilen :

TMyLabel = class (TLabel); Somit erzeugt er quasi zuerst einmal einen TLabel-Clone. Alles, was das TLabel hat, das hat "sein" Label ab sofort auch. Die Farbe fehlt aber noch und die baut er im Constructor ein :

Delphi-Quellcode:

Constructor TMyLabel.Create... ; override
begin
  inherited;  // Vorgänger-Constructor vorsichtshalber aufrufen wegen override
  Font.Color := clGreen;
end;

Gut, die Farbe ist schon sehr einfach. Das Prinzip bleibt aber gleich und gilt so auch für zu überschreibende Methoden.

Zitat von scrat1979:

Warum lässt sich nicht das selbe für die o.g. Ereignisse CMMouseEnter durchführen, indem man die beiden Zeilen herausnimmt und eine analoge Procedure einfügt (procedure MouseEnter; override? .

Damit man genau so etwas eben NICHT machen kann.

[scrat1979]

@Hansa

Vielen Dank. Das war ein gutes Beispiel, aber mir bleiben noch 2 Fragen offen.

1.) Du schreibst in Deinem letzten Satz:

Zitat:

Damit man genau das NICHT machen kann

Was genau meinst Du damit?

2.) Muetze1 schreibt:

Zitat:

Bei einer Ableitung von TLabel ist es schwierig (bzw. kein sauberer Weg) die schon von TLabel veröffentlichten Eigenschaften und Events wieder zu verstecken. Daher haben die anderen Autoren auch immer nochmals im Published Bereich die Properties veröffentlicht (Property WordBreak.

Was genau meint er denn dann mit "sauberer Weg" und mit Events "zu verstecken". Wenn ich von TLabel ableite, sind doch eben diese Events günstigerweise schon integriert (und nicht versteckt, jedenfalls nicht im OI) und ich habe weniger Schreibarbeit, kann die Events aber dennoch mit "override" erweitern. Wenn ich es richtig deute, dann geht er doch davon aus, dass TCustomLabel besser zum ableiten sei, du hingegen meinst TLabel (gerade weil weniger Schreibarbeit), oder habe ich da was missverstanden?

SCRaT

[Hansa]

Zitat von scrat1979:

@Hansa

Vielen Dank. Das war ein gutes Beispiel, aber mir bleiben noch 2 Fragen offen.

Zitat:

Damit man genau das NICHT machen kann

Was genau meinst Du damit?

2.) Muetze1 schreibt:

Was genau meint er denn dann mit "sauberer Weg" und mit Events "zu verstecken". Wenn ich von TLabel ableite, sind doch eben diese Events günstigerweise schon integriert (und nicht versteckt, jedenfalls nicht im OI) und ich habe weniger Schreibarbeit, kann die Events aber dennoch mit "override" erweitern. Wenn ich es richtig deute, dann geht er doch davon aus, dass TCustomLabel besser zum ableiten sei, du hingegen meinst TLabel (gerade weil weniger Schreibarbeit), oder habe ich da was missverstanden?

SCRaT

Wenn etwas als private deklariert wurde, dann stellst Du dir doch auch keine WebCam ins Badezimmer. Umgekehrt rum wird Gottschalk wohl auch kaum bei Wetten Dass mit der Axt alle Kabel zum Ü-Wagen abhacken. Dein Vorhaben ist in etwa so, dass für Wetten Dass eine Webcam zur Fernsehübertragung eingesetzt wird und die WebCam im Badezimmer zur Not gleich mitsamt Badewanne gesprengt wird. 8) Ich weiß, ist schon krass. Aber es hat Gründe, warum man das so eben NICHT macht.

Zu Mützes Beitrag und dem, warum ich überhaupt was geschrieben habe :

Lasse doch bei OOP erst mal die Finger von der Sichtbarkeit. Siehe die Delphi Warnungen für die, die es doch so machen. Benutze das, was da ist. Die Custom-Dinger sind für Komponentenentwickler gedacht, die besser wirklich alles selber neu machen wollen weil sie sowieso 70 % umbauen wollen und nicht dafür, alles komplett selber machen zu müssen.

Das "override" ist immer in Zusammenhang mit "inherited" zu sehen ! Man kann zwar mit override was bekanntes überschreiben, aber im Normalfall nicht einfach so. Insbesondere nicht, ohne vorher die Vorgängermethode per inherited aufzurufen. Guck dir "inherited" mal dringend an, wozu das gut ist !

Weiß auch nicht, was Mütze da meint und es ist schon etwas irritierend. Noch zum Problem an sich. Würde das so machen : Label bleibt Label, also wie bei meinem Farbbeispiel abgeleitet von TLabel. Folgendes würde ich machen (nur skiziert) : Links werden eben wie gewohnt blau gemacht und nicht grün und zwar beim Create. Oder mache sie karriert. Damit der User eine Reaktion merkt, würde ich eventuell dann das MouseOver (?) verwenden um umzufärben. Hmmm, das wars ja schon. Der Rest wäre im OnClick abzuhandeln. Bei vielen Links am besten dann auch gleich in Komponente einbauen.

[scrat1979]

Zitat:

Das "override" ist immer in Zusammenhang mit "inherited" zu sehen ! Man kann zwar mit override was bekanntes überschreiben, aber im Normalfall nicht einfach so. Insbesondere nicht, ohne vorher die Vorgängermethode per inherited aufzurufen. Guck dir "inherited" mal dringend an, wozu das gut ist !

Das ist mir so weit klar

Zitat:

Weiß auch nicht, was Mütze da meint und es ist schon etwas irritierend. Noch zum Problem an sich. Würde das so machen : Label bleibt Label, also wie bei meinem Farbbeispiel abgeleitet von TLabel. Folgendes würde ich machen (nur skiziert) : Links werden eben wie gewohnt blau gemacht und nicht grün und zwar beim Create. Oder mache sie karriert. Zwinkern Damit der User eine Reaktion merkt, würde ich eventuell dann das MouseOver (?) verwenden um umzufärben. Hmmm, das wars ja schon. Der Rest wäre im OnClick abzuhandeln. Bei vielen Links am besten dann auch gleich in Komponente einbauen.

Danke für den Tip. Hatte es GENAU SO (!) implementiert

Im Prinzip ist mir das alles einigermaßen klar. Ich würde nur gerne nachvollziehen können, warum man bei TLabel von den beiden Events OnClick und OnMouseEnter eben nur OnClick mit "override" erweitern kann. Für onclick nimmt man die Prozedur "procedure onclick". Das funktioniert wunderbar (mit inherited etc. ...). Aber mit der analogen Funktion von OnMouseEnter "procedure mouseenter" klappt das nicht. Kann es sein, dass der Name der Prozedur nur nicht korrekt ist und es sonst klappen würde?

Vielen Dank schonmal für Eure Tips!! War echt hilfreich.

SCRaT

[Christian Seehase]

Moin Scrat,

Du kannst Click überschreiben, weil es in einer der Vorfahren (TControl) existiert, was bei den anderen Methoden nicht der Fall ist.
Bei einem TLabel kannst Du im normalen Programm Click auch nicht aufrufen, da es als protected deklariert ist, so dass Du Dir selber einen Nachfahren erstellen musst, bei dem Du dann die Sichtbarkeit der Methode erhöhst (public), wenn man sie dann im Programm benutzen können soll.

Mal eine kurze Zusammenfassung der Sichtbarkeiten:

private:
Ist nur innerhalb der Klasse selber, und einer abgeleiteten Klasse, wenn sie denn innerhalb der gleichen Unit deklariert wird.

protected:
Ist, zusätzlich zu private, auch dann in einer abgeleiteten Klasse sichtbar, wenn sie in einer anderen Unit deklariert wird.

public
Auf public-Elemente kann überall zugegriffen werden.

published
Macht Eigenschaften im ObjectInspector sichtbar.
Dies ist borland-spezifisch.

[scrat1979]

Ahhhhhh!! Jetzt ist es mir glaube ich klar. Danke für die ausführliche Infos!!!

SCRaT

[Hansa]

hier steht doch alles :

Delphi-Quellcode:

  private
    procedure CMMouseEnter(var Message: TMessage); message CM_MOUSEENTER;
  protected
    procedure Click; dynamic;

Wo das CMMouseenter letzenendes rauskommt weiß nur die VCL. Wie Christian sagt, das Click ist protected. Es kann also vererbt werden. Ohne jetzt im Delphi-Source groß weiterzuwühlen : ich vermute, daß im Stile von FindComponent daraus die gewohnten Sachen wie "Label1Click" als Bezeichner zusammengesetzt und bereit gestellt werden. Mehr will ich gar nicht wissen.