Eigenschaft an Textbox anhängen?

[Threin]

Hallo,

ich wollte bei einigen Textboxen eine Eigenschaft oder dergleichen anhängen, weil ich direkt live bei Eingabe prüfen will, ob die Eingabe für die Textbox gültig ist, bspw. bei dem Namen nur alles von a-z und natürlich die Sonderzeichen ä, ö ...
Kann man die Textbox dafür irgendwie überschreiben oder gibt es da eine Möglichkeit eine Eigenschaft an jede Textbox anzuhängen, also z.B textbox.inputAllowed = Numbers?
Ansonsten könnte ich ja bei der Weitergabe nicht erkennen, ob die Textbox nun Nummern akzeptiert oder nicht.

[Christian Marquardt]

Neue Klasse, von der textbox ableiten, neue Eigenschaften implementieren oder überschreiben

[Threin]

Mmm .. dachte ich mir schon.

Wie würde man das ganze denn dann eigentlich regeln, wenn man z.B ein Programm zur Autoverwaltung hätte und auf einer Seite bswp. zur Eingabe des Kennzeichens, des Halters usw. fordert und das gleiche auf einer anderen Seite auch wieder und vielleicht zudem auch noch ein paar zusätzliche Sachen, die auf der anderen Seite nicht vorhanden sind? Wie könnte man dann nachher, wenn man dann auf Bestätigen drückt und die Eingaben an einen Parser weitergibt regeln, das nachher auch im Parser erkannt wird, was das Textfeld überhaupt für Eingaben akzeptiert?
Müsste man dann für diese zwei identische Eingabefelder auch jeweils eine seperate Überprüfung machen?

[Christian Marquardt]

Man würde gemeinsames in eine Klasse packen und verschiedene Abweicungen in jeweils extra Klassen. So werden gemeinsame Funktionalitäten vererbt und brauchen nur einmal implementiert werden

[fanderlf]

Alternativ kannst Du auch eine Art "Controller" bauen der eine Textbox als Parameter akzeptiert. Danach hängt dieser sich an sämtliche Events und Properties dran die ihn interessieren und trifft ggfs. auch die richtigen Maßnahmen.

Etwa so in der Art:

[highlight=c#]
// Den Quellcode hab ich einfach bei mir am Platz aus dem Kopf
// in den Browser getippt. Kann sein dass das so nicht kompiliert.
// Die Idee sollte aber klar werden
public class KennzeichenValidator
{
private TextBox textBox;
public KennzeichenValidator(TextBox textBox)
{
this.textBox = textBox;

this.textBox.TextChanged += Validieren(object sender, EventArgs e);
}

private void Validieren(object sender, EventArgs e)
{
if(textBox.Text.Contains("ä"))
{
textBox.Text.Replace("ä").("ae");
}
}
}
[/highlight]

Das wäre ein Lösung ohne überschreiben der Klasse. Ich bin nicht der Größte Fan von Vererbung. Deswegen wollte ich den Vorschlag hier noch in die Runde werfen Der Vorteil ist dass Du auch mehrere verschiedene Validatoren haben kannst die alle unterschiedliche Sachen machen und dann je nachdem welche Du brauchst Du auch mehrere auf eine einzelne TextBox packen kannst. Bei der Lösung mit der Vererbung müsstest Du Dich beim Kombinieren der verschiedenen Varianten an die Vererbung halten und kannst die verschiedenen Verhalten nicht ganz so gut kombinieren.

[Ralf Jansen]

Bei der Lösung mit der Vererbung müsstest Du Dich beim Kombinieren der verschiedenen Varianten an die Vererbung halten und kannst die verschiedenen Verhalten nicht ganz so gut kombinieren.

Das impliziert das Vererbung hier die schlechtere Variante wäre. Dem würde ich wiedersprechen. Man muß schon ~gute~ Vererbung mit ~guter~ Komposition vergleichen(bzw. man kann auch beides kombinieren). Das ist weder komplizierter noch wüßte ich nicht warum man bei Controls da zurückschrecken sollte (ich spreche explizit von Controls nicht von Klassen allgemein). Wenn man die Designerfeatures ausnutzen will würde man sich mit Vererbung wohl eher leichter tun oder man muß schon sehr viel Arbeit in Designercode stecken um Vererbung zu umgehen.

[Threin]

@fanderelf
Danke für den Hinweis aber mit der Möglichkeit ist das ganze auch doch schon ein wenig umständlicher.

Ich habe das ganze jetzt so gemacht:

public class OwnTextBox : TextBox
{
    public enum inputAllowed { Letters, Numbers, ..... };
    private inputAllowed _inputAllowed;

    public inputAllowed InputAllowed
    {
        get { return _inputAllowed; }
        set
        {
            if (_inputAllowed != value)
            {
                _inputAllowed = value;
            }
        }
    }
}

private TestProjekt.OwnTextBox textBox_FirstName;
this.textBox_FirstName = new TestProjekt.OwnTextBox();
textBox_FirstName.InputAllowed = OwnTextBox.inputAllowed.Letters;

Mich wundert aber, das man die enum auch public machen muss und das man zudem extra
= OwnTextBox.inputAllow.Letters; schreiben muss, wieso ist das so? Wieso nicht einfach inputAllowed.Letters;?

Dann müsste man ja nachher in der Parser Klasse das ganze so testen?

public static void test(OwnTextBox ownTextBox)
{
    if (ownTextBox.InputAllowed == OwnTextBox.inputAllowed.Letters)
    {
         // Was machen ..
    }
    usw ....
}

[Ralf Jansen]

Mich wundert aber, das man die enum auch public machen muss und das man zudem extra
= OwnTextBox.inputAllow.Letters; schreiben muss, wieso ist das so? Wieso nicht einfach inputAllowed.Letters;?

Weil du die enum Klasse in einer anderen Klasse definiert hast die du außerhalb verwendest. Also mußt du per Namespace.Klasse.Klasse referenzieren. Nur die Nennung des Namespaces kannst du dir sparen wenn du eine using Direktive hast.
Weil du die außerhalb der umgegbenden Klasse verwendest muß die naturlich auch public (oder zumindest internal) sein. Das gesamte Sichtbarkeitenkonzept wäre völlig überflüssig wenn ich die Sichtbarkeiten von Typen nachträglich erhöhen könnte (zum Beispiel in dem ich einen privaten Typ in einer public Property verwende).

Wo wir beim logischen Problem wären warum du den enum in der Klasse definierst aber außerhalb benutzt? In der Klasse würde ich Typen nur definieren wenn ich ihn auch tatsächlich nur innerhalb der Klasse verwende.

[Threin]

Es soll sich dabei ja um eine eigene TextBox handeln, wie soll ich sonst überprüfen, um welchen "inputAllowed"-Typ es sich handelt? Ich kann ja schlecht die OwnTextBox Klasse in die Parser Klasse integrieren oder das irgendwie in der Parser Klasse erweitern oder wie soll ich das sonst regeln? Zudem soll das ja ein Attribut der "OwnTextBox" oder wie auch immer sein.

Übrigens kann ich auch wenn ich using testprojekt.klasse benutze immer noch nicht so inputAllowed ... schreiben. Geht das nicht, wenn ich mich immernoch im selbem Namespace befinde? Es gibt als einziges using testrpojekt.properties

[Ralf Jansen]

Es soll sich dabei ja um eine eigene TextBox handeln, wie soll ich sonst überprüfen, um welchen "inputAllowed"-Typ es sich handelt?

Das worauf ich hinaus wollte, du hast einen Typ inputAllowed den du als private für die OwnTextBox Klasse definiert hast. Der einzige der die Klasse kennt und benutzen darf ist damit OwnTextBox. Du willst aber jetzt denn privaten Typ für eine öffentliche Property verwenden. Damit hast du einen privaten Typen öffentlich gemacht und das darf man nicht. Wenn jemand anderes OwnTextBox benutzen soll zum Beispiel dein Parser dann muß er diesen Typ auch sehen dürfen und das geht nunmal nicht wenn er etwas privates von OwnTextBox ist.

Nochmal anders gedacht wieso ist inputAllowed überhaupt Teil der TextBox? Wenn deine TextBox Ableitung den Zugriff für einen dranzuhängenden Validator/Parser darstellen soll sollte das nicht eher eine Eigenschaft des Validator/Parser sein?

[Threin]

Wäre es dann so richtig?

public class OwnTextBox : TextBox
{
    public enum inputAllowed { Letters, Numbers, NumbersAndSL };

    public inputAllowed InputAllowed { get; set; }
}

Ehrlich gesagt fällt mir ja auch sonst keine Möglichkeit ein, als die Textbox abzuleiten. Ich muss ja irgendwie bei jeder TextBox wissen, was diese für Eingaben akzeptieren soll oder nicht. Das ist doch der einfachste Weg oder nicht? Die Parser Klasse soll ja nur die Eingaben überprüfen. Wie sollte ich denn sonst überprüfen, was die TextBox jetzt akzeptiert oder nicht?

Das überprüfen der gültigen Eingaben mache ich weiterhin so wie oben mit ownTextBox.InputAllowed == OwnTextBox.inputAllowed.Letters.

[Ralf Jansen]

Ehrlich gesagt fällt mir ja auch sonst keine Möglichkeit ein, als die Textbox abzuleiten. Ich muss ja irgendwie bei jeder TextBox wissen, was diese für Eingaben akzeptieren soll oder nicht.

Ob es die TextBox selbst weiß oder eine andere Klasse die zum richtigen Zeitpunkt zum überprüfen aufgerufen wird (z.B. von der TextBox) macht keinen Unterschied.

Ich persönlich würde wohl je Typ auch erstmal explizit Ableitungen erstellen und eine NumberTextBox, MeinLiebesFormatTextBox u.s.w. produzieren. Kommt aber jetzt auch genau darauf an wie gut das implementiert sein soll. Letzt endlich ist natürlich eine einzige Ableitung der man einen Validator für verschiedene Prüfungen unterjubeln kann die Ideal Vorstellung. Je nachdem was alles geprüft werden soll muß man an verschiedene Stellen im Control angreifen und das kann je nach dem was man wie validieren möchte andere sein. Welche das alle für seinen eigenen Ansprüche sind weißt du aber eigentlich erst wenn du ein paar implementiert hast. Dann kann man das immer noch konsolidieren und ein Konzept wie einen austauschbaren Validator drüber legen. Z.B. fürs normale schreiben in der Textbox sollte OnKeyPress überschreiben reichen. Wenn du Clipboard Operationen abfangen willst (man kann ja auch Text oder Textteile einfach rein pasten man muß nicht geschrieben haben) wirst du die WndProc überschreiben müssen.

Ein gutes Beispiel einer TextBox die nur Nummern (auch Fließkommazahlen) zuläßt findest du hier.