![]() |
Änderungen an Edits und Co feststellen
Hallo,
ich suche gerade eine gescheite Möglichkeit, für Eingabeforms Änderungen festzustellen (um einen SaveButton zu enablen). Ich möchte natürlich möglichst nicht jedem einzelnen Edit/Memo/Combo etc.pp. einen OnChange zuweisen und dort rumprüfen und dann eine globale Variable setzen. Das geht sicherlich, aber wirkt nicht sehr schön und professionell. Meine Überlegung: Kann man die OnChange Events (sind doch TNotifyEvents) irgendwie global abfangen und prüfen (modified?). Hat da jemand schon was praktikables gefunden, oder geht Ihr die per OI mit Zuweisung durch? Gruß und vielen Dank im Voraus! winkel79 |
Re: Änderungen an Edits und Co feststellen
Du kannst allen Edits das gleiche onChange zuweisen, falls du das nicht ausschließen willst. IMHO gibt es keine für den Programmierer ( ;-) ) komfortablere Möglichkeit.
|
Re: Änderungen an Edits und Co feststellen
Hallo,
du kannst ein OnChange mehreren Edits z. B. zuordnen. Ich mach das in manchen Programmen auch, um zu prüfen, ob sich was geändert hat, um dann einen Übernehmen-Button zu enablen |
Re: Änderungen an Edits und Co feststellen
Zitat:
|
Re: Änderungen an Edits und Co feststellen
Zitat:
Hab den roten Kasten übersehen |
Re: Änderungen an Edits und Co feststellen
Danke für Eure Antworten. Das mache noch so spät hier sind ;)
Hab mir sowas schon gedacht mit dem OnChange. Habe aber gerade festgestellt, daß das natürlich nicht bei allen Komponenten klappt. Checkbox und ein paar andere haben den OnChange Event garnicht :( Andere Ideen? |
Re: Änderungen an Edits und Co feststellen
Da kannst du das onClick-Event nehmen. Müsste von den Parametern hinhauen.
[OT] Zitat:
[/OT] |
Re: Änderungen an Edits und Co feststellen
Zitat:
|
Re: Änderungen an Edits und Co feststellen
Hallo Hansa,
Zitat:
Ich wollte die OnChange/OnClick ansonsten automatisch per For-Schleife im OnCreate zuweisen. Mal sehen, ob das was wird. Gruß winkel79 |
Re: Änderungen an Edits und Co feststellen
Zitat:
|
Re: Änderungen an Edits und Co feststellen
Idee gut, Ausführung schlecht. Einige Componenten ohne OnChange haben bereits OnClick Events zugeordnet.
Da muß ich wohl alle einzeln durchgehen... |
Re: Änderungen an Edits und Co feststellen
Benutze :
Delphi-Quellcode:
usw. Das Ganze am besten in der Objektablage.
if XX is TEdit
|
Re: Änderungen an Edits und Co feststellen
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
"This unit implements a class that can store the content of controls on TWinControl container (e. g. a form), allows the containers current content to be checked for changes against a stored state, and also to be restored from a stored state." Siehe angehängtes Archiv. Hab leider die Webadresse nicht mehr, von der ich es heruntergeladen habe. |
Re: Änderungen an Edits und Co feststellen
@winkel79:
TRichEdit, TEdit, TMaskEdit, TMemo haben die Eigenschaft MODIFIED :) Diese Eigenschaft wird TRUE, wenn sich das entsprechende Control bzw der Text im selbigen (ver)ändert. Nach dem Speichern bspw. sollte man natürlich MODIFIED wieder auf false setzen (sofern die Form nach dem Speichern nicht geschlossen wird). |
Re: Änderungen an Edits und Co feststellen
Aaaalso:
Ich mach das bei den meisten Anwendungen so: Auf dem Formular habe ich eine Procedure ToggleButtons. Diese rufe ich nach jeder Aktion auf (OnChange, OnClick etc.). In dieser Methode werden alle Bedingungen für die jeweiligen Controls evaluiert und die dinger enabled / disabled visible / invisble etc. gemacht. Damit kannst Du diese Methode z.B. direkt im OnChange Deiner Edits, aber auch im OnClick Deiner Checkboxen aufrufen und alles ist in Butter. :) |
Re: Änderungen an Edits und Co feststellen
Hallo,
danke für die zahlreichen Antworten. @PeterPanino: Wow, das ist ja ein ziemlich umfangreiches Library. Sieht ja ziemlich gut aus, da muß ich aber mal die Unicode Verarbeitung prüfen - das verwendet ja viele Stringlisten für die Prüfung... Ich werde auch mal die Ansätze von raiguen und Phoenix gleich ausprobieren. Bis bald. |
Re: Änderungen an Edits und Co feststellen
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
du solltest zwei Problemfelder sauber voneinander trennen: Die Feststellung, ob sich etwas geändert hat und die Steuerung der Aktionsschalter. Letzteres wird zeitgemäß über das Ereignis OnUpdate() einer Action erledigt, welche dann den Aktionselementen zugeordnet wird. Beim angehängten Beispiel muss beachtet werden, dass Controls mit gekapselten StringListen (ListBox) Änderungen an diesen Listen nicht melden. Grüße vom marabu |
Re: Änderungen an Edits und Co feststellen
Hallo marabu!
Zitat:
Jetzt liegt alles in jeweils einer Prozedur (1x Execute, 1x Update), die alles prüft. Nun habe ich endlich die ActionsLists verstanden! Danke Dir, das suchte ich auch noch!! :cheers: Zurück zum Problem: Ich sehe gerade, daß z.B. Borland in der IDE den "Speichern" Button immer verfügbar hält. Die haben sich also auch nicht die Arbeit gemacht. Da frage ich mich, ob ich mir überhaupt die Arbeit machen sollte. Insbesondere bei Komponenten wie VST oder anderen, die garnicht Modified oder OnChange bieten... Gibt es hier welche, die Speichern auch immer anbieten (nicht verwechseln mit "Speichern Unter"). Gruß winkel79 |
Re: Änderungen an Edits und Co feststellen
Hallo,
die Aktion "Speichern" immer anzubieten finde ich nicht so gut, der Benutzer hat dann keine visuelle Kontrolle mehr. Die Überwachung von komplexen Komponenten lässt sich immer auf ein einfaches Problem zurückführen. Bei einem Grid (VST kann auch als ein Grid betrachtet werden) würde ich den Änderungsstatus des einzelnen Datensatz überwachen. Freundliche Grüße |
Re: Änderungen an Edits und Co feststellen
Hi marabu!
Zitat:
Aber Du hast mich überzeugt. Ich habe bei VST die Prüfung einfach in das EndEdit der EditLink-Propertyclass eingebaut. Habe nur noch eine Komponente, die kein OnChange o.ä. hat. Onclick geht zwar, aber das klappt mit Änderungen per Tastatur nicht... Gruß winkel79 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:29 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