OOP-TRealEdit von TEdit abgeleitet und Fähigkeiten erweitert

[Hansa]

Hi,

was jetzt kommt bezieht sich hierauf:

http://www.delphipraxis.net/viewtopi...=4012&start=30

Es geht um OOP. Die Quelltexte hänge ich mal als Anhang dran. Um es vorweg zu sagen, es funktioniert, aber ich blicke nicht richtig durch warum eigentlich. :shock: Das ist nun eine neue Komponente, die real, oder irgendwelche Zahlenfelder rechtsbündig behandelt. Wenn es genau so, wie ich gleich erklären werde, installiert wird, befindet sich in der Objektablage bei "Data Controls" noch eine Komponente "RealEdit". Diese hat im OI noch eine property Alignment. Diese kann man nun auf rechts, links oder zentriert einstellen. Bei Zahleneingaben ist das wie bei einem Taschenrechner. D.h. statt der Komponente DBedit zieht man einfach ein DBrealEdit auf die Form und stellt die Ausrichtung ein. Wie gesagt, ich raffe das selbst noch nicht genau, was da hinter den Kulissen passiert. Das ganze ist aus Anregungen zusammengestückelt. Ein paar Fragen stelle ich selber noch zum Schluß.

Die Installation ist folgendermaßen zu bewerkstelligen : File->new->other->package->Add nun muß die Datei "realedit.pas" ausgewählt werden. Dann noch "compile" und "install". Dann müßte die neue Komponente bei "Data Controls" zu finden sein. Die wird dann genau so behandelt wie ein Button o.Ä.

Nun meine Fragen:

1. SetAlignment läßt sich nur compilieren, wenn es so ist, wie es jetzt ist. Lasse ich den Parameter weg, meldet Delphi "incompatible Types", aber ich brauche nur eine rechtsbündige Ausrichtung, für linksbündig nehme ich sowieso das "normale" DBedit. Und Center, was soll ich damit ?

2. Im OI steht standardmäßig taLeftJustify. Wie kann ich das umbiegen, daß da taRightJustify drin steht. Damit hätte sich die erste Frage erledigt.

3. Was macht CreateParams konkret?

Ach so, noch zur Erläuterung : im private-Abschnitt steht die neue Eigenschaft, also Alignment. Dazu dient das FAlignment, welches in SetAlignment gesetzt wird. Um es im OI angezeigt zu bekommen MUß das ganze als published deklariert werden. Das ist wichtig. Sieht man sich das ganze an, im Prinzip nur 4 Zeilen :!: , die in einem riesigen Programm an jeder Ecke benutzt werden könnten.

[edit=Daniel B]Titel angepasst, da viele neue sachen dazu gekommen sind. MfG Daniel :hi:[/edit]

[Hansa]

invalid Session hat wieder zugeschlagen. :twisted:

Hier ist noch ein Beispiel für ein kleines Programm:

Code:

unit RealEd;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, DB, FIBDatabase, pFIBDatabase, FIBDataSet, pFIBDataSet,
  StdCtrls, Mask, DBCtrls, RealEdit;

type
  TForm1 = class(TForm)
    DBRealEdit1: TDBRealEdit;
    pFIBDatabase1: TpFIBDatabase;
    pFIBDataSet1: TpFIBDataSet;
    pFIBTransaction1: TpFIBTransaction;
    DataSource1: TDataSource;
    procedure Edit1Exit(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Edit1Exit(Sender: TObject);
begin
  pFIBdataset1.Active := false;
  pFIBdataset1.SelectSQL.Text := 'SELECT * FROM <TABELLENNAME> WHERE NR = '+Edit1.Text;
  pFIBdataset1.Active := true;
end;

end.

Wird im Edit1 etwas eingegeben stehen die Daten rechtsbündig oder wie auch immer in DBrealEdit1.

[Daniel B]

Hallo,

äähm, kann es sein dass das ganze nicht mit PE funktioniert? So wie ich das sehe muss man wenisgtens Prof. haben, wegen dem DBEdit.
So würde das ganze hier nicht vielen was bringen. ;)

Grüsse, Daniel :hi:

[Hansa]

jo, mit PE gehts wohl nicht, sorry. Denke in einer anderen Dimension. :mrgreen: Aber wie wäre es probeweise das DB in den Typ-Bezeichnungen wegzulassen :?: Ansonsten genau so vorgehen wie beschrieben. Dann einmal das Alignment ändern und zur Entwurfszeit sehen, wie es aussieht.

Für die, die das schon installiert haben : das Package einfach neu compilieren und die Palettenseite der Objektablage z.B. in "Beispiel" ändern, statt "Data Controls"

[Daniel B]

Hallo,

ich habe ein Package erzeugt das vom normlaen Edit abstammt.
Zip runterladen und dann Doppelklick auf die HansaRealEdit.dpk.
Danach erscheint die neue Komponenten auf der Palette Standard. Ganz rechts, ist das gleiche Icon wie beim normalen Edit.

Grüsse, Daniel :hi:

Nachtrag: Doppelklick auf die Komponenten, dann kommt ein Fensterlein, dort auf Install und dann ist es fertig!

[Hansa]

Damit sich keiner den Strick holt 8):

Noch etwas wichtiges, Delphi ist manchmal dumm. :bouncing4: Ist irgendetwas schief gelaufen, falsche Palettenseite usw. dann stellt Delphi sich etwas quer. "Die Komponente x kann nicht installiert werden, weil sie schon in package y drin ist" oder so ähnlich. Sollte so etwas auftauchen, dann muß man folendes tun : Components --> Install Packages --> in der Liste die zu entfernende Komponente suchen (Ja wirklich: Installieren aufrufen, um etwas zu beseitigen :!: :wall: ). Dann Remove/entfernen und ok. Ansonsten gehts schief. Und dann wie beschrieben fortfahren.

Und noch was : im Moment wirkt sich das Alignment im OI nicht aus oder nicht unbedingt wie gewünscht, weil es konstant auf taRightJustify eingestellt ist. Ursprünglich wollte ich es konstant so lassen. Es stellte sich aber heraus, daß das SetAlignment einen Parameter braucht. Siehe meine eigenen Fragen.

[Hansa]

Alignment kann so richtig aktiviert werden:

Code:

procedure TRealEdit.SetAlignment (value:TAlignment);
begin
  fAlignment:=value;
  RecreateWnd;
end;

[Daniel B]

Hallo,

also Eure Begeisterung zum Thema OOP ist berauschend. :roll: Muss ich jetzt einfach mal so sagen. Ich dachte das interesse an dem Thema gibt. Und es gibt auch Personen die sich jetzt deswegen Arbeit machen. Interessierts jetzt doch keinen mehr?

Grüsse, Daniel :hi:

[Hansa]

Hi Daniel B,

sonst brauche ich hier wohl niemanden zu begrüßen. :roll: Das KeyPress mußte noch etwas geändert werden. da müssen natürlich noch . und , rein, sonst ginge nur integer. Dann wurde das OnlyReals nicht berücksichtigt, die Abfrage ob true oder false muß da auch noch rein.

Dann habe ich noch taRightJustify in den Constructor CreateParams eingebaut. Da das Vorfahrobjekt TEdit ist, ist dies standardmäßig von Delphi auf "linksbündig" gesetzt. Der Grund ist einfach nur Faulheit, damit man nicht jedesmal im OI das umändern muß. Jetzt ist zwar alles schön rechtsbündig, aber die Methode ist zu hart. Man kann nun nicht mehr taCenter oder taLeftjustify einstellen. Das muß irgendwo anders rein, bloß wo?

Code:

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

procedure TRealEdit.KeyPress(var Key:Char);
begin
  inherited KeyPress(Key);
  if OnlyReals then begin
    if not (Key in ['0'..'9','.',',',#8]) then
      Key := #0;
  end;
end;

Noch ein Schönheitsfehler : Das Dezimalzeichen (im Moment kann . oder , verwendet werden) kann man eingeben sooft man will. D.h. da müßte noch ein Exception-Handler eventuelle Fehler abfangen. Besser wäre es, sobald ein '.' oder ',' eingegeben wird, eine zweite zu blockieren. Dabei spielt dann auch noch Backspace eine Rolle. wird das einzige DecChar gelöscht sollte man es wieder eingeben können.

[Hansa]

Hiermit braucht man nicht einmal eine Exception abzufangen. Über die Tastatur sind Eingaben wie "53.,.543.3435,,,543.43" nun ausgeschlossen:

Code:

procedure TRealEdit.KeyPress(var Key:Char);
var ZulZeichen : SET OF char;
begin
  inherited KeyPress(Key);         
  if OnlyReals then begin
    ZulZeichen := ['0'..'9',#8];
    if pos (DecimalSeparator,text) = 0 THEN  // kein . im RealEdit.text . zulassen
      ZulZeichen := ZulZeichen + [DecimalSeparator]
    else
      ZulZeichen := ZulZeichen - [DecimalSeparator]; // zweiten .  verhindern
    if not (Key in ZulZeichen) then
      Key := #0;
  end;
end;

Jetzt wäre es vielleicht noch schön, auch den Tausenderpunkt zu berücksichtigen und automatisch zu setzen. Wegen der tollen Resonanz hier, werde ich das wohl auch selber machen müssen.

Zwischenbericht:
alle Eigenschaften der Delphi Standardkomponente TEdit wurden an die neue Komponente TRealEdit vererbt, dann wurden einige Methoden überschrieben und somit durch eigene ersetzt. Um dies zu vereinfachen wurden im OI zwei zusätzliche Felder eingefügt: "Alignment" und "RealsOnly", siehe "published"-Sektion. Also kann ein Edit-Feld nach Belieben rechts/linksbündig oder zentriert eingegeben/angezeigt werden. Steht OnlyReals auf false, können beliebige Zeichen eingegeben werden, RealEdit.text kann dann halt ausgerichtet werden. Steht es auf true, werden nur Zahlen akzeptiert, wobei ein Komma nicht mehrfach eingegeben werden kann. Das schließt falsche Zahleneingaben aus. Desweiteren wurde ein Package erstellt -> compiliert -> installiert, so daß die Komponente wie gewohnt einfach auf eine Form gezogen werden kann.

P.S. (das kann ich mir jetzt doch nicht verkneifen) : zumindest für mich ist es unbegreiflich, daß anscheinend von 99% nur das vorgekaute von Borland benutzt wird. Delphi ist von Grund auf objektorientiert ausgelegt. Alle Komponenten, die ihr benutzt, egal ob Button oder Table sind in ähnlicher Weise von Borland erstellt worden. Da führen sie bei Delphi 6 TLabeledEdit (ist nicht viel mehr, als das TRealEdit hier) ein und schon werden sie Tausende von Updates los. Und ihr Tausende Euros. :mrgreen: Das soll verstehen, wer will. Gott sei Dank gibt es keine Pisa-Studie über deutsche Programmierer. Die würde weit schlimmer ausfallen, als die von den Schülern. :bounce2: Finde ich ziemlich traurig, so was.

[Christian Seehase]

Moin Hansa,

irgenwie hab' ich den Eindruck, dass die hier meist schnellen Antworten auf Fragen/Beiträge verwöhnen :mrgreen:

Zu Deinen Fragen:

1. Zu jeder Eigenschaft die man deklariert kann man eine Get- (read) und eine Set- (Write) Methode deklarieren, deren Parameter/Rückgabewert durch die Eigenschaft für die man sie benötigt festgelegt sind (wie Du ja inzwischen auch schon festgestellt hast).
   Es gibt hierbei eine sehr einfache Möglichkeit sich das Leben zu erleichtern:
   Man schreibt einfach die Zeile
   property Eigenschaft : Datentyp read GetMethode write SetMethode;
   und drückt dann STRG-SHIFT-C (Caret in der Zeile lassen). Dann werden die Deklarationen automatisch erzeugt.
   Es geht auch auf diesem Wege mehrere Methoden gleichzeitig erzeugen zu lassen. Dies gilt nicht nur für Get/Set sondern auch für alle anderen, deren Header man schon in der Klasse deklariert hat.
2. Den Wert der standardmässig im OI erscheinen soll kann man im constructor vorgeben.
3. CreateParams setzt die für den aufruf der CreateWindow erforderlichen Werte (Struktur CREATESTRUCT). Dazu am Besten mal im PSDK unter CreateWindows(Ex) die Einzelheiten nachschlagen.
   In diesem Zusammenhang darf man nicht vergessen, dass ja auch ein Button oder ein Editfeld ein Fenster darstellen, nur eben mit besonderen Eigenschaften.

Wenn die Meldung:

Zitat:

Zitat von Hansa

"Die Komponente x kann nicht installiert werden, weil sie schon in package y drin ist"

oder ählich kommt muss die Kompo erst einmal entfernt werden, weil nun einmal nicht zwei Kompos mit gleichem Namen gleichzeitig im System vorkommen dürfen.
Deshalb sollte man auch seinen Komponenten immer einen Prefix verpassen um die Wahrscheinlichkeit von Kollisionen zu verringern.
Dazu gab's bei Borland sogar mal die Möglichkeit "seinen" Prefix registrieren zu lassen.
(Beispiel RxLib: Hier fangen die Kompos immer mit Trx an)

Zitat:

Zitat von Hansa

...zumindest für mich ist es unbegreiflich, daß anscheinend von 99% nur das vorgekaute von Borland benutzt wird.

Das glaub' ich nicht unbedingt. Es ist nur einfacher fertige Komponenten, von wem auch immer, zu verwenden, als selber welche zu schreiben. In manchen Fällen kann es auch eine betriebswirtschaftliche Entscheidung sein:
Eine Komponente zu schreiben und zu testen kann teurer sein, als eine entsprechende fertige zu kaufen.

Vielleicht ändert sich ja durch Diesen und ähnliche Threads etwas, und es fangen doch ein paar mehr mit der Eigenentwicklung an, nachdem die Hemmschwelle erst einmal überwunden ist. ;-)

[Hansa]

Hi, Christian, willkommen im Club. :mrgreen:

Zitat:

Zitat von Christian Seehase

...dann STRG-SHIFT-C

Guter Hinweis. Die Feldeigenschaften werden richtig gesetzt. Der Typ wird berücksichtigt usw. Im OI ist das dann auch schon drin.

Zitat:

Zitat von Christian Seehase

...Den Wert der standardmässig im OI erscheinen soll kann man im constructor vorgeben.

Dann schau Dir mal meine Sourcen an und sage mir, wo das hin muß. Ich meine damit, daß taRightJustify als Standardwert angenommen wird. In CreateParams ist es wohl fehl am Platze. constructor ist im Moment keiner vorhanden.

Zitat:

..Das glaub' ich nicht unbedingt. Es ist nur einfacher fertige Komponenten, von wem auch immer, zu verwenden, als selber welche zu schreiben. In manchen Fällen kann es auch eine betriebswirtschaftliche Entscheidung sein:...

Wenn Du da eine passende findest, schön und gut. Besser ist es wohl dennoch, sie selber zu machen, dann weiß man,was man hat.

Und nun noch zu meinen 99%: vielleicht ist das zu viel, aber ich mache mal folgende Rechnung auf : 1. fast 1200 registrierte Benutzer 2. Zahl der Gäste wesentlich höher (gerade im Moment das 10-fache) 3. Insgesamt 125 Aufrufe des Themas. 4. Antworten von 2 Benutzern. Das sind dann 1.6 Promille. Also das wären 99.84 %, die das alles nicht nutzen. Gehen wir mal von den Lesezugriffen aus : Falls jeder User das ganze nutzt und sich EINMAL durchliest, haben immer noch 90% kein Interesse. Rechnet man die Gäste hinzu landen wir wieder bei 99%.

Traurig, traurig, aber mir egal. Das Thema ist wichtig, das weiß ich.

[Christian Seehase]

Moin Hansa,

Zitat:

Zitat von Hansa

constructor ist im Moment keiner vorhanden.

Dann würd' ich mal vorschlagen:
Füg' einen hinzu und initialisiere dort die Ausrichtung.
Dafür ist der constructor auch da.

[Hansa]

wo soll ich denn den am besten einbauen ? Soll ich da Parameter benutzen ?

[Christian Seehase]

Moin Hansa,

ich hoffe mal Dich jetzt richtig verstanden zu haben:

I.d.R. wird ein constructor unter public angelegt, und mit dem Namen Create versehen.

So in der Art:

Delphi-Quellcode:

//...
  published
    constructor Create(AOwner : TComponent); override;
//...

implementation

constructor TDBRealEdit.Create(AOwner: TComponent);
begin
  inherited;
  FAlignment := taRightJustify;
end;

//...

[Hansa]

sieht aus, als wärs das gewesen. Und nun das nächste:

Code:

procedure TRealEdit.KeyPress(var Key:Char);
var ZulZeichen : SET OF char;
begin
  inherited KeyPress(Key);
  if OnlyReals then begin
    ZulZeichen := ['0'..'9',#8];
    if pos (DecimalSeparator,text) = 0 THEN  // kein . im RealEdit.text . zulassen
      ZulZeichen := ZulZeichen + [DecimalSeparator]
    else
      ZulZeichen := ZulZeichen - [DecimalSeparator]; // zweiten .  verhindern
    if not (Key in ZulZeichen) then
      Key := #0
    else begin
      if length (text) = 3 then
        text := text + '.';
    end;
  end;
  end;

Man beachte die Zeile :

Code:

text := text + '.'

Testweise soll bei dem 3. Zeichen ein Tausenderpunkt kommen. So sollte es aussehen: 123.456 und das kommt dabei heraus : 456123. Der Punkt ist zwar gesetzt, aber die Eingabe beginnt danach vor der 1. Zuerst also 4123. dann 45123. usw. Sieht da jemand mehr als ich ?

[[TP]Hawk274]

@Christian Seehase
Warum muss schreibst du den Konstruktor in den Published Teil der Klasse? Wie du auch erwähnt hast schreibt man ihn immer in den Public Teil der Klasse, was ich auch immer mache. Worin besteht jetzt darin der Unterschied?

[Christian Seehase]

Moin Hawk,

da hab' ich nicht aufgepasst.
Der constructor sollte natürlich in den public Teil :oops:

published ist ja auch eine Borland Spezialität für den OI.

[Hansa]

die Spezialität ist: protected. ähmmm

[nailor]

Ich habs bis jetzt noch nicht gebraucht, aber jetzt ist der Moment gekommen. Und es ist sehr gut. Wenn jetzt noch jemand ein SpinEdit so umbastelt, dass es damit arbeitet, dann ist demjenigen mein Dank sicher!!!
:firejump:

[Hansa]

Zitat:

Zitat von Nailor

...aber jetzt ist der Moment gekommen...noch jemand ein SpinEdit so umbastelt, dass es damit arbeitet...

Anscheinend bist Du tatsächlich der erste, der das Original-Orakel in Delphi gefunden hat. :mrgreen: Welcher Moment ist wozu gekommen? Und womit soll ein SpinEdit arbeiten ? Was soll das überhaupt sein ?

[Hansa]

So ich habe das ganze jetzt noch um ein Label erweitert:

Code:

type
  TRealEdit = class(TEdit)
  private
    fAlignment:TAlignment;
    fOnlyReals:boolean;
    fLabel:TLabel;
    procedure SetAlignment(Value:TAlignment);
    procedure SetOnlyReals(Value:boolean);
  protected
    procedure SetLabel(Value:TLabel);
    procedure CreateParams(var Params:TCreateParams); override;
    procedure KeyPress(var Key:Char); override;
  public
    constructor Create(AOwner: TComponent); override;
    destructor destroy; override;
  published
    property Alignment: TAlignment read fAlignment write SetAlignment;
    property OnlyReals: Boolean read fOnlyReals write SetOnlyReals;
    property RealLabel: TLabel read fLabel write SetLabel;
  end;

implementation

procedure TRealEdit.SetLabel (Value : TLabel);
  begin
    fLabel := value;
    flabel.SetSubComponent(true);
  end;

constructor TRealEdit.Create(AOwner: TComponent);
begin
  inherited;
  FAlignment := taRightJustify;
  OnlyReals := true;
  FLabel := TLabel.Create(AOwner);
  FLabel.Caption := 'CAPTION';
end;

destructor TRealEdit.Destroy;
  begin
    FLabel.Destroy;
    inherited;
  end;

Die Caption ist explizit gesetzt als CAPTION und steht so auch im OI. Der Haken an der Sache ist aber, daß das Label zwar offensichtlich existiert, aber nirgends in Erscheinung tritt. Das hängt irgendwo im Nirwana. Wieso das ?

[Motzi]

Zitat:

Zitat von Hansa

Der Haken an der Sache ist aber, daß das Label zwar offensichtlich existiert, aber nirgends in Erscheinung tritt. Das hängt irgendwo im Nirwana. Wieso das ?

Weil du den Parent für das Label nicht gesetzt hast... :roll: ;)

[Hansa]

Vielleich überzeugt das hier doch einige Ungläubige, :shock: die nicht sehen, wie wichtig das Thema ist. Das Label kriegt man auch so hin : man leitet statt von TEdit von TLabeledEdit ab. In die USES Liste muß dann noch "ExtCtrls" rein. Mir selber nutzt das aber nichts, da das ganze letzenendes mit einem TDBedit funktionieren muß und ein TDBLabeledEdit gibts nicht.
http://www.lcschuhmann.de/hornet/meckersmilie.gif

@Motzi: Hast Du das getestet ? Bei mir steht alles, was mit Parent zu tun hat auf true.

[Motzi]

Zitat:

Zitat von Hansa

@Motzi: Hast Du das getestet ? Bei mir steht alles, was mit Parent zu tun hat auf true.

Ich kann momentan nix testen.. aber ich bin mir ziemlich sicher!
Füg einfach diese Zeile in deinem constructor dazu:

Delphi-Quellcode:

FLabel := AOwner;

[Hansa]

Flabel ist doch vom Typ TLabel und Aowner ist TComponent. Wie soll das gehen ? Das meint auch der Compiler. Mittlerweile vermute ich aber auch, daß das an so was liegt. Irgendwie muß ich ja das Label an das Edit dranhängen.

[Motzi]

Zitat:

Zitat von Hansa

Flabel ist doch vom Typ TLabel und Aowner ist TComponent. Wie soll das gehen ? Das meint auch der Compiler. Mittlerweile vermute ich aber auch, daß das an so was liegt. Irgendwie muß ich ja das Label an das Edit dranhängen.

Oops.. hab mich in der Eile vertan..! :oops:
Muss natürlich so lauten:

Delphi-Quellcode:

FLabel.Parent := AOwner;

[Hansa]

soweit war ich auch schon. Dann kommt aber:

inkompatiple Typen : TWinControl und TComponent

Das einzige was geht ist :

Code:

FLabel := TLabel.Create(AOwner);

So wars ja vorher auch schon. Das Label bleibt verschwunden.

P.S.: Ich habe mal das TLabeledEdit mit dem hier verglichen, dabei fiel mir auf, daß das im OI fast gleich aussieht. Bei dem Standard-Editlabel steht in der Zeile Editlabel als Wert LabeledEdit1.Sublabel, bei "meinem" steht nichts.

[Motzi]

Zitat:

Zitat von Hansa

soweit war ich auch schon. Dann kommt aber:

inkompatiple Typen : TWinControl und TComponent

Achja.. ist eigentlich auch klar... na dann hilft eigentlich nur ein Typecast auf TWinControl - ist aber auch unschön.

Am besten wäre es die SetParent-Methode des Edits zu überschreiben um damit auf ein setzen des Parents des Edits reagieren zu können und den Parent des Labels entsprechend zu korrigieren. Ich weiß allerdings nicht, ob die SetParent-Methode als private oder protected deklariert ist und virtual bzw dynamic oder eben static ist... Überschreiben ginge nur wenn sie im protected-Teil und als virtual oder dynamic deklariert ist...

Eine andere Möglichkeit (über schön oder unschön lasst sich hier streiten) wäre ein eigenes property Parent einzuführen, womit das original Property Parent verdeckt wird. In diesem Fall hat man dann seine eigenen Get/Set-Methoden über die man Zugriffe steuern kann und kann aber intern über inherited auch auf das Original-Property Parent zurückgreifen...

[Hansa]

Hi,

also ein SetParent scheint es nicht zu geben. Ich habe aber jetzt das Label "gefunden". :mrgreen: Das hängt oben links in der Ecke. Bei Object-Treeview war noch ein <component [1]> drin. Klickt man das an, dann sieht man was. Nee, das wird zu kompliziert zu erklären, ich hänge den Bildschirm hier dran. Will ich das Label da wegziehen, kommt ein Fehler, den hänge ich auch noch dran, vielleicht weiß jemand was damit anzufangen.

[Hansa]

hier der Fehler

[Hansa]

Ich habe eine Vermutung. Die stelle ich mal so in den Raum : Bei einem TLabeledEdit ist das Label eher ein Panel, als ein Label. Könnte das sein ?

[Motzi]

Zitat:

Zitat von Hansa

Ich habe eine Vermutung. Die stelle ich mal so in den Raum : Bei einem TLabeledEdit ist das Label eher ein Panel, als ein Label. Könnte das sein ?

Hm.. glaub ich eigentlich nicht... aber ich kann momentan nur Vermutungen anstellen, da ich auf meinem Zivi-Arbeitsplatz sitz. Hab erst wieder zu Hause ein Delphi zur Verfügung.

[nailor]

Zitat:

Zitat von Hansa

Zitat:

Zitat von Nailor

...aber jetzt ist der Moment gekommen...noch jemand ein SpinEdit so umbastelt, dass es damit arbeitet...

Anscheinend bist Du tatsächlich der erste, der das Original-Orakel in Delphi gefunden hat. :mrgreen: Welcher Moment ist wozu gekommen? Und womit soll ein SpinEdit arbeiten ? Was soll das überhaupt sein ?

Welches Original-Orakel? Der Moment, in dem ein SpinEdit mit rechtsbündigen Zahlen praktisch wäre, ist gekommen. Sollte die zweite Frage beantworten. Ich hätte gerne die SpinEdit-Komponente aus der Samples-Abteilung mit dem Text nicht links, sondern rechts!

[Hansa]

Dann kupfere doch mein RealEdit ab und erweitere das Spinedit. So wie ich das mit dem TEdit gemacht habe. Du brauchst sogar nur das fAlignment und die zugehörigen Funktionen einzubauen. Alles andere am besten rausschmeißen. Der Thread hier müßte eigentlich ein gute Vorlage sein. Ich habe doch den ganzen Quelltext sogar als Anhang mitgeschickt. Und glaube Daniel B sogar das fertige Package. 8)

[oki]

Hi Hansa,

ich würde mal gern mit reinschauen. Wo finde ich den aktuellen Code?

Gruß oki

[Hansa]

Ich habe den Tausenderpunkt hinbekommen, werde ihn aber nicht benutzen. Und zwar aus einem trivialen Grund: Der Punkt muß ja durch die Zahl "hüpfen". Und das ist einfach nur irritierend. Deweiteren muß der DecimalSeparator auch noch berücksichtigt werden. An diesem Punkt hab ich dann aufgehört. die exe hängt hier dran. Wer den Source braucht, soll sich melden. Ich will in dem Thread hier nicht zu viel durcheinander bringen.

[Hansa]

hier ist noch der momentane Code (das Label will einfach noch nicht) :

Code:

Unit RealEdit;

interface

uses
  Windows, Messages, SysUtils,
  Variants, Classes, Graphics,
  Controls, Forms, Dialogs, StdCtrls,ExtCtrls;

procedure Register;

type
  TRealEdit = class(TCustomEdit)
  private
    fAlignment:TAlignment;
    fOnlyReals:boolean;
    fLabel:TLabel;
    procedure SetAlignment(Value:TAlignment);
    procedure SetOnlyReals(Value:boolean);
  protected
    procedure SetLabel(Value:TLabel);
    procedure CreateParams(var Params:TCreateParams); override;
    procedure KeyPress(var Key:Char); override;
  public
    constructor Create(AOwner: TComponent); override;
    destructor destroy; override;
  published
    property Alignment: TAlignment read fAlignment write SetAlignment;
    property OnlyReals: Boolean read fOnlyReals write SetOnlyReals;
    property RealLabel: TLabel read fLabel write SetLabel;
  end;

implementation

procedure TRealEdit.SetLabel (Value : TLabel);
  begin
   fLabel := value;
   flabel.SetSubComponent(true);
  end;

constructor TRealEdit.Create(AOwner: TComponent);
begin
  inherited;
  FAlignment := taRightJustify;
  OnlyReals := true;
  FLabel := TLabel.Create(AOwner);
//  FLabel.Parent := AOwner;
  FLabel.Name := 'RealLabel';
  FLabel.SetSubComponent(true);
  FLabel.Caption := 'CAPTION';
end;

destructor TRealEdit.Destroy;
  begin
    FLabel.Destroy;
    inherited;
  end;

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];
  fAlignMent := taRightJustify;
end;

procedure TRealEdit.KeyPress(var Key:Char);
var ZulZeichen : SET OF char;
begin
  inherited KeyPress(Key);
  if OnlyReals then begin
    ZulZeichen := ['0'..'9',#8];
    if pos (DecimalSeparator,text) = 0 THEN  // kein . im RealEdit.text . zulassen
      ZulZeichen := ZulZeichen + [DecimalSeparator]
    else
      ZulZeichen := ZulZeichen - [DecimalSeparator]; // zweiten .  verhindern
    if not (Key in ZulZeichen) then
      Key := #0;
  end;
end;

procedure TRealEdit.SetAlignment (value:TAlignment);
begin
  fAlignment:=value;
  RecreateWnd;
end;

procedure TRealEdit.SetOnlyReals (value:boolean);
begin
  fOnlyReals:=value;
  RecreateWnd;
end;

procedure Register;
begin
  RegisterComponents('Eigene', [TRealEdit]);
end;

end.

[oki]

Hi Hansa,

ich hab mir die pas angeschaut. Da sind mir ein par Fragen gekommen. (ich würde die gerne mal erörtern, wobei es nicht darum geht, dass ich damit recht habe)

Deine Methode KeyPress.

Du rufst inherited KeyPress(Key) am Anfang auf und bearbeitest dann nachträglich den Wert im Edit.

Warum nicht prüfen, verändern und dann mit keypress über inherited weiterverarbeiten lassen? so nach dem Motto:

Delphi-Quellcode:

procedure TRealEdit.KeyPress(var Key:Char);
var ZulZeichen : SET OF char;
    Old Key : Char; 
begin
  if OnlyReals then begin
    ZulZeichen := ['0'..'9',#8];
    IF not (Key in ZulZeichen) then begin
      Key := #0;
      Exit;
    end;
    OldKey := Key;
    IF (pos (DecimalSeparator,text) = 0) and Length(Text) = 3 then begin
      Key := '.';
      Inherited KeyPress(Key);
    end;
    inherited keypress(OldKey);
  end;
end;

Also, ist jetzt nicht grad sehr elegant (OldKey ist Quatsch, würde '.' direkt reinschreiben) aber im Prinzip nach der Art.

Außerdem ist der Dezimalseperator nicht der Punkt als Tausendertrennzeichen sondern das Komma; dächte ich.

Gruß oki

[Hansa]

Lese nicht den Kommentar, sondern die Source : :mrgreen:

Code:

ZulZeichen := ZulZeichen + [DecimalSeparator]

Das dürfte wohl genügen. Und dann lese noch den Beitrag von vorhin, der Tausenderseperator interessiert im Moment nicht, es geht nur noch um das Label.