3 Buttons und 3 Labels

  • VB.NET

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Ich würde da vermutlich einfach nur hingehen und mit nem Select Case abfragen welcher Button gedrückt wurde und jeweils reagieren?

    VB.NET-Quellcode

    1. Select Case sender.Name
    2. Case Button1.Name : LabelXY.Text = ""
    3. Case Button2.Name : LabelXY.Text = ""
    4. Case Button3.Name : LabelXY.Text = ""
    5. End Select

    Polling is trolling!

    Achtung: Ich habe die komische Angewohnheit, simple Dinge zu verkomplizieren..
    Okay also wir haben ja eine Prozedur mit drei unterschiedlichen Events.

    Mit Hilfe von Select Case können wir dann jedem Event eine Handlung zuweisen, ohne eine neue Prozedur zu erstellen.

    Jetzt ist nur noch meine Frage, wie das mit dem .Name funktioniert.
    Was ist das überhaupt?
    Wieso bezieht man es auf den namen des Parameters (sender)?
    Und wie funktionniert das Wiederaufgreifen unter "Button.Name"?

    Danke
    • Wir haben eine Prozedur die 3 "gleiche" Events (gleicher Signatur) jedoch unterschiedliche Controls abonniert hat.
    • Mit Hilfe von Select Case schauen wir nach welcher der Buttons das Event ausgelöst hat.
    • Das mit dem .Name funktioniert, da der sender hier zu 100% vom Typ Button ist und entsprechend die Property/Eigenschaft .Name besitzt. Wir könnten alternativ den Umweg über Dim btn = DirectCast(sender, Button) machen, was aber totaler Quatsch ist, da wir sowieso einen Button erhalten.
    Der sender enthält hier wie der Name schon sagt den "Sender" des Events, sprich das Control, was das Event ausgelöst hat (also in unserem Fall einen der Buttons).
    Darunter verwende ich Button1.Name als Hilfsmittel zum Vergleich. Wenn der Name (des Senders), dem Namen des Button1 übereinstimmt, dann wurde Button1 gedrückt :).

    PS: Das Select Case könnte auch so funktionieren. (Man beachte die erste & falsche Variante, die man vermutlich zuerst ausprobieren würde:

    VB.NET-Quellcode

    1. ' falsch
    2. Select Case sender
    3. Case Button1 : MessageBox.Show("1")
    4. Case Button2 : MessageBox.Show("2")
    5. Case Button3 : MessageBox.Show("3")
    6. End Select
    7. ' richtig
    8. Select Case True
    9. Case sender Is Button1 : MessageBox.Show("1")
    10. Case sender Is Button2 : MessageBox.Show("2")
    11. Case sender Is Button3 : MessageBox.Show("3")
    12. End Select

    Ich würde allerdings trotzdem die obere Variante bevorzugen^^.. Aber das ist bloß meine Meinung.
    Polling is trolling!

    Achtung: Ich habe die komische Angewohnheit, simple Dinge zu verkomplizieren..

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „Rootbob91“ ()

    @Rootbob91: mach mal Option Strict On, und überdenk nochmal deine Meinung.

    jdfs meine Meinung ist, dass nur dein letzter Select was taugt.
    Ansonsten stimme ich deinen Ausführungen aber zu :thumbup: - mittm Select Cases wird geguckt, welcher der Buttons der Sender ist, und dementsprechend kann man dann unterschiedlich agieren.
    Wahrscheinlich wirds rummeckern, aber ich erinnere mich noch an einen Thread, da sagtest du selber mal zu mir folgendes:
    "Warum hier casten, dass erwartete Objekt ist doch sowieso vom Typ xy".

    Aber freut mich ja, dass wir andererseits einig sind :).
    Polling is trolling!

    Achtung: Ich habe die komische Angewohnheit, simple Dinge zu verkomplizieren..
    Was hat Deiner Meinung nach "casting" mit der Problemstellung zu tun? Hier wird nix gecasted und es geht auch nicht darum, ob 2 Dinge vom selben Typ sind.
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o
    Bei dem Post zu Strict On geht es in der Regel drum, dass es bequem ist es aus zu haben, weil man dann "fauler" sein kann.
    Wenn jemand weiß was er tut und auch weiß was im Hintergrund passiert, kann es auch schön sein...
    Aber es hat viele viele Nachteile.

    Für einen Anfänger ist es aber nahezu tödlich. Denn der wird wahrscheinlich garnicht wissen was im Hintergrund passiert, damit sein Gewurstel funktioniert..
    Er wird irgendwann beim Umstieg in ne andere Sprache riesen Probleme bekommen...
    Und er wird große Probleme bei der Fehlersuche bekommen, wenn der gleiche Code der vermeintlich "richtig" ist auf einmal nicht mehr funktioniert, weil das, was im Hintergrund erraten wird, was gemeint sein könnte, auf einmal nicht stimmt.

    Also direkt Strict On. Gerade beim Erklären!
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D
    ich sehe das mit Option Strict stricter.
    Wenn man weiß was man tut, kanns immer noch nicht schön sein.
    Sondern Strict Off ist der Beweis, dass man nicht weiß, was man tut.
    Man kann auch nicht "fauler" sein, denn Strict On zu proggen ist keinerlei Mehrarbeit.
    Strikte TypÜberprüfung ist keine Lästigkeit, gegen die man an-casten muss, sondern ist eine Hilfe, bei der Auswahl des richtigen Datentyps.
    Und das gilt für Anfänger wie für Fortgeschrittene.
    Wobei - wie gesagt: Wer Strict Off proggt, kann gar nicht fortgeschritten sein, denn er hat den Sinn der Datentypen in einer streng typisierten Sprache noch nicht voll erfasst.

    (Der Vollständigkeit halber: Es gibt Szenarien - Stichwort "InterOp", wo man in der Release diejenigen Dateien Strict Off setzen muss, die InterOp auf Bibliotheken zugreifen, deren Version auf dem Zielrechner nicht bekannt ist.
    Aber in solchen Fällen setzt man explizit nur diese Dateien Strict Off, und kommentiert hinzu, warum das leider unumgänglich ist.)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    @Visual_Prog Gib mal Deinem Thread den Titel VB.NET.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!