Visual Basic 2010 Express Abfragen welcher Button gedrückt wurde

  • VB.NET

Es gibt 40 Antworten in diesem Thema. Der letzte Beitrag () ist von ~blaze~.

    Hi
    das sind dann jene Projekte, vor denen man nach zwei Jahren fluchend sitzt und sagt, "warum hat er das nicht eingebaut, jetzt muss ich jede einzelne Zeile des Programms durchgehen und schauen, ob die kompatibel ist" und wenn keine Kommentare drin sind, sitzt man halt wirklich davor und frägt sich, warum es so gemacht wurde, obwohl die Abfrage doch eigentlich sinnlos ist.

    Nur um auf die Diskussion mit ErfinderDesRades von letztens nochmal Bezug zu nehmen. Das war ein klassisches Beispiel für schlechte Wartbarkeit.
    Wenn das Nie des Jetzts auch ein Nie für zukünftige Entwicklungen ist, dann ist das Einbauen nicht sinnvoll - das ist aber oft eine reine Abwägungssache. Wenn der Aufwand groß ist, lohnt es sich nicht, den Fall einzukalkulieren, aber lieber setze ich mich jetzt 5 Minuten (1 für dieses Problem) hin und mache das, als dass ich bei einer späteren Änderung mich dumm und dämlich suche und einen Bug produziere, weil ich dann doch nicht alle Fälle abgedeckt habe. Bei auswuchernden Dingen, wie bspw. GUI in Windows Forms sitzt man dann halt ewig dran, bis man sich durch den gesamten Code durchgefressen hat. Der umfasst ja bei ausgereiften Anwendungen mehr als 10000 Zeilen strukturierten Code - Kommentare nicht mit eingerechnet - wobei ich auch das eher schrecklich finde; mit einer guten Architektur wäre auch das unnötig. Mit einer guten Architektur würde man allerdings auch genötigt, die Fehler abzufangen, was das gesamte Problem hinfällig macht.

    Viele Grüße
    ~blaze~

    ~blaze~ schrieb:

    das sind dann jene Projekte, vor denen man nach zwei Jahren fluchend sitzt und sagt, "warum hat er das nicht eingebaut, jetzt muss ich jede einzelne Zeile des Programms durchgehen und schauen, ob die kompatibel ist" und wenn keine Kommentare drin sind, sitzt man halt wirklich davor und frägt sich, warum es so gemacht wurde, obwohl die Abfrage doch eigentlich sinnlos ist.
    Stimmt doch ühaupt nicht.
    Also mal konkret - weil ich beziehe mich auf den gezeigten Code und nicht irgendwelchen anderen, wo die Dinge anders liegen mögen.
    Wenn da: post#11 - die Abfangerei von unerlaubtem schlicht weggelassen wird, und in 2 Jahren tritt an der Stelle eine InvalidCastException auf, da fragt niemand nach irgendetwas damals nicht eingebauten (schon gar nicht nach einer Messagebox "Es wurde kein Button geklickt").

    Sondern man fragt sich, welcher Idiot (Üblicherweise man selber) nun diese Methode in einer Weise aufruft, dass der Sender kein Button ist - wie kann das zugehen?
    Und da guckt man in die Aufrufeliste und hat sofort die Stelle und kann seine Grütze aufräumen.
    Hingegen irgendwie abgefangen, geloggt, gemessageboxt, mit eigener Exception (ja ist InvalidCastException denn nicht gut?) - wie auch immer: So einfach und direkt am Fehler kriegt man Lokal-Fenster und Aufrufeliste nicht verfügbar, wenn man da iwas dranbastelt.
    Im Optimum tritt es beim Debugging auf. Wenn du's erst mal an den Kunden gegeben hast, regt sich der darüber auf. Du hast dann halt diesen einen Fall nicht getestet. Wirft ein schlechtes Licht auf dich und auf die Firma, falls vorhanden. Und du suchst nach dem Fehler und musst dich erst noch mit dem Kunden austauschen, was auch nochmal ein Mist ist.

    Ich habe keine Lust mehr auf eine weitere ausufernde Diskussion. Ich stelle meine Ansicht dar und sehe diese als zutreffend an und du hast deine, für die du das gleiche machst. Und das heißt übrigens nicht, dass ich dir recht gebe.

    Viele Grüße
    ~blaze~
    Naja, du wirst es ja iwann hingebaut haben, und nachdem du's hinbaust, wirstes auch ausprobiert haben.
    Und in dem Moment kriegste ja auch schon die Rückmelde.
    Du wirst ja nicht irgendetwas an Kunden ausliefern, was du nicht ein einziges mal ausprobiert hast - sonst geschieht dir ganz recht, mit schlechtem Licht beworfen zu werden.
    Das ist ja genau das Problem: Du baust es hin und weißt nicht, an welchen Stellen das Problem signifikant wird. Folglich musst du sie dir raussuchen und wehe du übersiehst was. Spezialfälle machen dir das Leben eben schwer, sodass du es nicht in einem Testlauf herausfindest, dass dort ein Fehler geschehen kann. Hätte man es vorher berücksichtigt und ungültige Werte frühzeitig abgefangen und abgefragt, würde der Fehler auch in keinem einzigen Case auftreten - wenn man es richtig gemacht hat. Sind meist ein paar Minuten, die man investieren muss, aber die sind in extrem vielen Fällen sehr lohnend.

    Viele Grüße
    ~blaze~
    Versteh ich nicht.
    Also angenommen, ich hab eine Methode gebaut, die von einem ButtonClick aus aufgerufen wird - so wie in post#7.
    In 2 Jahren verfalle ich auf die Idee, diese Methode auch von einem TreenodeMouseClick aus aufzurufen.
    Ja, das werde ich doch mindestens einmal ausprobieren?
    Und wenn das eine dumme Idee war mit dem TreenodeMouseClick, dann möchte ich bitte sofort die Quittung, und nicht erst in iwelchen LogFiles danach suchen, oder mysteriösen Messageboxen nachgehen müssen.

    ~blaze~ schrieb:

    Mit einer guten Architektur würde man allerdings auch genötigt, die Fehler abzufangen, was das gesamte Problem hinfällig macht.

    Ich bin bis jetzt davon ausgegandgen, daß es sich ganau andersrum verhällt. Nun bin ich ?( .

    Unter guter Architektur verstehe ich, Code der eben keine Fehler mehr Produziert und nur auf Fehlerquellen von außen reagieren muss.
    Wenn die Progammlogig sich selbst korregieren muss, erachte ich das nicht als gute Architektur.

    FormFollowsFunction schrieb:

    Unter guter Architektur verstehe ich, Code der eben keine Fehler mehr Produziert und nur auf Fehlerquellen von außen reagieren muss.


    Genau das meine ich. Man frägt Nothing ab, wirft eine ArgumentNullException, falls zutreffend und unerwünscht, usw. und überprüft so, dass es nicht eintritt. Wenn man die GUI-Operationen auslagert, sodass sie nicht mehr an die GUI selbst gebunden ist, sondern losgelöst ist, d.h. Buttons, usw. rufen nur noch externen Code auf, der nicht in der Form enthalten ist, läuft es halt auch darauf hinaus, dass man verpflichtet ist, jede einzelne dieser Komponenten in sich abzuschließen, d.h. jeden Fall zu berücksichtigen. Wenn das nicht passiert, kommt es eben nicht zwangsweise zu einem Fehler, z.B. wenn der Wert Nothing gar nicht erst erreicht wird. Oder man hat schon Änderungen durchgeführt, die nicht mehr umgekehrt werden können und das Programm löscht z.B. einfach mal den Inhalt einer Datei.

    Viele Grüße
    ~blaze~

    ~blaze~ schrieb:

    Man frägt Nothing ab, wirft eine ArgumentNullException,...
    ...womit man im konkreten Fall schon eine Fehlinformation geworfen hätte, die das Debuggen in 2 Jahren was anderes tut als erleichtern ;)
    Der Fehler - nochma gugge post#11 - ist ein InvalidCast, kein ArgumentNull.
    Bzw. ArgumentNull könnte es auch sein, und der würde ja auch geworfen im Auftrete-Fall, wenn man sich da nicht einmischtete.

    Wie gesagt: Zumindest gelegentlich einfach mal die Finger davon lassen und die Exceptions ihren Job machen lassen - wenn man da nix dranbaut, baut man auch keinen Mist dran, und es läuft alles eiglich sehr gut.
    InvalidCastException darf nur vom System geworfen werden und indiziert falsche Implementierung. ArgumentNullException indiziert falsche Verwendung.
    Also meiner Ansicht nach ist deine Perspektive in diesem Fall falsch. Und der .Net-Code stimmt mir zu (siehe Reference Source) und die Microsofteigenen Konventionen auch. Wenn Nothing zulässiger Wert ist, darf/sollte man natürlich keine Exception werfen.

    Viele Grüße
    ~blaze~
    also nochmal: Wenn ich die methode aus post#11/post#7 falsch bediene, etwa wie in post#26 angedeutet, mit Treeview als Sender aufrufe, und du wirfst da eine ArgumentNullException, dann wirfst du Desinformation.
    Ich hingegen werfe garnichts, und dann fliegt eine InvalidCast - und das ist genau, was passiert: Ein Treeview ist eben kein Button.

    So einfach ist das, wenn man mal die Finger davon lässt. Ob man Reference-Source oder MS-Konventionen so auslegen kann, dass sie sich zu diesem Problem überhaupt äussern ziehe ich in Zweifel.
    Und selbst wenn - weißt ja, was ich von Koryphäen halte: Solange sie argumentieren, bin ich interessiert, wenn sie nur beeindrucken wollen bin ich höchst unbeeindruckt.

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

    Die Wahrcheinlichkeit einer InvalidCastException ist im konkreten Fall aber auch gleich einer ArgumentNullException,
    nämlich NullOrEmty aka Nothing aka 0. :D
    Oder irre ich mich ?
    Ja bei obigem Problem bei dem ich gar nicht mehr bin.
    ArgumentException oder konkreter Typ wäre das Mittel der Wahl.

    Mir reicht's auf jeden Fall jetzt. Was ich sagen wollte habe ich gesagt und ich sehe keinen Sinn in einer weiteren Diskussion.
    Sehr viele Firmen empfehlen auf jeden Fall einen sehr anderen Stil, als du an den Tag legst.

    Viele Grüße
    ~blaze~
    Hallo Leute

    ​Ich habe mich absichtlich aus der Diskussion rausgehalten.
    Mein Gott, dachte nie das mein Snippet solch eine Diskussion auslöst.

    ​1.) Da der Threadsteller noch nicht so weit ist wollte ich ihm mit der Zeile aufzeigen das er genau dieses Snippet nicht durch andere Controls aufrufen kann.
    ​2.) Jeder hat seinen Stil und klar, jeder kann seine Meinung kundtun und seinen Stil aufzeigen. Aber man muss ihn niemanden mit der Brechstange aufzwingen. Jemand der im TDD Stil programmiert oder stets ein gewisses Pattern verwendet wird jetzt nicht sagen das jeder der das nicht macht schon mal alles grundsätzlich falsch macht.
    ​3.) In einem Snippet wird jetzt niemand eine vollständige Fehlebehandlung posten, außer es geht um Fehlerbehandlung.
    ​4.) Es kommt immer darauf an was die Routine macht. Das muss der Threadsteller wissen.
    ​5.) Nehmen wir wieder die Praxis her. Und bitte, hier gehe ich jetzt davon aus das der spezielle Fall nicht getestet wurde und fertig. Der Enduser drückt auf ein Control. Fehler. Was ist dem Endkunden lieber. Ein z.b. Dialog geht auf das ein unerwarteter Fehler passiert ist und er doch bitte das Log übermitteln soll oder das die Anwendung abschmiert und die nicht gespeicherten Daten des Users sind weg!

    ​Man kann lange drüber diskutieren und ich sehe auch den Standpunkt von @ErfinderDesRades. Aber Diskussion hin oder her, ich wollte mit der Zeile nur zeigen das es eben nur bei Buttons geht wenn man es so macht. In diesem Sinne, wenn eure Anwendungen erfolgreich laufen und keine Probleme habt, bleibt eurem Stil doch Treu, jeder muss wissen ob sein Code gut wartbar ist oder nicht.
    ​Ich verstehe ja das die Suche dann nicht so schön ist. Aber VS hat ja mittlerweile Funktionen die dies hinfällig machen. Mit einem klick sehe ich wo der Code aufgerufen wird.

    ​PS: Ich will das Feuer aber jetzt nicht wieder entfachen.

    Schöne Grüße im eigenen Stil ;)
    ​Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Ähhmmm ja, da muss ich widersprechen. Ich ahne worauf ~blaze~ Hinaus will, aber auf deinen Code trifft das nicht zu, der schlicht und einfach Quatsch.
    Nochmal:

    FormFollowsFunction schrieb:

    Die Wahrcheinlichkeit einer InvalidCastException ist im konkreten Fall aber auch gleich einer ArgumentNullException,
    nämlich NullOrEmty aka Nothing aka 0.
    ...

    Weder das TryCast, noch die If NullOrEmty Abfrage ergeben den geringsten Sinn, da im Button.Click Event eben nur Buttons feuern (da tuts dann ein DirectCast) und sender niemals NullOrNothing sein kann.
    Überflüssiger Code ist schlechter Code :!:

    Ich würde das nichtmal Coding Stil nennen, das ist einfach nur Unwissenheit und um so eher du das einsiehst, um so eher kannst du von der Erkentnis profitieren. ;)
    @FormFollowsFunction
    Auf wen bzw. welchen Code bezieht sich die Antwort nun?
    ​Ich hatte nie ​If NullOrEmpty verwendet.

    ​Egal, ich bin hier jetzt eh raus. Habe nie behauptet das ich das in meinem Code habe, siehe Punkt 1 meines vorherigen Posts.
    Aber das wird mir hier jetzt echt du ......

    ​PS: Ist das hier in diesem Forum öfters so?
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Ich beziehe mich natürlich auf deinen Code, und ok, Du hast Nothing abgefragt, das ist natürlich etwas ganz anderes. :rolleyes:
    Ok, wenn du nichts dazu lernen willst, dann lass es eben.
    Der Thread ist spätestens seit Post #12 erledigt.

    Die nachfolgenden Glaubenskriege waren anfangs vielleicht noch interessant, aber inzwischen sind sie auf einem Niveau angekommen, das mir persönlich nicht mehr zusagt.
    Könnt ihr das nicht per PM zu Ende klären?
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --
    Welche Glaubenskriege ?
    Also den Schuh ziehe Ich mir nicht an und auf EDR und ~blaze~ trifft das auch nicht zu.
    Also das meiste an dieser Diskusion, war doch eher faktisch, bis auf ein paar Ausnahmen. :whistling: