OOP-TRealEdit von TEdit abgeleitet und Fähigkeiten erweitert

[Hansa]

Hi,

das hier ist jetzt die fertige Version. Nur die Frage der Zwischenablage ist noch offen. Darüber dürfte man aber einiges finden. Wenn jemand das sowieso weiß, wie solche Fehler abzufangen sind, dann her damit.

Bei 700 Aufrufen hat das Thema anscheinend schon Interesse geweckt, aber die Anzahl der Downloads (1-2) 8) zeigen wohl, daß viele sich nicht einmal mit fertigem Quelltext ernsthaft um OOP kümmern wollen. Vielleicht schreckt die Länge des Threads mittlerweile auch einige ab. Da es noch Probleme mit LabelSpacing, den Zeichenkoordinaten usw. gab, habe ich um nicht noch eine Woche an dem Thema zu hängen kurzerhand entschlossen einige Sachen von dem Borland-TLabelEdit zu übernehmen. Dies bedeutet für nicht D6-Benutzer wahrscheinlich nichts gutes. Z.B. ist nicht mehr abgeleitet von TEdit, sondern von TBoundEdit. Es betrifft um die 3-4 Prozeduren. Falls es sich nicht compilieren läßt empfehle ich die Version davor zu benutzen und den Alignment Fehler zu korrigieren. LabelPosition und LabelSpacing dürften wohl nicht sooo wichtig sein. Bzw. sind sie leicht abzuändern. Vorsichtshalber habe ich die Unit mal anders genannt.

Und noch eine Bitte: Sollte irgendwann jemand auf die Idee kommen, das ganze tatsächlich so in seinen Programmen zu verwenden, dann bitte kurze PN. Würde mich schon mal interessieren.

[Motzi]

So, hab mir jetzt auch mal den Source runtergeladen...

Hab mir das Ding mal angeschaut und ein paar Änderungen vorgenommen. Da ich aber so wie immer an meinem Zivi-Arbeitsplatz sitz und daher wie immer kein Delphi hab sind die Änderungen alle aus dem Kopf und natürlich nicht getestet!

BTW: hab das ganze außerdem ein bisschen an meinen Stil angepasst!

[Motzi]

Während ich den Code überarbeitet hab hat da anscheinend noch jemand was dazwischen gepostet!

@Hansa: schau dir mal meinen Code an und ich schau mir daweil mal deinen neuen an!

[Motzi]

Ein paar kleine Fehler...

Delphi-Quellcode:

procedure TRealEdit.CreateParams(var Params: TCreateParams);
const Alignments: array[TAlignment] of byte=(ES_Left, ES_Right, ES_Center);
begin
  inherited CreateParams(Params);
  Params.Style := Params.Style or Alignments[fAlignment];
end;

Die Zuweisung von Params.Style muss natürlich VOR dem Aufruf von inherited erfolgen, damit der neue Stil im neuen Fenster auch wirklich vorhanden ist!

Delphi-Quellcode:

procedure TRealEdit.SetParent(AParent: TWinControl);
begin
  inherited SetParent(AParent);
  if FRealLabel = nil then exit;
  FRealLabel.Parent := AParent;
  FRealLabel.Visible := True;
end;

Hier sollte man noch die Position des Labels aktualisieren...!

Und außerdem muss man nicht jedesmal, wenn ein property geändert wird RecreateWnd aufrufen! RecreateWnd wir benötigt wenn ein Property geändert wird, dass ein elementarer Bestandteil eines Windows-Steuerelements ist, der zur Laufzeit nicht geändert werden kann wie zB der Fensterstil für die Ausrichtung. Wird die Ausrichtung geändert, dann muss das gesamte Fenster neu erstellt werden (-> neues Handle). Bei normalen Properties wie LabelSpacing, LabelPos, .. kann man sich das sparen.

Außerdem würd ich das Property RealLabel ReadOnly machen! Eine Set-Methode für das Label mit einer einfachen Zuweisung:
fRealLabel :=value; ist eine potenzielle Fehlerquelle!

[[TP]Hawk274]

Zitat:

Außerdem würd ich das Property RealLabel ReadOnly machen! Eine Set-Methode für das Label mit einer einfachen Zuweisung:

Code:

fRealLabel :=value;

ist eine potenzielle Fehlerquelle!

Kannst du das bitte mal näher erläutern? Mit einem Beispiel würde ich das in diesem Fall besser verstehen. Danke ...

[Motzi]

Zitat von [TP:

Hawk274]

Zitat:

Außerdem würd ich das Property RealLabel ReadOnly machen! Eine Set-Methode für das Label mit einer einfachen Zuweisung:

Code:

fRealLabel :=value;

ist eine potenzielle Fehlerquelle!

Kannst du das bitte mal näher erläutern? Mit einem Beispiel würde ich das in diesem Fall besser verstehen. Danke ...

Objekte sind in Delphi nur Pointer die implizit dereferenziert werden (klingt komplizierter als es ist). Durch die Anweisung fRealLabel := Value wird also nicht das Objekt sondern einfach nur eine Referenz kopiert. Einerseits verliert man damit die Referenz auf das Original-Objekt, das fRealLabel ursprünglich referenziert hat, und hat damit keine Möglichkeit mehr darauf zuzugreifen und es freizugeben (-> Speicherleck), und andrerseits erhält man eine Referenz auf ein Objekt, auf das höchstwahrscheinlich auch noch eine andere Referenz existiert. Wird dieses Objekt nun freigegeben und die TRealLabeledEdit-Komponente versucht auf "sein" Label zuzugreifen, dann wird damit ein EAccessViolent ausgelöst da das Objekt ja nicht mehr existiert.

[oki]

Hi Leute,

ich hab nur ein bischen was gemacht und eure Änderungen noch nicht eingearbeitet. Aber das Thema Abstand Label - RealEdit ist bei mir mit drin. Gleichzeitig habe ich ein Property für die Ausrichtung des Labels zum RealEdit eingefügt. Vielleicht ist das interessant.

Man sollte aber noch mal prüfen, ob man das Label nicht mit seinen Property in den OI bekommt. Es gibt ja doch einige Eigenschaften die nützlich sind.

Gruß Oki

[Motzi]

Zitat von oki:

Hi Leute,

ich hab nur ein bischen was gemacht und eure Änderungen noch nicht eingearbeitet. Aber das Thema Abstand Label - RealEdit ist bei mir mit drin. Gleichzeitig habe ich ein Property für die Ausrichtung des Labels zum RealEdit eingefügt. Vielleicht ist das interessant.

Man sollte aber noch mal prüfen, ob man das Label nicht mit seinen Property in den OI bekommt. Es gibt ja doch einige Eigenschaften die nützlich sind.

Gruß Oki

Das mit dem Label im OI werd ich mir mal anschaun.. vielleicht geht das sogar (schlimmstenfalls braucht man halt ein Wrapper-Objekt).

Ansonsten würd ich sagen, das Hansa du und ich uns mal auf einen Source einigen und uns "synchronisieren", damit nicht jeder immer nur an seinem eigenen Code arbeitet.

[oki]

Hi Motzi,

das mit dem "syncronisieren" ist eine tolle Idee, auch dass du das übernehmen willst (ich hätte dafür auf Anhieb keine Idee).

Zum Thema Wrapper-Object bin ich gespannt. Auf dem Gebiet bin ich richtig blaß.

Schau Dir mal meinen Code an. Ich hab die Thematik "Pos setzen" in eine eigene Methode ausgelagert. Ich halte das für sinnvoll. Hier ist doch die Möglichkeit recht übersichtlich auf alle Eigenschaften zur Positionierung des Labels zu reagieren und in den notwendigerweise überschriebenen Methoden des TEdit wird es übersichtlicher.

Gruß oki

[Motzi]

Zitat von oki:

Hi Motzi,

das mit dem "syncronisieren" ist eine tolle Idee, auch dass du das übernehmen willst (ich hätte dafür auf Anhieb keine Idee).

Mal schaun wie wir das am blödesten äh.. besten machn.

Zitat:

Schau Dir mal meinen Code an. Ich hab die Thematik "Pos setzen" in eine eigene Methode ausgelagert. Ich halte das für sinnvoll. Hier ist doch die Möglichkeit recht übersichtlich auf alle Eigenschaften zur Positionierung des Labels zu reagieren und in den notwendigerweise überschriebenen Methoden des TEdit wird es übersichtlicher.

Ja, find ich auch sinnvoll!

Zitat:

Zum Thema Wrapper-Object bin ich gespannt. Auf dem Gebiet bin ich richtig blaß.

Jo.. ich hab mich mal gestern drangemacht. Folgendes Prinzip: es gibt ja die Möglichkeit im OI "Unteroptionen" (die mit diesem "+" dahinter) einzutragen. Siehe zB TFont - wenn man da auf das "+" klickt klappen die "unteroptionen" auf. Vorsicht, nicht verwechseln mit den Enumerations-Typen! Die haben zwar auch ein "+" allerdings enthält die aufklappbare Liste nur Boolean-Werte die angeben ob ein bestimmtes Element in der Menge enthalten ist oder nicht.
Solche "Unteroptionen" implementiert man indem man eine neue Klasse von TPersistent ableitet und ein Objekt der neuen Klasse im published Teil seiner Komponente deklariert. TLabel hat in seiner Klassen-Hirachie TPersisten drinnen, dh wenn man das Label im published Teil deklariert hat man auch alle Eigenschaften des Labels als "Unteroptionen" im OI. Allerdings ist das nicht wirklich sinnvoll, dann man dann zB auf Eigenschaften wie Left und Top Zugriff hat die ja eigentlich vom Edit gesetzt/gesteuert werden sollen. Daher meine Überlegung:

Ich leite eine neue Klasse TLabelOptions von TPersistens ab und führe jene Properties des Labels ein auf die man zugreifen können soll. Für jedes Property meiner TLabelOptions-Klasse implementiert man dann eine read (Get-) bzw write (Set-) Methode die intern nichts andres macht als auf die Eigenschaften des Labels zurückzugreifen. Das Label selbst würde ich dann nur mehr als privates Objekt-Feld deklarieren, damit von außen gar kein direkter Zugriff mehr erfolgen kann. (ist ja auch nicht nötig, wenn man alle wichtigen Eigenschaften über das TLabelOptions-Objekt ändern kann).

Das warst erstmal. Ich meld mich heute/morgen wieder wenn ich fertig bin (hab BTW auch den rest des Codes ein bisschen überarbeitet).

So long...