Ohne async kannst du dies nicht so implementieren. Du müßtest dann umständlich eigene Ereignisse definieren und darauf dann reagieren.
Oder meinst du explizit async void? Dann verwende einfach async Task.
Edit: Nach WinForms oder WPF hatte ich nur deswegen gefragt, weil man bei WPF dies anders lösen würde (MVVM).
@Abt: Warum verwendest du jeweils explizit ConfigureAwait(true)? So wie ich das u.a. in ConfigureAwait FAQ ("Why would I want to use ConfigureAwait(true)?") gelesen habe, bewirkt das nichts.
Ja, das entspricht dann der Präfix-Variante.
Du mußt die Eingabe von Console.ReadLine() entsprechend auswerten, also das erste Zeichen überprüfen, bevor du die Umwandlungen durchführst.
Und dein Quadrat-Konstruktor sollte nur einen Parameter haben.
Außerdem lösche die Konsolenausgaben dort (durch die Ableitung von Rechteck sollen ja die Ausgaben durch dessen Methoden erfolgen - außer dass dann "Recthteck", statt "Quadrat", ausgegeben wird).
Zusatzaufgabe: Vergleiche "Breite" und "Höhe" und gib entsprechend "Rechteck" oder "Quadrat" aus.
PS: Für eine Hausaufgabe so OK, aber falls es dich interessiert, lies mal Kreis-Ellipse-Problem.
wie soll denn unterschieden werden, wie eine Zahl interpretiert wird (als Beispiel: "10" kann sowohl binär, dezimal als auch hexadezimal interpretiert werden)?
Entweder du fragst den Anwender danach oder aber eine gängige Methode ist auch ein Präfix (0b, 0x) zu benutzen.
PS: Dein switch ließe sich auch eliminieren, wenn du einen String "0123456789ABCDEF" benutzt und darauf dann per Index zugreifst.
PPS: gerade erst gesehen - falsches Unterforum (ein Mod. wird es wohl verschieben)...
Ja, du mußt Objekte der Klassen erstellen und dann auch deren Methoden (Umfang, Fläche) aufrufen.
Kennst du schon Arrays oder Listen (List<T>)? Denn der Sinn von abstrakten Klassen besteht darin, deren Methoden aufzurufen ohne den genauen Klassentyp zu kennen.
Wenn man diese Objekte in ein Array oder Liste packt, so kann man dann deren abstrakten (bzw. virtuellen) Methoden in einer Schleife aufrufen und es wird jeweils die zu dem Objekt gehörende überschriebene Methode aufgerufen.
PS: Du kannst deine Beiträge auch noch (eine bestimmte Zeit lang) nacheditieren.
Überlege mal was beim letzten Fighter (element = fighter.Count - 1) passiert (da du ja jeweils den aktuellen Fighter aus der Liste löschst)? Verwende einfach den Debugger ("watch window"/"Überwachte Ausdrücke"), sobald die Exception erscheint, um die Werte anzuzeigen.
Aber das ganze Löschen und Wiederhinzufügen ist überflüssig, wenn du den Code von @OlafSt benutzt (so wie ich es auch schon beschrieben hatte). Dann sind beide Fehler aus der Welt.
PS: Absolute Pfadangaben (als String-Literale) solltest du nicht verwenden (da es ja dann nur auf deinem Rechner funktioniert). Verwende Application.StartupPath mit relativen Pfaden (mittels Path.Concat(...) zusammengesetzt). Das "Data"-Verzeichnis sollte dann auch ein Unterverzeichnis des Ausgabeverzeichnisses ("bin/Debug" bzw. "bin/Release" sein).
Und wie ich mir die Auslagerung als eigene Methode vorstelle:
WriteFight(fighter[element], fighter[opponent], result);
if (result == 0)
result += 2;
else if (result == 1)
result += 2;
else ...
WriteFight(fighter[opponent], fighter[element], result);
Jetzt mußt du nur noch WriteFighter implementieren...
Das ist eher eine ungewollte Codeausführung - es soll ja nur genau 1 Kampfergebnis abgespeichert werden.
Es fehlen jeweils else vor den if (result == ...)-Anweisungen und bisher sind die Änderungen von result auch unnötig, da der gegensätzliche Wert ja direkt als String abgespeichert wird. Besser wäre aber das komplette Neuschreiben (und Aufteilen in 2 Methoden).
An sich ist die Abfrage nicht falsch, aber die Frage ist: was soll dann passieren? Denn bei dir könnte es ja theoretisch sein, daß dann kein (bzw. kaum ein) Kampf stattfindet, wenn zufällig öfter diese Zahl "gewürfelt" wird. Du könntest z.B. einfach solange ziehen, bis diese Zahl unterschiedlich ist (so daß immer eine konstante Anzahl von Kämpfen stattfindet).
PS: Die unteren Links sind einfach meine Signatur (d.h. für dich jetzt noch nicht interessant) - in der alten Forensoftware war dies klarer ersichtlich.
da paßt m.E. einiges an der Logik nicht.
Du solltest ersteinmal genau definieren, wie viele Kämpfe ausgetragen werden sollen und wer gegen wen kämpfen soll.
Bis jetzt führst du 64 (8 * 8) Kämpfe durch und läßt jeden Kämpfer (start_pos) mit 8 zufällig ausgewählten Gegnern kämpfen. Und durch die Einschränkung k == start_pos übergeht der Code dann jeweils einen Kampf (das k++ ist hier bislang nutzlos, da der else-Code dann ja nicht ausgeführt wird).
Warum die Zuordnung der Namen in den Dateien unterschiedlich ist, kann ich dir auf Anhieb auch nicht sagen (s. nächster Satz), aber du könntest in der Konsole ja einfach beide Namen jeweils ausgeben oder alternativ mittels [Artikel] Debugger: Wie verwende ich den von Visual Studio? deinen Code schrittweise abarbeiten.
Der Code würde auch viel übersichtlicher werden, wenn du Teile davon in eigene Methoden auslagern würdest (Logik und IO gehören normalerweise zusammen nicht in eine Methode).
PS: Deine Namenszuordnung innerhalb der Opponent-Klasse über die Listen-Eigenschaften firstNames, nickNames und lastNames zeigen, daß du OOP falsch anwendest. Jedes Opponent-Objekt sollte selbst je eine Eigenschaft für die 3 Namensteile haben!
Du bräuchtest dann auch nicht so komplizierte Stringkonkatenationen durchführen, wenn diese Objekte passende Eigenschaften für die Gesamtnamen (FullName) hätten.
Und auch das Rausschreiben des result machst du zu kompliziert...
Also habe ich tatsächlich in C# keine andere Möglichkeit als mit SQLite zu arbeiten.
@Nexmo: Was hast du denn an meiner Antwort nicht verstanden?
Zitat von Nexmo
was ist denn dieser .net Provider?
Das ist der Datenbank-Treiber für .NET (man braucht dann nur die zugehörigen DLLs und die Datenbankdatei in das Release-Verzeichnis kopieren, so daß du dieses en-block weitergeben kannst - ohne Installation beim Anwender).
Auch für SQLite bräuchtest du den passenden .NET Provider.
Zuersteinmal: Ein Datumswert ist intern unabhängig von der Locale, sondern nur für die Ausgabe wird diese Locale (also z.B. deutsch, amerikansich, britisch, ...) verwendet.
Und der Debugger zeigt es dir in dem Format an, daß du bei Visual Studio als Sprache eingestellt hast.
Ich denke, dein Fehler liegt bei
DTdatum = DateTime.Parse(datum, CultureDE);
Wenn du in der XML-Datei ein amerikanisches Format hast, dann mußt du es auch mit einer amerikanischen ("en-us") Locale parsen.
Es kommt drauf an, was der Hersteller als API anbietet (d.h. es müßte noch ein SDK dazu geben) - meistens per C/C++, aber es gibt auch einige mit .NET API.
Für reine C-APIs kann man auch von .NET aus per P/Invoke auf die Funktionalität zugreifen (Stichwort: Marshalling) - ansonsten ginge auch noch ein C++/CLI Interop-Projekt.
Wie heißt denn der Hersteller des I2C Controllers?
Sorry, dann scheint das nicht so einfach zu gehen (ich habe gerade auch gelesen, daß wohl x:Shared="true" der voreingestellte Wert bei Resources ist).
Hast du denn schon MVVM eingesetzt (s.a. [Artikel] MVVM und DataBinding)?
Ich empfehle dir dazu den Artikel (sowie das Projekt) Navigation with MVVM - dort wird nur einmalig ein ViewModel je Page erzeugt (so daß zwar die Controls evtl. immer wieder erzeugt werden, aber die gebundenen Daten den aktuellen Zustand wieder herstellen).
In der Convert-Methode suchst du dann die übergebene ID (du bindest also an GenreID) aus der Genre-Liste und gibst dann die passende Farbe zurück (bzw. genauer ein Brush, da Background von diesem Typ ist - per XAML wird das intern automatisch umgewandelt).
Edit: Das sollte dann auch bei einer DataGridTextBoxColumn funktionieren.
Danach habe ich es ja auch wie du sagtest, mit Breakpoints versucht. Den Fehler dort abgefangen wo er war. Nur wenn die Exception mir zwar was sagt, dass da ein Fehler ist, hat sie mir ja nicht gezeigt von welchem Code es verursacht wird.
du fragst ja auch die UI-Komponente noch im Background-Thread (und nicht im UI-Thread) ab:
if (... && LampenLabel[j].BackgroundColor == Color.Red && ...)
Packe also diese Abfrage innerhalb des Dispatcher-Codes.
Und
LampenLabel[0]
ist sicherlich ein Fehler (im ersten Dispatcher-Code) und du möchtest
LampenLabel[j]
Außerdem vermischt du generell hier Logik und UI-Code, das sollte man vermeiden.
Also befolge Abt's Rat und steige auf MVVM (DataBinding) um - das direkt Arbeiten mit verschiedenen Threads ist, wie du siehst, sehr fehleranfällig.
PS: Auch den Schreibzugriff auf die Variable j führst du in unterschiedlichen Threads aus (die Anweisung j++ führst du doch logisch jedesmal aus, also reicht diese Anweisung einmalig auszuführen - nach if ... else).
Bitte sehr! Ich bezeichne mich auch selbst als Analyst. ;-)
Du hast aber bzgl Abt einen falschen Link angegeben: AutoUpdaterTest/FormMain.cs (dein geposteter ist mein Link bzgl. GetTempFileName).
Das ist also Testcode, um zu zeigen, was man alles einstellen kann (daher auskommentiert, aber mit entsprechendem Kommentar).
Und wie ich schon schrieb, ist das nur Beispielcode auf der AutoUpdater-Seite (es geht nur darum zu zeigen, daß man InstallationPath setzen kann - mit welchem Wert liegt ja am Anwender der Lib selbst, also du).