 Frühlingsrolle hat folgendes geschrieben  : |
| Verstehe, dann werde ich mir eine Methode dafür überlegen.
Das Casten scheine ich noch immer nicht verstanden zu haben. Ich meine, was bringt es mir wenn mir ein object sender zur Verfügung steht, und dieser in dem Beispiel eh nur für die Form gedacht ist? Dann hätten die Entwickler gleich aus dem Typ object, ein Typ Form machen können, oder etwa nicht? |
Ahh, eine Frage für Verschwörungstheoretiker.
Meine Theorie.
Weil es heute nur Form ist, heißt ja nicht das man es nicht anders geplant hat bzw. für anderes offen halten wollte und das es sich nicht noch in Zukunft ändert :)
Versetz dich zurück ins Jahr 2000 du müsstest Winforms designen, es gibt also noch nicht Millionen Entwickler die das ~testen~ dabei Stackoverflow volltexten und wo man einfach nachlesen könnte was der durchschnittliche Entwickler denn braucht, sondern du hast nur eine Handvoll Leute für eine kleine interne und öffentliche Beta, musst aber was abliefern was Jahrzehnte halten soll.
Wenn du noch nicht genau weißt wie sich das in Zukunft entwickelt dann versucht man das so allgemein zu halten wie möglich. Es fällt ja auf das es nicht Control ist sondern sogar nur object. Möglicherweise hatte man im Kopf ~künstliche~ sender objecte zurückzuliefern. Also z.B. bei Grid Events Objekte die Zellen darstellen, oder hier bei FormClosing möglicherweise etwas das die Quelle des closens darstellt (Man möchte z.B. ALT+F4 vom Systemmenu von Close() als unterschiedliche KLassen im Sender unterscheiden). Letztlich sind solche Informationen dann alle in den EventArgs oder andere Klassen die man abfragen muss gelandet. Da sich das so etwas entwickelt hat und Winforms ganz nah an EOL ist sieht das natürlich merkwürdig aus. Aber eben nur im Rückspiegel wenn man den Weg wie es entstanden ist nicht im Kopf hat sondern nur das sich stabilisierte Ergebnis kennt. Vermutlich hatte man sich auch gedacht sender braucht man eh nicht so oft meistens wird ein Event an einem Control hängen und gut. Da ist es nicht tragisch wenn man da rumcasten muss. Besser so als jetzt was zu konkret zu designen und sich dadurch Optionen für die Zukunft zu verbauen. Als EventArgs hat man dann ja was konkretes genommen wenn es nötig ist. Konsequent wäre wenn man die auch immer casten muss wenn man die braucht. Aber da war man sich vermutlich sicher die wird man häufiger brauchen. Da riskieren wir es uns konkret festzulegen. Soweit so spekulativ.
Wenn wir das genau wissen wollen müssten wir hoffen das Microsoft oder jemand anderes mal die ganzen Besprechungsnotizen der Framework Designer veröffentlicht. Microleaks oder so.