![]() |
Problem mit meiner CalcEdit-Komponente
Liste der Anhänge anzeigen (Anzahl: 3)
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:
Delphi-Quellcode:
wenn ich da override angebe, krieg ich Mecker.
procedure CMExit(var Message: TCMExit); message CM_EXIT;
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; |
Re: Problem mit meiner CalcEdit-Komponente
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; |
Re: Problem mit meiner CalcEdit-Komponente
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. :hello: :roteyes: mfg BrunoT P.S. Mich hätte das OnExit- Ereignis aber auch interessiert. :lol: |
Re: Problem mit meiner CalcEdit-Komponente
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:
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.)
...
protected procedure DoExit; override; ... procedure TOwnEdit.DoExit; begin inherited; // + deinem zusätzlich Code für diese Situation end; PS. Und warum bist du eigentlich nicht mit dem einfachen Eventhandler (der über die OnExit-Property aufgerufen wird) zufrieden? :chat: 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? :nerd: (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. :mrgreen: |
Re: Problem mit meiner CalcEdit-Komponente
Hi TStringlist,
Danke für die ausführliche Antwort, als Ertrinkender im WWW klammert man sich an (fast) jeden Strohhalm. :zwinker: und: Manchmal Sieht man den Wald vor lauter Bäumen nicht: In meinen Programmen benutzte ich OnExit sehr oft, warum nicht in meiner Kompo? :wall: Das mit der OnExit- Procedure erscheint mir ja auch mehr Delphi-konform zu sein. :-D ich konnte ir nur die folgende Zeile nicht erklären, und kenne auch nicht deren Auswirkungen:
Delphi-Quellcode:
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. :gruebel:
if Assigned(fOnExit) then fOnExit(Sender);
Ich werde als doch OnExit nehmen, da KillFocusHandle auch bein OnCreate(oder so) angesprungen wird. THX BrunoT |
Re: Problem mit meiner CalcEdit-Komponente
:gruebel: 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 :pale:
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 :stupid: |
Re: Problem mit meiner CalcEdit-Komponente
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 |
Bitte testen
Liste der Anhänge anzeigen (Anzahl: 3)
Hi DP'ler,
ich wollte nicht unbedigt einen neuen Thread anfangen, denn soo wichtig ist mein Problem nicht mehr. :mrgreen: 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. :roll: 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. :gruebel: Danke an Marco für's Testen |
Re: Problem mit meiner CalcEdit-Komponente
Hallo Holger,
schon mal zwei kleine Bugs (Tippstreifenrechner.exe):
Gruß, Marco |
Re: Problem mit meiner CalcEdit-Komponente
Hi Marco,
danke für's Testen. Richtig, die Tasten gibt es ja auch noch... Korrigiert und hochgeladen. mfg BrunoT |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:45 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz