@T-Virus
Hmh, mir ist eigentlich gar nicht klar was der TE überhaupt damit will. Meistens ja um diese zu entfernen. Daher meine Antwort.

GroupBy ist overkill für Duplikate. Du kannst doch einfach Distinct() verwenden. Schau mal ob er es berücksichtigt wenn du Equals überschreibst oder IEquatable<T> implementierst. Sicherlich gibt es auch irgendwo ne Lib welche Linq um DistinctBy erweitert.

Dabei sollte wenn möglich aber keiner 2x gegen den gleichen spielen und jeder nur einmal mit demselben Partner. Jetzt spielt jeder gegen jeden zwei mal also klassische Liga mit Rückrunden.

So einfach ist das nun auch wieder nicht, schließlich sind in einem Team zwei Leute - er muß ja die Duplikate entfernen. Das Team (m1, m2) ist identisch mit (m2, m1). Du siehst in der Liste das die Gruppen immer kleiner werden. Man muß also darüber sortieren oder einen Comparer einrichten oder mit Iteratoren oder Baumrekursion arbeiten.

Danke,
Oder Komposition.

Man könnte ein Dictionary<String, object> verwenden. Allerdings geht dann die OOP über den Haufen weil gecastet werden muss.

Ja das Problem ist aber dass du die Aufzählung dynamisch brauchst und du wirst dir auf xaml-Ebene dabei einen abbrechen. Möglicherweise bekommst du das mit DataTriggern, Selektoren und CollectionViews gebacken - bei jeder Änderung und Erweiterung jedoch fällt das Kartenhaus zusammen. Musst du entscheiden welchen Weg du gehst - ich würde mit meinen Erfahrungen das auf ViewModel-Ebene lösen.

Du sollst das nicht in die Datenbank schreiben, sondern im ViewModel die Collection zum Lesen vorhalten die für den jeweiligen Typen vonnöten ist. Ein InstrumentViewModel bekommt im Konstruktor sein Modell injiziert und zusätzlich die Liste an Saitendingern die es zur Auswahl braucht - oder es filtert diese sich selbst heraus. Dazu ist das ViewModel schließlich da - das die Daten nicht so präsentiert werden müssen wie sie im Modell definiert wurden.

Du könntest alternativ den jeweiligen Saitensatz in der Instrument-Klasse halten von dem der Benutzer eines auswählt. Oder besser noch mit einem InstrumentViewModel arbeiten. Also ohne RelativeSource arbeiten sondern direkt am Listenobjekt binden.
InstrumentViewModel kennt das Instrument und weiß anhand dessen Typs welche Saitenliste dafür in Betracht kommt. Vllt mit Overriding arbeiten.

Warum wunderst du dich? Du verwendest als Binding Trigger PropertyChanged: nach jedem Tastendruck auswerten.
Also nimm einen anderen UpdateSourceTrigger-Typen oder eine TextBox die für solche Angaben erschaffen wurde.

Verwende Binding und MVVM . Dann kannst du im Setter des entsprechenden Propties im ViewModel reagieren.

Na das ist ja nun nicht schwer sich ein paar Blogs zu merken und jeden Abend mal ein Artikel zu lesen oder ein C#-Keyword nachzulesen oder ein Kapitel aus der C#-language spec wenn man sich durch trockenes Brot fräsen will ...

Sorry, aber du musst mal versuchen genau zu lesen sonst wird das mit der Softwareentwicklung nichts. Die Frage war ob ein AccountData-Objekt mehreren Accounts zugeordnet werden kann.

Du hast drei Tabellen
* TB_Account
* TB_AccountAccountData
* TB_AccountData
TB_AccountAccountData ist eine Link-Tabelle welche eine n:m-Beziehung von TB_Account und TB_AccountData abbildet. Meine Frage war gewesen ob es so gewollt ist, das TB_AccountData zu mehreren TB_Account zugeordnet werden kann.

Nein, das sind zwei 1:n die zusammen n:m ergeben. Die Linktabelle ist überflüssig.

Wieso ist die Beziehung Account :: AccountData n:m? Warum ist da AccountAccountData dazwischen? Du drückst aus dass es mehrere User gibt die sich eine E-Mailadresse teilen. Wenn du das nicht brauchst kannst du die Beziehung zu 1:n vereinfachen und dir den Tanz sparen.

Was has du genau vor? Wenn man einen Zahlenwert angeben soll der sich nur in einem Bereich befinden soll kannst du ein entsprechendes Control verwenden -> NumericUpDown

... man könnte auch alle abhängigen Modelle laden und dann mit einer CollectionView arbeiten.

* du kannst eine CollectionView verwenden
* du kannst das MVVM-Pattern verwenden um die anzuzeigenden Daten in einem ViewModel zu abstrahieren

Man kann die Anfrage auch einfach umdrehen: Gebe alle Kunden die die Einladung mit Id =100 bekommen haben, also irgendwas wie

kunden.Where(p => p.Einladungen.Any(q => q.Id == 100))

FindAncestor-Type fehlt, Beispiel:

 Command="{Binding DataContext.OpenCommand, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type UserControl}}}"

Naja, vllt hast du nur den ersten von mehreren Fehlern gelöst. Wird denn der Code im RelayCommand ausgeführt? Hast du da mal ein Breakpoint gesetzt? Was passiert wenn du den Command von woanders her aufrufst?

Das hat mit dem ScrollViewer nichts zu tun sondern mit dem ItemsControl. Der sucht den HomeCommand in den Elementen der Menge die an das ItemsControl gebunden sind. Such mal nach RelativeSource beim Binding.

Da steht RecordsetTypeEnum.dbOpenSnapshot. Hört sich nach Readonly-Modus an.

Wahrscheinlich tritt irgendwo ein Fehler bei der Vorschauerstellung in Word auf und der Prozeß bleibt als "Zombie" hängen.

Verwende doch einfach Mahapps.Metro

Kann der Server denn Push-Nachrichten versenden?

Dann solltest du die App aber nicht mehr verwenden wenn sie den Status des Einkaufswagens nicht speichert, von Idempotenz der Http-Aktionstypen ganz zu schweigen.

Die Leute meinen du sollst die Exception richtig behandeln damit du erfährst was der Fehler ist. Mach da wenigstens ein Breakpoint ran.

Gibt es einen eleganteren "offiziellen" Weg dafür? Wenn du nicht weißt welches konkrete Objekt gesendet wird: Zuständigkeitskette / Chain of responsibility pattern

Lies dir doch mal Jobangebote durch was da erwünscht ist.

Das ist schwierig zu sagen, da man zu wenig von der Aufgabenstellung weiß. Man könnte sicherlich mit Objekten bauen falls du die Parameter kapseln willst. Wenn verschiedene Typen denselben Code durchlaufen sollen könnte man generisch arbeiten. Man könnte die Algorithmen auch als Methodenargumente übergeben, vllt erklärst du mal genauer was du vor hast.

Also ehrlich, mit so einer Arbeitsweise wirst du nicht weit kommen. Wenn es dir zuviel wird dann mach doch erst einmal ne Pause und arbeite an etwas anderem. Wenn du dich dann beruhigt hast kannste da weiter machen.
Offensichtlich akzeptiert der SQL-Server keine Verbindungen. Also mal schauen ob man mit der Mgmt-Konsole drauf kommt und wie der Server konfiguriert ist.

@CompilerSaysNo: Wenn Du viel Zeit hast kannst du dir mal das OO-Buch anschauen welches hier unter Ressourcen verlinkt ist. Der Link zeigt auf eine lesbare Online-Version. Da wird das m.E. sehr gut erklärt - z.B. unter dynamischer Polymorphie. Musst mal schauen ob dir das liegt.

Die Konvertierung in Zeile 3 kannst du eigentlich nur durch hartes Boxing forcieren.

Wieso? Er hat doch nicht gesagt dass alles in eine Lib gequetscht werden muss, man kann es tun. Wenn du für die einzelnen Schichten jeweils eine Lib verwenden willst dann tu es doch.

Hallo,
normalerweise arbeitet man in WPF mit MVVM, ich zitiere:

Für WPF solltest du jedoch
> verwenden (dabei ist jedoch das Öffnen eines neuen Fensters MVVM-konform etwas komplizierter). Diese Arbeitsweise ist zuerst ziemlich verwirrend, man benötigt einige Zeit um diese zu kapieren. Wenn du sie aber verinnerlicht hast wirdt du merken dass auch relativ komplexe Dinge einfach umsetzbar ist. In deinem Fall würde man damit ein VM-Objekt binden, wenn dann eine Property sich ändert kann man eben eine andere mit einem neuen Wert setzen.

Wenn du MVVM verwendest, also ein ViewModel dahinter gebunden ist kannst du doch ein weiteres Property basteln was die drei Properties vereint und das kannste doch dann an die Visibility binden ...

Warum zoomst du nicht einfach das Datagrid?

<mycontrol.LayoutTransform>
<ScaleTransform ScaleX="{Binding Zoom}" ScaleY="{Binding Zoom}" />
</mycontrol.LayoutTransform>

Das Zoom-property kannst du dann an dein Slider binden. Fertig.

Erzeuge eine Liste von PositionModel ohne den Dispatcher. Das Ding gibst du in die nächsthöhere Schicht raus. Diese baut das in die UI ein.

BTW 2: Wie viele Artikel liest du überhaupt ein? Wenn du bei jedem Objekt eine (eventuelle) Threadsynchronisation durchführst könnte das bei einer großen Anzahl an Objekten sehr teuer werden.

Na lies dir doch mal die Fehlermeldung richtig durch. Läuft das SQL-Statement auch in der Konsole nicht bzw. stimmt die Spaltenanzahl noch?
BTW, gibt es auch ein command.ExecuteReaderAsync() und reader.ReadAsync()? Dann könntest du diese verwenden mit await und würdest das Task.Run nicht benötigen.

Du könntest dich auch mal in das Thema weak events einlesen.

Sorry mein Fehler. Habe WinForms mit WPF verwechselt.

Wenn du das Binding verwendest kannst du mal UpdateSourceTrigger=PropertyChanged im Binding angeben damit die Änderung sofort durchgeschrieben wird. Eine andere Möglichkeit ist die Verwendung einer DataGridTemplateColumn wo du eine eigene Checkbox defibnieren kannst.

Ach so, Header ist nicht im Visual Tree. Dann vllt ein HeaderTemplate?. Antwort auf so

RelativeSource muß natürlich für den Header UND der Visibility verwendet werden.

Hallo,
die Textbox muß Mehrzeilendarstellung unterstützen. Außerdem muß du den neuen Teilstring zu den bestehenden dazupacken also nicht setzen "=" sondern anfügen "+="

Schau mal hier. Die geben den Window-Knoten anders an (blauer Text):

<local:YourBaseClass x:Class="WpfApplication1.MainWindow"

Du kannst übrigens Views auch zusammensetzen, vllt ist das einfacher...

Kannst du die app deinstallieren? "Programme hinzufügen oder entfernen". Wenn du beim publishing angibst "tha application is available online only" sollte das nicht mehr passieren.