Problem mit meiner CalcEdit-Komponente

[BrunoT]

Hallo DP'ler

Hier zum Testen und Weiterverwenden. Die neue Version.

{
wer kennt sich mit Komponentenentwicklung ein bischen aus?

Meine Tippstreifen-Komponente funktioniert schon ganz gut, aber das Anzeige-Memo schließt sich nicht, wenn man die Komponente mit TAB oder SHIFT+TAB verlässt.}*
*(Problem behoben, geht jetzt)

Ich wollte das OnExit-Event neu erstellen, aber ich weiss nicht wie.

mfg

BrunoT

PS.

Ich habe da schon was gefunden, komme damit aber nicht weiter:
     procedure CMExit(var Message: TCMExit); message CM_EXIT; wenn ich da override angebe, krieg ich Mecker.
und dann noch

Delphi-Quellcode:

constructor TCalcEdit.Create(AOwner: TComponent);
begin
  inherited;
  inherited OnExit := NewOnExit;  /das verstehe ich ja noch
end;

procedure TCalcSEdit.NewOnExit(Sender: TObject);
begin
  MemoCalc.Visible := false;
  MemoCalc.Clear;
  if Assigned(fOnExit) then fOnExit(Sender); //Warum unbekannter Bezeichner?
end;

[TStringlist]

Wenn man die Komponente mit TAB oder SHIFT+TAB verlässt, dann verliert sie also in jedem Fall ihren Focus. Ergo könntest du es auch mal über die WM_KillFocus-Message versuchen, bzw. über eine dementsprechende Botschaftsbehandlungsroutine:

Delphi-Quellcode:

procedure KillFocusHandler(var Msg : TMessage); message WM_KillFocus;

  .
  .

procedure TCalcEdit.KillFocusHandler(var Msg : TMessage);
begin
  inherited;
  MemoCalc.Visible := false; 
  MemoCalc.Clear; 
  ...
end;

[BrunoT]

Hi TStringlist,

Danke für den Hinweis. ich habe das Problem jetzt so gelöst, wie du angegeben hast. Ich musste noch feststellen, dass der Focusverlust merfach auch beim Starten des Programmes erfolgt, warscheinlich beim OnCreate, OnShow, OnResize des CalcEdits oder Formulars.

Deshalb habe ich noch eingebaut, dass diese Funktion nur ausgeführt wird, wenn tatsächlich der Inhalt des CalcEdits verändert
wurde.

Damit ist das Problem ja vom Tisch.

mfg

BrunoT

P.S. Mich hätte das OnExit- Ereignis aber auch interessiert.

[TStringlist]

Ich habe nochmal kurz ein bisschen in der OH herumgewühlt, weil mir die CM-Messages und CM-Procs bisher nämlich auch eher unbekannt waren. Sie sind da allerdings auch nicht richtig breit und fett herausgekehrt oder erklärt und deswegen würde ich auf die auch nicht größer drauf aufbauen.

Wo immer du deinen obigen Code her hast, aber zur normalen DelphiUser-Schnittstelle gehört diese CM_Exit-Message u. CMExit-Proc (mit ihrem TCMExit-Datentyp in der Parameterliste) eher nicht, obgleich es aber auch damit gegangen wäre:

Delphi-Quellcode:

procedure CMExit(var Msg : TCMExit); message CM_Exit;

...

procedure TCalcEdit.CMExit(var Msg : TCMExit);
begin
  inherited;
  // + deinem zusätzlich Code für diese Situation
end;

Die für deine Zwecke jedoch normale bzw. richtige Schnittstelle ist hier mit Sicherheit aber mehr die 'DoExit'-Methode von TWinControl. Die hättest du für deine Zwecke nämlich auch gut überschreiben können:

Delphi-Quellcode:

  ...
  protected
    procedure DoExit; override;
  ...

procedure TOwnEdit.DoExit;
begin
  inherited; 
  // + deinem zusätzlich Code für diese Situation
end;

Und so wie es aussieht, wird diese DoExit-Methode dann ja ihrerseits auch wieder von einer Control-eigenen Botschaftsbehandlungsroutine für WM_KillFocus aufgerufen. Also ist auch die Lösung die ich dir ganz oben genannt hatte völlig ok. (In so einem Fall ist es dann nämlich egal welche der beiden Procs du überschreibst, wenn nur das inherited im Code vorkommt.)


PS. Und warum bist du eigentlich nicht mit dem einfachen Eventhandler (der über die OnExit-Property aufgerufen wird) zufrieden? Der wird doch in den Fällen, in dem das Control durch das TAB oder das SHIFT-TAB verlassen wird, auch immer angesprungen. Oder wolltest du ja auch überhaupt nie mehr? (Dann einfach:

Delphi-Quellcode:

constructor TCalcEdit.Create(AOwner: TComponent); 
begin 
  inherited; 
  OnExit := CalcEdit1Exit;  
end; 

procedure TCalcEdit.CalcEdit1Exit(Sender : TObject);
begin
  MemoCalc.Visible := false; 
  MemoCalc.Clear; 
end;

)

PPS. Gut möglich, dass ich mich durch deinen irgendwo aus dem I-Net aufgegabelten Code da auf eine etwas überflüssig komplizierte Bahn habe bringen lassen.

[BrunoT]

Hi TStringlist,

Danke für die ausführliche Antwort, als Ertrinkender im WWW klammert man sich an (fast) jeden Strohhalm.

und: Manchmal Sieht man den Wald vor lauter Bäumen nicht: In meinen Programmen benutzte ich OnExit sehr oft, warum nicht in meiner Kompo?

Das mit der OnExit- Procedure erscheint mir ja auch mehr Delphi-konform zu sein.

ich konnte ir nur die folgende Zeile nicht erklären, und kenne auch nicht deren Auswirkungen:

if Assigned(fOnExit) then fOnExit(Sender); ich hatte es schon mit dem überschriebenen OnExit-Ereignis versucht, es funktionierte auch, aber ich traute mich nicht, weil ich das da oben nicht einfach weg lassen wollte.

Ich werde als doch OnExit nehmen, da KillFocusHandle auch bein OnCreate(oder so) angesprungen wird.

THX

BrunoT

[TStringlist]

hmmm, letztlich kommt es bei der Komponentenentwicklung aber auch immer irgendwie darauf an, was denn das Endprodukt schließlich auch so alles können soll. Angenommen ein Anwender baut das in sein Programm ein und erwartet nun aber so eine OnExit-Property von dieser Komponente selbst wieder angeboten zu bekommen. Also genau so, wie er das ja auch z.B. von jedem normalen TEdit o. TMemo selbstverständlichst gewohnt ist. In diesem Falle wäre für jeden Anwender diese OnExit-Property aber quasi tabu, weil sie ja von dir für das eigene Komponenten-Managment selbst schon "aufgebraucht" wurde. Gebrauchen könnte man die Komponente in dem Falle also nur noch mehr dann, wenn man dann auch jeweils wirklich immer den Quell-Code vorliegen hätte und einen eigenen Code in den dann schon existierenden Eventhandler nochmal zusätzlich inserieren könnte. Für den Anwender wird dieser eigentlich eher unnötige Umstand jedenfalls weniger plausibel sein

Fazit: Bei einer Komponentenentwicklung über die nur persönliche Anwendung hinaus wird man also immer darauf achten, möglichst nie geerbte Properties dieser Art schon selbst "verbraucht" zu haben! ...Und weswegen also letztlich die etwas korrektere Technik trotzdem in der Überschreibung der "DoExit"-Methode liegen dürfte

[BrunoT]

Hi TStringlist,

Ich habe das letztentlich doch über DoExit gelöst. Denn ich benötige auch in meiner Anwendung (wofür ich das teil ja letztentlich gechrieben habe) das OnExit-Ereignis auch.

Ich lade das fertige Teil noch einmal hoch.

mfg und besten Dank

BrunoT

[BrunoT]

Hi DP'ler,

ich wollte nicht unbedigt einen neuen Thread anfangen, denn soo wichtig ist mein Problem nicht mehr.

Dies ist nun eine neue Version(4.0) meiner Komponente Calcedit. Ich stelle die mal hier rein, damit Ihr mal testet.

Selbst macht man ja kaum Fehleingaben.

Was sollte diese Komponente können:
- positive und negative Zahlen
- Anzeige von beliebigen Kommastellen
- Tausender- Trennzeichen
- Ergebins als Text und als Value
- Verhalten wie eine normale Edit- Komponente(eingeschränkt auf Zahlen)
- in der Eingabezeile: rechnen mit den Grundrechenarten wie 3 + 6 und 700 * -2
(div 0 ergibt 0)
- Addieren und Subtrahieren wie ein Tippstreifen- Tischrechner, wobei auch Muliplikation und Divison möglich sind.
3+
6+
5
---
14

mfg

BrunoT

Weiterverwenden erlaubt!

Fehler mit Ende,Home,Pfeiltasten beseitigt.

Danke an Marco für's Testen

[Marphy]

Hallo Holger,
schon mal zwei kleine Bugs (Tippstreifenrechner.exe):

• Drücke nach dem Programmstart die [Ende]-Taste. Was passiert? Nuscht... Und das ist schlecht.
• Dann drücke die [->]-Taste, gebe + ein und drücke [Enter]. Nun funktionieren die [<-]/[->]-Tasten nicht mehr...

Ansonsten schöne Komponente! Noch viel Erfolg bei der Weiterprogrammierung.

Gruß, Marco

[BrunoT]

Hi Marco,

danke für's Testen. Richtig, die Tasten gibt es ja auch noch...

Korrigiert und hochgeladen.

mfg

BrunoT