C# Elemente via String benennen?

2 Antworten

Nein, da die Zugriffe auf die Variable zur Compilezeit bekannt sein müssen.

Im Designer erstellte Controls haben auch immer für die Name-Property den Namen der Variable.

Unter der Voraussetzung kannst Du die Find-Methode nutzen:

this.Controls.Find("LED_11", true);

Ob der zweite Parameter true oder false sein muss, probierst Du am besten mal aus.


Wenn Du die Controls selber anlegst, machst Du mit den Namen das gleiche oder musst selber suchen. Dabei hilft z.B. LINQ to Objects sehr gut:

this.Controls.Cast<Control>().FirstOrDefault(c => c.Name == "LED_11");

Und als dritte Variante:

Du sammelst die Controls in einer Liste oder Dictionary.
Sind sie in einer Liste, kannst Du sie über den Index ansprechen, bei einem Dictionary kannst Du sie über den Key, der jeder Typ sein kann, ansprechen.

Dein erster Satz lässt sich nicht in Einklang mit dynamisch erzeugten Steuerelementen in Einklang bringen. Denn die sind zur Compilezeit eben noch nicht bekannt.

0
@CrystalixXx

Stimmt, aber er möchte die Variablen über einen zusammen gesetzten String ansprechen - so habe ich die Frage zumindest verstanden.

Im letzten Satz beschreibe ich aber ein Vorgehen, wo die Controls nicht über eine eigene Variable direkt zugreifbar gemacht werden, sie werden von einem anderen Objekt verwaltet was dann den Zugriff über z.B. den index oder dem Key erlaubt.

0

... und als vierte, Dirty-Methode gibt es noch Reflection ... ;-)

0
@KnorxyThieus

Ich hab es eigentlich extra nicht erwähnt :D

Man an manchen Stellen ganz hilfreich sein, aber wenn  unerfahrene Entwickler das entdecken und fest stellen, was damit alles möglich ist, dann ist das Chaos vorprogrammiert und hier oder in Foren kann sich keiner mehr vor skurilen Fehler-Beschreibungen retten.

1
@Palladin007

Stimmt, ich schrieb ja auch dirty ...

Generell frage ich mich manchmal, ob es überhaupt Szenarios geben kann, in denen die Verwendung von Reflection mehr als nur die Folge der Unkenntnis über OOP oder eines schlechten Klassenentwurfes ist ... (bin selber noch Anfänger).

0
@KnorxyThieus

Ja, ohne Ende :D

So werden z.B. Attribute via Reflection abgerufen und auch das EntityFramework arbeitet mit Reflection. Auch das Framework CSLA nutzt es intesiv, wobei sich mir der Nutzen da nicht erschließt.

0
@Palladin007

Okay, Attribute leuchten mir ein, die anderen Frameworks sagen mir jedoch nichts.

0
@KnorxyThieus

Schau dir mal das EntityFramework an. Ist besonders für Anfänger leicht zu lernen. Das ist ein ORM (Object Relation Mapper), es ermöglicht die Arbeit mit Daten einer Datenbank ohne selber direkt mit SQL zu arbeiten oder die Connection zu verwalten. Dabei arbeitest Du dann mit Objekten, die die Daten anhand von Properties zugreifbar machen.

CSLA (Component-based Scalable Logical Architecture) ist ein Framework um sog. BusinessObjects zu erstellen die dann im Prinzip die Grundlage für das Programm darstellen. Sie nutzen die Datenschicht, die UI nutzt die BusinessObjects, andere Features wie z.B. Export/Import nutzen auch die BusinessObjects.
Dieser Aufbau fordert aber sehr viel Aufwand und produziert einen großen Overhead an Code und genau das soll CSLA minimieren.
Sich da einzulesen ist aber langwierig

1
@Palladin007

Oh, bei SQL bin ich noch gar nicht ...

Zweckorientiert bei meinen Anwendungen noch gar nicht darauf gestoßen. Was bringt mir das denn C#-intern gegenüber Serialisierung?

0
@KnorxyThieus

Was meinst Du mit Zweckorientiert?

Der größte Vorteil bei Datenbanken ist die intelligente Verwaltung der Daten.

Serialisierung, egal ob binär, XML, Soap, etc. speichert den Zustand von Daten in irgendein Format.
Häufig haben diese Formate aber das Problem, dass zum Verarbeiten der Daten diese komplett eingelesen werden müssen, was besonders bei sehr großen Datenmengen Probleme verursacht. Mir hat mal wer erzählt, er musste eine 10 GB große XML-Datei einlesen und verarbeiten. Da XML komplett geladen werden muss damit es geparst werden kann, bedeutet dass, dass 10 GB im RAM lagen. Dazu dann noch der zusätzliche Speicher während der Vearbeitung. Sein Rechner hat 16 GB und das war viel zu wenig.

Für sowas haben Datenbanken ein eigenes Modell, je nachdem was Du für Daten abfragen willst laden sie nicht alle Daten sondern suchen in den Daten die Position wo der gesuchte Datensatz beginnt und liest nur das ein. Darüber hinaus werden die Daten auf verschiedene Arten verwaltet und angeordnet. Legst Du für die Daten einen bestimmten eindeutigen Schlüssel-Wert fest, dann kann der Datenbank-Server die Daten anhand dieses Schlüsselwertes ordnen was beim Suchen nach eines Datensatzes anhand dieses Schlüssels deutlich schneller funktioniert.

Dazu kommt aber auch noch die Möglichkeit, die Daten verteilt zu verwalten. Wenn Du sie als XML in eine Datei speicherst, dann kannst nur Du auf genau diesem Rechner diese Daten wieder einlesen.
Ein Datenbank-Server kann aber auch auf einem anderen Rechner liegen und über das Netzwerk angesprochen werden, während SQL als standardisierte Sprache die gemeinsame Schnittstelle darstellt.

Auch hier kann wieder optimiert werden. Wenn sehr große Datenmengen über das Netzwerk abgefragt werden müssen, kann das unter Umständen sehr lange dauern. Wenn ein Programm aber nur einen Teil dieser Daten braucht, kann es vorher genau definieren, welche Daten es enötigt und es werden dann auch nur genau diese Daten übertragen. Um da mehr Möglichkeiten zu bieten liefert SQL auch eine Reihe eigener Programmier-Elemente mit, sodass ganze Programmabläufe auf dem Datenbank-Server ausgeführt werden.
So habe ich z.B. mal die Situation gehabt, dass für viele Datensätze ein eindeutiger Name existieren muss. Der Benutzer kann den frei wählen und das Programm muss prüfen ob es den Namen gibt. Vorher wurden alle zig millionen Namen abgerufen und dann lokal durchsucht. Besser ist es, wenn nur der Name zum Server geschickt wird, der sucht und schickt nur ein Boolean zurück.

Auf diese Weise können viele Programme augenscheinlich performanter sein und weniger Anforderungen haben, obwohl das garnicht stimmt, sie lagern zeitintensive Aufgaben mit den Daten einfach auf einen firmeneigenen leistungsstarken Server aus.

Das kann ich jetzt noch eine Weile so weiter führen :D

Einfache Serialisierung sollte aber auch nicht komplett unter den Tisch fallen gelassen werden, Datenbanken sind nicht immer sinnvoll, da sie sehr viel mehr Aufwand bei der Nutzung drum herum fordern. Lokale Einstellungen (Fenstergröße, Position, etc.) sollten bei .NET mit dem eigenen Settings-Verfahren als XML gespeichert werden. Oder allgemein Daten, die lokal auf dem Client nachträglich geändert werden können sollen, aber nicht umfangreich oder komplex genug sind, dass sich eine Datenbank lohnt.

Sobald es aber umfangreicher oder komplexer wird, sollten Datenbanken in Betracht gezogen werden. So eine Datenbank braucht auch nicht immer einen eigenen Server, SQLite von Microsoft brauch nur eine kleine Version vom SQL-Server, SQLite kommt mit einer einzigen DLL klar.

1
@Palladin007

Okay, da habe ich ja etwas gelernt. :)

Nun ja, mit Datenverarbeitung habe ich mich noch nicht groß beschäftigt, soviel zur Zweckorientierung.

0
@KnorxyThieus

Ich würde es als einen der wichtigsten Bereiche neben der eigentlichen Programmierung bezeichnen. Für mich gehören daher C#, WPF und SQL zum Grundwissen. C# für die eigendliche Programmlogik, WPF für die Benutzeroberfläche und SQL für die Arbeit mit Datenbanken.

Natürlich gibt es für alles mehr als eine Möglichkeit, für die meisten Programme würde ich aber mindestens diese drei Dinge brauchen.

1
@Palladin007

Das klingt sinnvoll. Na ja, derzeit lastet mich ein Projekt so aus, dass ich mich nicht auch noch auf Neues konzentrieren kann, aber ich werde es im Auge behalten - zumal ich noch mit WinForms arbeite ... *peinlich!

0
@KnorxyThieus

WinForms ist nicht schlecht aber alt und das merkt man an vielen Ecken, besonders da es an einigen Stellen nicht wirklich sauber objektorientiert arbeitet. Außerdem wird es nicht mehr weiter entwickelt.

Besser ist da schon WPF, da es mitllerweile auch min. genauso viel Material im Internet zu finden gibt, wenn nicht sogar mehr.

Man kann mit WPF aber auch genauso arbeiten wie mit WinForms, sprich im Designer alles zusammen klicken, EventHandler registrieren und dann im CodeBehing füllen. Dabei lässt man aber einige Features und Vorteile von WPF sausen.

Der Unterschied ist dann der, dass es keinen Designer-Code mehr gibt sondern XAML-Code. Außerdem sind einige Dinge bei WPF im C#-Code umständlicher zu lösen als bei WinForms, das liegt aber daran, dass WinForms dafür designed wurde, es im C#-Code zu nutzen. WPF dagegen ist darauf getrimmt ist im XAML-Code kompakt und einfach zu sein, weshalb man im C#-Code eben Abstriche machen muss.

Wenn es um langfristige Entwicklung geht, dann ist WPF auf jeden Fall die bessere Wahl. Es ist um Längen flexibler und mächtiger als WinForms, in den meisten Fällen auch performanter und es wird eben weiter entwickelt ^^

Wer es ganz extrem treiben will kann auch komplett auf ASP.NET setzen und Websites entwickeln. Ähnlich wie es bei Android-Apps gerne gemacht wird könnte man da dann auch eine Browser-Anwendung umsetzen. Das eigentliche Programm hostet dann intern diese Website und zeigt sie in einem angepassten Browser an.
Das wäre die langfristigste und flexibelste Variante, bin ich aber kein Fan von, ich mag WPF zu sehr - und ich bin kein HTML-Fan :D

1
@Palladin007

So pauschal trifft die Aussage auch nicht immer zu. Vorallem im industriellen Bereich, wo noch häufig alte Windows-PCs laufen (Windows 98 und vergleichbar) bleibt nur WindowsForms, wenn denn mit .NET entwickelt wird.

Da kann WPF noch so toll sein. Manchmal geht es nicht anders. Man muss nur wissen, wie man mit den vorhandenen Mitteln umzugehen hat.

0
@CrystalixXx

Natürlich, auf alten Systemen ist man häufig auch an alte Techniken gebunden. Deshalb verwende ich unter Anderem auch das Wort "langfristig" - und niemand kann mir erzählen, Windows 98 ist gut für langfristig angelegte Systeme geeignet ;)

1
@Palladin007

Das kommt auf die maschinellen Steuerungen an. Bei uns laufen noch einige dieser alten Dinger. Eines sogar noch auf DOS und Windows 95 (natürlich ohne .NET). Nicht immer lassen sich alte Steuerungen auf aktuelle Betriebssysteme portieren. Es fehlen meist Treiber für die alte Hardware.

Die Anlagen laufen auch schon über 20 Jahre. Schon sehr langfristig. :-)

1
@CrystalixXx

Und jetzt auf die nächsten 20 Jahre betrachtet? Windows XP und abwärts bekommt keinen Support mehr, da gibt es sicherlich so manche Sicherheitslücken.
Nicht umsonst gelten (oder galten) so manche Anlagen wie z.B. CERN, die eben genau dieses Problem haben (oder hatten), als beliebtes (Trainings-)Ziel für Hacker.

0
@Palladin007

Die Rede ist von industriellen Anlagen. Aus solchen Zeiten übernommene Maschinen werden selten ans Netz gehangen, noch seltener ohne zusätzliche Hardware davor.

0
@CrystalixXx

Ex braucht keinen Zugang zum Netz um Schaden anzurichten, es reicht wenn Menschen damit arbeiten.

Das ändert aber auch nichts daran, dass 20 Jahre alte Systeme nicht mehr lanfristig sinnvoll sind. Vor 20 Jahren waren sie vielleicht gut durchdacht und darauf ausgelegt, langfristig zu funktionieren, aber irgendwann ist eben auch das veraltet.

Ein schönes Beispiel für ein anderes Problem ist die Sprache Cobol.
Damals, als sie entwickelt wurde, war sie vielleicht der Stand der Technik und die Unternehmen haben damit gearbeitet.
Das ist jetzt aber schon eine ganze Weile her, einige dieser Unternehmen haben ihr System aktualisiert, andere nicht.
Die Unternehmen, die ihr System nicht aktualisiert haben, müssen heute mit dem Problem kämpfen, dass sie kaum noch Fachpersonal finden.

So oder so, der Vortschritt drum herum wird nicht aufgehalten.
Irgendwann muss jeder mit der Zeit gehen, sonst tuts jemand anderes.

0

Ich glaube das geht schon, ist aber n seehrr schlechtes Konzept.

Zu erst ein mal sollte dein Spielfeldzustans nicht durch die Buttonfarbe gegeben sein sondern zB durch ein Array im Hintergrund.

Dann wäre es sinnvoll die Buttons in ein Array zu schreiben, dann kannst du zB mit buttons[0, 0] auf das Button oben links zugreifen.

Nein geht nicht und ein schlechter Stil ist deine Variante auch :P

Der beste Stil wäre durch DataBinding möglich.
Im Hintergrund arbeitet eine eigene kleine Mini-Engine (Controller), die für jeden Button ein Objekt und dessen Eigenschaften hat (Model). Die Controls in der UI koppeln sich via DataBinding an ihr jeweiliges representatives Objekt, was von der Engine kommt. Passiert etwas, werden die WinForms-Buttons (View) automatisch durch das DataBinding geändert.

Das ist mit WPF aber einfacher und für den Anfang für ein kleines Projekt oder zur Übung nicht unbedingt notwendig, denn wer dem MVC-Pattern (Model View Controller) folgt (das habe ich eben sehr sehr grob umschrieben) hat in der Regel auch deutlich mehr Code drum herum. Profitieren tut man davon, wenn das Projekt größer ist, lange verwendet oder gewartet werden soll oder ein Team daran arbeitet.

0

Ja ich weiss dass meines auch nicht der allertollste Code ist.. Aber die Spielfelddaten über die Buttonfarben zu definieren ist noch viel schlechter. Und mein Code erreicht das was der Fragesteller will recht einfach (man kann sehr leicht auf die umliegenden Buttons zugreifen!) Außerdem is der Fragesteller ja Anfänger, da muss er ja nicht gleich mit MVC anfangen xD

0

Was möchtest Du wissen?