Code verkürzen (Clear bei mehreren Edits)

[Hagbart]

halllo,

Erstma Sorry für den Sche.. Titel, aber wusste nicht wie ich das sonst beschreiben sollte. Aber jetzt zum eigentlichen Problem (dabei ist es ja gar kein Problem )
Ich hab mir so eben die Frage gestellt, ob man diesen Code nicht einfacher bzw. kürzer fassen kann (ich finde es sieht irgendwie unprofessionell aus :roll: ). Ich denke dabei an soetwas wie eine Schleife, aber logischer weiße kann man nicht einfach

Delphi-Quellcode:

 Edit + variable + .Clear;

machen.

Delphi-Quellcode:

procedure TForm2.Button2Click(Sender: TObject);
begin
  Edit2.Clear;
  Edit3.Clear;
  Edit4.Clear;
  Edit5.Clear;
  Edit6.Clear;
  Edit7.Clear;
  Edit8.Clear;
  Edit9.Clear;
  Edit10.Clear;
  Edit11.Clear;
  Edit12.Clear;
  Edit13.Clear;
  Edit14.Clear;
end;

[youuu]

Delphi-Quellcode:

for i := 0 to ComponentCount - 1 do
  if Components[i] is TEdit then
    TEdit(Components[i]).Clear;

Sollte funktionieren, wenn du alle Edit Felder löschen möchtest in deiner TForm.
Oder geht es wirklich nur um die genannten?

[Hansa]

Zuerst : ComponentCount <F1>

Prinzip ist so :

Delphi-Quellcode:

if (MeineKomponente is TEdit) then
  (MeineKomponente as TEdit).Clear;

Uff, fast schon zu spät. :shock: Trotzdem genau gucken : meine Zeilen sind etwas anders wegen dem "as".

[Cyf]

Zitat:

Zitat von Hansa

Zuerst : ComponentCount <F1>

Prinzip ist so :

Delphi-Quellcode:

if (MeineKomponente is TEdit) then
  (MeineKomponente as TEdit).Clear;

Uff, fast schon zu spät. :shock: Trotzdem genau gucken : meine Zeilen sind etwas anders wegen dem "as".

Dann kann man sich das as schenken.

Delphi-Quellcode:

TForm.FindChildControl
TForm.FindComponent

Aber alle Edits in eine TObjectList stecken und die durchlaufen wäre imho deutlich eleganter.

[DeddyH]

Zitat:

Zitat von Hansa

Zuerst : ComponentCount <F1>

Prinzip ist so :

Delphi-Quellcode:

if (MeineKomponente is TEdit) then
  (MeineKomponente as TEdit).Clear;

Uff, fast schon zu spät. :shock: Trotzdem genau gucken : meine Zeilen sind etwas anders wegen dem "as".

Das spielt hier aber keine Rolle, da der Typ ja direkt vorher erst ermittelt wird.

[mkinzler]

Zitat:

Dann kann man sich das as schenken.

Delphi-Quellcode:

TForm.FindChildControl
TForm.FindComponent

Nicht unbedingt, denn auch eine andere Komponente könnte Edit1 o.ä. heissen, aber kein TEdit sein.

[DeddyH]

Wieso, is ermittelt doch den Typ.

[mkinzler]

War als Antwort für Cyf gedacht (hat sich mit deiner Antwort überschnitten)

[DeddyH]

Achso, sry, mein Fehler :oops:

[Cyf]

Zitat:

Zitat von mkinzler

War als Antwort für Cyf gedacht (hat sich mit deiner Antwort überschnitten)

:gruebel: Dachte eigentlich auch

Zitat:

Zitat von DeddyH

Wieso, is ermittelt doch den Typ.

[Edit]Ok, war vielleicht oben ungünstig untereinander gesetzt. :wink:

[himitsu]

Mal ganz im Ernst .... die Suche existiert nicht umsonst :!:

z.B.: Clear TEdit > http://www.delphipraxis.net/internal...t.php?t=156979

Und das ist gerade Mal einen Tag alt.

[Hagbart]

Erstmal danke. Genau das was ich wissen wollte.

Zitat:

Zitat von himitsu

Mal ganz im Ernst .... die Suche existiert nicht umsonst :!:

z.B.: Clear TEdit > http://www.delphipraxis.net/internal...t.php?t=156979

Und das ist gerade Mal einen Tag alt.

Sorry, gesucht habe ich. Ich habe halt nur nicht gezielt nach "Clear TEdit" gesucht sondern eher nach allgemeinen Begriffen wie z.B. "Komponente in Schleife". Denn wenn jetzt jemand den gleichen Thread statt mit TEdit mit TMemo erstellt hätte, hätte ich ja vermutlich nichts gefunden. Denn das Beispiel mit TEdit habe ich nur gebracht, weil ich mir dachte das es jeder kennt. Bei meinem Projekt geht es konkret um JvSimIndicator von denen ich mehrer auf einer Form habe und alle zurücksetzen möchte.

[Hansa]

Hier scheint Verwirrung zu herrschen. :mrgreen: Trotzdem noch zu dem is/as. Man kann ja sogar den Namen der Komponente für gezielte Aktionen verwenden. Angenommen, man will irgendeinen Text wegen irgendeiner Aktion, z.B. ButtonClick nur im "Edit9" haben :

Delphi-Quellcode:

    if c is TEdit then
      if (copy ((c as TEdit).Name,5,1) = '9') then
        (c as TEdit).Text := 'TEST';

Wäre zwar identisch mit

Delphi-Quellcode:

Edit9.Text := 'TEST';

, ABER :

Wenn man die Namen der Komponenten geschickt wählt, dann lassen sich schöne Konstrukte bauen, die man dann mit Schleife über ComponentCount und dem entsprechenden Prefix etc. gezielt ansprechen kann. Beispiel : Adresse und noch diverse andere Editfelder.

Nenne ich die Adress-Felder jetzt konsequent z.B. edAdrAnrede, edAdrName etc. dann brauche ich nur auf 'edAdr' zu prüfen (siehe oben) und mache auf einen Schlag die Adresse leer, ohne die anderen Felder zu beeinflussen.

[himitsu]

"as" prüft genauso wie "is" ... nur wirft "as" im Fehlerfall eine Exception und gibt als Result den Typ des Vergleichs,
wärend "is" nur prüft und als Result einen Boolean mit dem Ergebnis des Vergleichs liefert.

und typ(var) konvertiert ohne eine Prüfung...


da jetzt schon mit "is" geprüft wurde, kann man also jegliche weitere Prüfung mit "as" eigentlich weglassen.

Delphi-Quellcode:

if c is TEdit then
  if (copy (TEdit(c).Name, 5, 1) = '9') then
    TEdit(c).Text := 'TEST';

Zitat:

Wenn man die Namen der Komponenten geschickt wählt, dann lassen sich schöne Konstrukte bauen, die man dann mit Schleife über ComponentCount und dem entsprechenden Prefix etc. gezielt ansprechen kann. Beispiel : Adresse und noch diverse andere Editfelder.

man kann auch .Tag geschickt verwenden und so die aufwendigen Stringoperationen durch nette Integer-Operationen ersetzen :angel:

[Hansa]

Tja, die Tags könnte man auch verwenden für sowas. Aber dann sind sie auch nicht mehr frei verfügbar. Und wer weiß ? Wird das mit String-Operationen zu schwer lesbar, dann macht man besser eigene Properties. Bei mir gibts z.B. im OI ein published "aktiv". Das setze ich notfalls mal schnell auf false und die Funktion ist gesperrt. :mrgreen:

[mkinzler]

Zitat:

Tja, die Tags könnte man auch verwenden für sowas. Aber dann sind sie auch nicht mehr frei verfügbar.

Hauptsache du hast am Ende recht und behälst das letzte Wort. :zwinker:

[Hansa]

Zitat:

Zitat von mkinzler

Hauptsache du hast am Ende recht und behälst das letzte Wort. :zwinker:

In der Frage gibt es kein "Recht haben". Ich habe lediglich die möglichen Nachteile vom "Tag verbrennen" angesprochen und man sich notfalls mal mit properties etc. Kundig machen sollte.

[mkinzler]

du hast einen komplizierten weg vorgeschlagen und als man dann einen einfacheren genannt hat, eine Grund gegen diesen gefunden.

[himitsu]

nja, das .Tag ist ja zur freien Nutzung für den Programmierer vorgesehn und wofür man es nun verwendet ist dabei egal ... also kann man es auch ganz gut zur Identifikation nutzen.

ich hab hier irgendwo 'nen alten Installer-Setup rumliegen, dessen Benutzeroberfläche komplett über .Tag identifiziert wird (einige viele Edits, Buttons, ListBoxen ...)

dort sind im .Tag dann die Objekt-ID, Gruppen-ID und einige Statusflags integriert, worüber z.B. alle Edits mit nur ein/zwei Ereignisprozeduren behandelt werden können.