moinzusammen

hab gestern (Sonntag) mal mit "C#, Winforms" angefangen.
bisher kam ich gut mit Google und Youtube aus, doch das hier finde ich nirgends

ich habe eine form mit 142 Checkboxen und die einziege methode die ich kenne wäre dies beiden:


für jede einzelne Checkbox neu in die confic zu hauen.

gibt es da nicht irgendeine weg das ganze kürzer zu halten


Mein Code:





Moderiert von Th69: Titel geändert (war "Checkbox (142stk) müllen meine confic zu").

- Nachträglich durch die Entwickler-Ecke gelöscht -

142 Checkbox kommen mir irgendwie gerade auch wie ein Usability-Albtraum vor. Da blickt doch vermutlich kein Nutzer durch bzw. ergreift die Flucht, wenn er die sieht.

So einen generischen Kram, wie es frühlingsrolle beschreibt, würde ich nicht machen.
Du hast damit eine Abhängigkeit zwischen Control-Name und XML-Tag

Hier würde ich die Fleißarbeit wählen. Wenn Du nicht gerade alle zwei Tage weitere 100 hinzufügst, machst Du das einmal und danach änderst Du nur noch ab.
Übrigens kann Visual Studio vertikal markieren. Linke Maustaste gedrückthalten, STRG und SHIFT gedrückt halten und dann mit der Maus ziehen.
Wenn Du auf Settings zugreifst, kannst Du so in 142 Zeilen gleichzeitig den selben Code schreiben

Außerdem und ganz ganz wichtig: Verstendliche Namen
CheckBox1 bis 142 geht gar nicht, wenn ich darüber entscheiden müsste, hätte ich dir das sofort an den Kopf geworfen Und ein CleanCode-Buch gleich hinterher
Wähle Namen, die beschreiben, wofür der Boolean-Wert steht und der Name in der Config endet nicht mit CheckBox, in der Config ist es egal, wie der Wert am Ende genutzt wird.



Aber trotzdem hat Christian recht: 142 CheckBoxen klingen danach, dass da ordentlich verschönert werden kann Z.B. mit ComboBoxen und Enum-Werten?

- Nachträglich durch die Entwickler-Ecke gelöscht -

Also für für mich hört sich die Bezeichnung "Warframe" nach einem Spiel an. Und bei 142 Checkboxen denke ich an sowas wie Schiffe versenken. Und da ist auf jeden Fall der generische Weg besser.

Du legst dir einfach eine List<bool> in deinen Properties an, anstatt 142 einzelne bools. Speichern und laden kannst du das ganze dann so (ohne es getestet zu haben):


Der Teil .OrderBy(cb => int.Parse(cb.Name.Remove(0,8)) sortiert die Liste einfach nur aufsteigend nach der Nummer die im Namen der CheckBox ist, also

Wichtig ist bei meinem Code nur, dass die gespeicherte Liste auch tatsächlich so viele Einträge hat, wie es CheckBoxen gibt.

Wie sinnvoll es allerdings ist, ein Spiel auf diese Art zu programmieren, ist eine andere Geschichte

Falls du kein Spiel machst, sondern einfach nur eine ewig lange Settings-Form oder ähnliches hast, in der jede CheckBox eine komplett andere Bedeutung hat, würde ich es auf jeedn Fall wie Palladin007 machen und meinen Beitrag komplett ignorieren.

Frühlingsrolle hat folgendes geschrieben :

Palladin007 hat folgendes geschrieben: So einen generischen Kram, wie es frühlingsrolle beschreibt, würde ich nicht machen. Wie dann? Viele Anhaltspunkte um sie von einander zu unterscheiden, hat man nicht, außer den Control-Typ, Namen und vielleicht noch den Tag, der zuvor gesetzt werden müsste.

Die Aufwendige Art

Wenn die Inhalte dynamisch sind, dann sollten sie auch dynamisch geladen/gespeichert werden.

Wenn aber nicht, dann hat jede CheckBox eine eigene separate Bedeutung und die sollte nicht einfach in einer Liste verschwinden.
Ich würde dann sogar so weit gehen, dass ich eine Klasse erstelle und für jede CheckBox eine sinnvoll benannte Property anlege und die dann alle einzeln in die Config schreibe.

Das ist zwar aufwendig, aber nur einmal, danach kann der Code separat bearbeitet werden.
Es kann ja schließlich auch sein, dass sich im Code was ändert, die Config aber abwärtskompatibel bleiben muss. Spätestens dann fängst Du an, Sonderbehandlungen einzubauen



Aber wie gesagt: Ich behaupte, dass bei so vielen boolischen Werten sich das auch sehr gut mit einem Enum lösen lässt.

Ein Beispiel:
Bei jedem x-beliebigen Wecker-Programm sieht man für die Wochentage einzeln eine CheckBox, es können ja auch verschiedene Tage gleichzeitig ausgewählt werden.
Dafür würde ich ein Enum mit dem Flags-Attribut nehmen:



Für jede der 7 CheckBoxen wird dann ein Flag hinzugefügt oder weg genommen.
7 CheckBoxen auf eine Property und einen Config-Eintrag reduziert und ganz nebenbei noch deutlich besser zu lesen.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Also

Warframe ist ein firstperson game
In dem.man sich seine Rüstungen aus 3-5 teilen zusammen Bau. Immer am Ende einer Mission hat man 5secunden Zeit sich eine beuteil zu wählen.
Es gibt 31 Rüstungen, die aus 142 verschiedenen teilen bestehen,
es gibt 287 Waffen die jede aus 4teilen besteht
Und noch ca 150 sonstige Teile die aus 503teilen bestehen.

Das mach:
142+4*287+503=1793 checkboxen
Jeden Monza kommen waffen, Rüstungen und Ausrüstung dazu
----------------------------------------------------------------------------

Im meinem Programm steht jede Checkbox für eine Bauteil
Immer zu je 3-7teilen dem Endprodukt zugeteilt;

Rüstung: atlas
Helm,chsses, system,Batterie

Mit den checkboxen ist es mir so schnell möglich zu sehen ob ich bestimmte teile schon habe. Und muss mich nicht mehr auf gut Glück entscheiden.
Ich werde wenn ich zu Hause bin , werde ich ein paar Bilder der checkboxen hochladen nnzum leichteren verständnis

Also geht es dir gar nicht darum die Werte zu ändern/checken sondern "nur" darum zu visualisieren was du schon hast?
Wo kommen diese Informationen her?
Wie geschieht die Zuordnung, zwischen Quelle und Checkbox?

Ich glaube ich würde bei so einer Aufgabe eher zu etwas wie einer mehrspaltigen Liste tendieren, in welcher ich die Objekte, die du bereits besitzt anders einfärbst. Das fänd ich zum einen Übersichtlicher und zum anderen lassen sich Listen Objekte in der Regel besser in einem Rutsch füllen.
Da ich aber keine WinForms Erfahrung habe kann ich dir keine spezielle Komponente empfehlen.

Gruß

Es geht mir darum das wenn ich in eine der checkboxen einen haken mache und dann dad s Programm schließe
Und es wieder öffne
Der Haken noch da ist

- Nachträglich durch die Entwickler-Ecke gelöscht -

hier mein aufbau



frühlingsrolle
was du mir da gezeit hat sieht gut aus mal sehn ob ich das irgendwie nutzen kann

Moderiert von Christian S.: Bild als Anhang eingefügt

Frühlingsrolle hat folgendes geschrieben :

Die Frage steht noch aus, in welcher Form die Daten aufgenommen werden sollen. Vieles spricht für eine Datenbank Anwendung, oder eine Datenklasse.

was meinst du mit dasten "Ausnehemne"? abspeichern?

Zitat:

was meinst du mit dasten "Ausnehemne"? abspeichern?

Ich bin zwar auch nicht die hellste Kerze was Rechtschreibung betrifft und kann auch viel ertragen was andere so verbrechen, hier würde ich trotzdem eine Rechtschreibprüfung empfehlen. Zu erraten was du meinst ist fast unmöglich.

Die Properties die du benutzt sind eigentlich eher für Konfigurationsdaten einer Anwendung gedacht aber nicht für Daten einer Anwendung allgemein. Das was du da hast gehört eher in ein für Datenhaltung gedachtes Format. Also z.B. irgendeine Datenbank oder in simplen Fällen (wo ich deinen Anwendungsfall jetzt auch mal verorte) in einem Fileformat wie xml oder json.
Das löst aber natürlich immer noch nicht dein Mengenproblem mit repetitivem Code.

Da gilt es jetzt in deinem Wust von Checkboxen ein Muster zu erkennen. Das kannst du sicher besser als wir weil du denn Context deiner Anwendung besser verstehst.
Ein Blick auf deinen Screenshot zeigt aber ganz deutlich zumindest ein Muster das sich immer wiederholt, die Gruppe von 4 Checkboxen (Neuroptics, Chassis, System, Orokin).
Zur vereinfachten Datenhaltung und zur vereinfachten Programmierung einer UI solltest du solche Muster ausprogrammieren.

Also diese 4 Daten die hinter den Checkboxen stecken als Klasse ausprogrammieren (und was sonst vielleicht noch logisch dazugehört) und für die UI ein User Control programmieren das eben aus den 4 Checkboxen besteht und du einfach dann n-mal auf der Form verwendest so wie du jetzt die checkboxen n-mal benutzt. S solltest du für die gesammte Anwendung vorgehen.

Also die Daten in einer Klasse zusammenfassen. Muster in diesen Daten durch Subklassen darstellen und jeweils dazu korrespondierende User Cointrols für die UI bereithalten. Diese Klasse wenn sie denn mal alle DAten enthält kann man dann einfach in irgendeins der genannten Fileformate serialisieren um sie zu beim nächsten Programmstart zu benutzen oder irgendwo zu transportieren.

Wenn ich mir das so anschaue, sieht das für mich so aus, als könnte man das hervorragende mit einer passenden Objekt-Struktur abbilden.

Meine spontane Idee:
Jede Waffe hat einen Typ (Schwert, Bogen, was auch immer). Das kann z.B. ein Enum mit dem Flags-Attribut sein
Die Modifikationen sehen irgendwie alle gleich aus, so wie es da aussieht, sieht das fast schon nach einem Enum aus.
Allerdings würde ich eher ein Interface schreiben, was zuerst einmal definiert, welche Waffen-Typen diese Modifikation haben können.
Dazu noch der Name und andere Informationen wie z.B. ein Schadens-Multiplikator

Jede Modifikation bekommt dann eine eigene Klasse und wird woanders registriert.

Könnte z.B. so aussehen:



Dazu noch eine Basisklasse für die Waffen bzw. für jede Waffe eine entsprechend erbende Klasse.
Dort wird dann das Objekt der Modifikation übergeben und die Waffe nutzt sie damit. So kann eine Waffe z.B. eine Property BaseDamage und ActualDamage haben. BaseDamage ist immer gleich, ActualDamage ist der BaseDamage mit den Multiplikatoren der Modifikationen zusammen gerechnet.
Die UI wird dann entsprechend dynamisch zusammen gebaut. Anfangs wirkt das komplizierter, wenn dann aber eine weitere Modifikation für alle Waffen dazu kommen sollte, ist das eine Arbeit von 5 Minuten. Mit CheckBoxen dauert das dann bedeutend länger.


Wenn das ganze gespeichert werden soll, sollte das dann in einem eigenen Format liegen.
Das geht zwar auch über die Settings und Du kannst auch einen eigenen Settings-Bereich definieren, aber dafür ist das nicht gedacht.
Mit XML und Linq To XML oder dem XmlSerializer lässt sich das alles ganz flott in eine XML-Datei serialisieren bzw. daraus laden. Wobei ich persönlich vom XmlSerializer abraten würde. Damit hat man sich schnell die Serialisierung aufgebaut, aber nur eher umständlich angepasst. Bei einfachen Daten ok, wenn das ganze aber als Grundlage für das Programm dienen soll, lieber nicht.
Je nach Umfang des Spiels und der damit verbundenen Daten bietet sich vielleicht auch eine Datenbank an.

Ich könnte mir vorstellen, dass viele moderne Spiele genau das speichern: Eine Datenbank-Datei, natürlich umbenannt, aber am Ende bleibt's eine Datenbank.

versuch grad mit nem kollegen es hinzubiegen
jedoch immer wenn wir

nutzen
bekommen wir einen vollkommen Leere Liste

nur man kurz vorweg:
Warframe ist ein vorhandenes FREE-TO-PLAY Spiel
in dem man rüstungen und Waffen herstellt in dem man die einzelteile sich erspielt
dies werden in einem sehr "unübersichtlichen" inventar gesammelt.
warframe.com/de/download

Palladin007 hat folgendes geschrieben :

Meine spontane Idee: Jede Waffe hat einen Typ (Schwert, Bogen, was auch immer). Das kann z.B. ein Enum mit dem Flags-Attribut sein Die Modifikationen sehen irgendwie alle gleich aus, so wie es da aussieht, sieht das fast schon nach einem Enum aus. Allerdings würde ich eher ein Interface schreiben, was zuerst einmal definiert, welche Waffen-Typen diese Modifikation haben können. Dazu noch der Name und andere Informationen wie z.B. ein Schadens-Multiplikator Jede Modifikation bekommt dann eine eigene Klasse und wird woanders registriert.

sowas wie "schaden oder Klasse" sind vollkommen irrelewand und werden auch in keinem zeitpunkt in der Gui auftauchen
der Sinn des ganzen ist es, das man Alle zb. waffen auf einen Blick offen hat.

man hat nur 5 sec zeit , um sich eines von 3 angebotenen teile auszusuchen;
daher sind zb. comboboxen für mich keine Altenative dah man nciht die zeit um nach eine Bestimten waffe zu suchen, man muss alles möglichst auch einen blick haben.

z.Beispiel:

mission gewonnen folgendes zur auswahl(sie haben 5sec zum Wählen):
Bauteil der Waffe Soma: Lauf
Bauteil der Rüstung Frost: System
Bauteil der Waffe Paris Prime: Sehne

/z.B.

daher habe ich keine zeit für irgendwelche aufkleppenden Menüs

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ich glaube, Du hast meinen Beitrag falsch verstanden
Ich betrachte nicht, wie deine Oberfläche aussehen soll. Meinetwegen sind's CheckBoxen, oder ComboBoxen, Du kannst es auch gerne über dreifach verschachtelte MenuItems im ContextMenu machen

Auch was in dem Beispiel steht, ist egal, wichtig ist, dass Du den ungefähren Aufbau verstehst und auf deinen Anwendungsfall überträgst.
Die Oberfläche muss dann daraus dynamisch generiert werden, über z.B. das CheckedChanged-Event von der CheckBox kannst Du dann entsprechend die Daten in den Objekten aktualisieren.

Um bei meinem Beispiel zu bleiben:
Du hast eine Liste von Waffen und eine Liste von Modifikationen.
In dem Control läufst Du durch jede Waffe und sammelst für jede Waffe die erlaubten Modifikationen mit Hilfe des Waffen-Typs.
In dem Control legst Du dann für jede Waffe einen Eintrag an. In jedem Eintrag wird für jede erlaubte Modifikation eine CheckBox hinzugefügt. Bei jeder CheckBox setzt Du dann das CheckedChanged-Event. Du hast ja die Waffe, kennst die Modifikation für die die CheckBox steht und wenn sich Checked ändert, kannst Du die Modifikation entsprechend hinzufügen oder entfernen.

Das Ergebnis ist eine Oberfläche, die sich schnell ergenzen lässt, das Übertragen der Daten zurück in die Objekte passiert automatisch ohne durch Controls zu laufen und zu hoffen, dass die Namen richtig sind.
Soll heißen: Das Problem, dass Du massig CheckBoxen hast und die alle irgendwo weg schreiben willst, fällt komplett weg, das passiert nämlich automatisch.
Wie das dann für den Benutzer aussiehst, kannst Du ganz nebenbei schnell ändern ohne die eigentliche Programm-Logik anzufassen.
Aber das ist mein Beispiel, deinen Anwendungsfall kenne ich nicht.


Überlege dir genau, was Du für Daten hast, was die können sollen, was Du damit machen willst.
Überlege dir dann genau, wie diese Daten in Form von Klassen, Interfaces, etc. aussehen sollten
Und erst dann baust Du die Oberfläche, die die Klassen nutzt ohne selber Funktionalität (bis auf reine UI-Features) zu besitzen.




Ach ja, wegen dem was Frühlingsrolle geschrieben hat:

Zitat:

Hast du dich doch noch mit dem enum-Typ angefreundet, das freut mich. Scheint doch kein NoGo in der OOP zu sein.

In der reinen OOP sind die ein NoGo, die sind nämlich schlicht nicht objektorientiert Aber kein .NET Programm ist komplett objektorientiert, schon deshalb weil .NET selber Werttypen beinhaltet, die das nicht sind. Und auch WinForms hat ein paar Inhalte, die mit der OOP brechen, gerade kämpfe ich beispielsweise mit der ListView. Wer von WPF kommt, wird das Ding hassen -.-
Enums können super praktisch und an einigen Stellen auch sehr sinnvoll sein, können aber schnell mehr Probleme verursachen als sie lösen, weil sie am Ende eben nur Zahlenwerte sind.
Als Alternative finde ich dabei die Idee ganz gut, eine Klasse mit private Konstruktor und public static Properties für die möglichen Instanzen der Klasse. Das ist ähnlich praktisch wie Enums, aber besser zu erweitern, allerdings immer noch grausam zu testen.
Die reine OOP-Lösung wäre ein Interface und entsprechende Implementierungen, die dann irgendwo registriert werden. Das ist aber bei z.B. Wochentagen ziemlich overkill und nervig zu nutzen, außerdem ist es sehr unwahrscheinlich, dass in naher Zukunft noch mehr Wochentage hinzu kommen werden
Oder bei Waffentypen: Ein neuer Waffentyp macht nur Sinn, wenn es auch entsprechende Waffen dafür gibt, was Entwicklungszeit benötigt. In dem Zuge kann man dann auch gleich dem Enum ein neues Feld hinzu fügen.