Ich hab nur mal ganz grob reingeschaut. Ein nächster logischer Schritt wäre ggf. deine Datenabfragen aus deinem Model rauszuholen und somit zu entkoppeln.

Desweiteren ist es empfehlenswert ein Lightweight ORM wie z.B. "Dapper" ( Hier gibt es auch Extensions für SQLite ) einzusetzen damit du nicht selbst den DataReader nutzen musst um die Daten aus der DB in deine Anwendung zu holen.

Ich glaube wenn du hier ein Attached Property verwendest ist das für dein Szenario der einfachste Weg ohne das Radiobutton Control selbst abzuleiten

https://dailydotnettips.com/how-to-create-an-attached-properties-in-wpf/

Ich würde die empfehlen mit echten Typen bei den Nachrichten zu arbeiten. Im Optimalen Fall hast du für jede Nachricht einen eigenen Typen.

Mit den Magic Strings wirst du dir auf Dauer keinen Gefallen tun.

Wenn deine Main Komponente eine Referenz auf deine Einstellungskomponente hat ( was allerdings nicht danach aussieht ) könntest du es über ein einfaches Event lösen.

Eine andere Variante, die ähnlich funktioniert, wäre ein Messaging System in deiner Anwendung einzusetzen. Dadurch würde deine Einstellungskomponente eine Nachricht über einen MessageBus senden und deine Main Komponente jegliche Nachrichten dieser Art empfangen und behandeln auch ohne eine direkte Referenz auf die Instanz zu haben. Für einen MessageBus gibt es bereits verschiedene Implementierungen am besten einfach mal danach googlen.

Eine dritte Variante wäre glaub ich auch der Einsatz von MediatR. Ich weiß allerdings nicht ob das in deinem Fall mit Raketen auf Spatzen geschossen ist.

EDIT: Falls du MvvmLight einsetzt -> das Framework hat glaube ich bereits einen internen Messagebus
Falls du Prism nutzt -> Auch da gibt es mWn eine integrierte Pipeline

Ich würde vermuten, dass die x:Class="..." Angabe im XAML dieser View ggf. falsch ist aus welchen Gründen auch immer.

Zumindest würde ich zunächst definitiv versuchen auszuschließen, dass es sich um keinen Fehler im Code handelt den Visual Studio hier ignoriert oder nicht beachtet.

Achso da habe ich deine Anforderung wohl missverstanden.

Meines Wissens nach geht das nicht. Zumindest fände ich es besorgniserregend wenn es irgendwie möglich wäre.

Was du aber ggf. tun möchtest ist den ExitCode der Anwendung die du gestartet hast mitbekommen? Du hast nicht wirklich klar gemacht wofür du das ganze tun möchtest.

https://docs.microsoft.com/de-de/dotnet/api/system.diagnostics.process.exitcode?view=netframework-4.7.2

https://docs.microsoft.com/pl-pl/dotnet/api/system.console.read?view=netframework-4.7.2

Wollte dazu auch mal grade meinen Senf ablassen. Habe auch nur ein paar der Meinungen überflogen daher vor ab schon mal sorry wenn ich bereits genannte Dinge nochmal erwähne.

Generell ist meine Meinung zum Thema "Was bringst du als Neuling mit": -> Alles kann nichts muss. Das gilt sowohl für Talent, als auch für gutes logisches Denken. Man kann wie alles im Leben lernen. Bei manchen Dinge braucht es im Zweifel etwas mehr Training, Routine und Zeit. Das ist aber kein Problem solange du Spaß bei der Sache hast. Du lernst dadurch begeistert und dein Gehirn macht viel schneller Fortschritt.

Ich denke das wichtigste ( erneut wie so oft im Leben ) ist Durchhaltevermögen und die richtige Motivation. Mit Motivation meine ich hier aber nicht sich ständig zu überwinden etwas zu lernen sondern zu hinterfragen "Warum mache ich das?". Macht es dir Spaß was du tust? Willst du diese Dinge wirklich lernen und wo willst du genau hin? Diese Frage solltest du dir selbst stellen denn programmieren ist je nach gestecktem Ziel nicht unbedingt eine Sache die man in Monaten auch nicht in 1-2 Jahren lernt, sondern die man sein Leben lang lernen muss.

Viele der User hier sind bereits 5-25 Jahre dabei und ich würde mal behaupten auch die alten Hasen müssen tag täglich ihre Lektion dazu lernen um nicht abgehängt zu werden.

Drum wäre mein einziger Rat an dich: Lass dir nicht von anderen sagen was du brauchst um etwas zu tun. Solange deine Motivation stimmt bei dem was du tust und du ein Ziel vor Augen hast bist du auf dem richtigen Weg, ganz egal wie weit er auch ist.

Ein paar weitere Tipps die dir in der Branche generell helfen:

• Sei kritikfähig
• Sei ebenso selbstkritisch
• Hinterfrage und verstehe. Am Anfang kann man zum spielen sicherlich auch Dinge verwenden die man nicht versteht, jedoch fährt man damit früher oder später gegen eine Wand. Doch auch das gehört zum Lernen dazu.
• Nicht jede Meinung ist richtig, und das gilt auch für deine eigene.

Von den Abhängigkeiten her sollte es besser so aussehen, dass nur eine Klasse die andere kennt aber dann nicht mehr umgekehrt. Sprich -> Keine zirkulären Abhängigkeiten bilden!

Was du suchst ist das Observer Muster -> Observer pattern

Dazu gibt es mittlerweile mehrere verschiedene Umsetzungen.

Eine in C# integrierte Umsetzung des Observer Musters sind Events. https://docs.microsoft.com/de-de/dotnet/standard/events/

Es gibt aber auch noch viele andere Umsetzungen z.B. mit Reactive Extensions ->
http://reactivex.io/

Wenn du dir IndexOf('-') & die Length in Zwischenvariablen holst und debuggst müsstest du deinen Fehler sehr schnell finden 😃

Es gibt noch die Variante mit String.Split() , damit machst du dir das Leben in diesem Fall wohl etwas leichter 😃

https://msdn.microsoft.com/de-de/library/tabh47cf(v=vs.110).aspx

Und gilt das jetzt für Windows Forms oder WPF ?

Ich vermute mal er will die PropertyImplementierung mit new überschreiben.

Eine hervorragende Idee.

wenn ich vom Code aus etwas im ViewModel setze wird irgendwie kein PropertyChanged Event ausgelöst, er springt irgendwie gar nicht erst in den Set Bereich

Vom Code aus wo? Deine Formulierung ist hier nicht genau genug.

• Welche Aktion führst du in der UI aus?
• Welcher Methodenaufruf folgt daraus?
• Was wird nicht ausgeführt, was du aber erwartest?
• Bis wohin konntest du deine Aktion im Code durch debuggen nachvollziehen, und ab wo nicht mehr?

Bitte gib keine Antwort bis du nicht auf jede der Fragen eine Antwort hast.

Wäre schon gut wenn du es selbst löst.

https://stackoverflow.com/questions/9881790/how-to-design-viewmodel

Das sind echt absolute Basics der Programmierung zu verstehen was ein Wrapper ist oder wie man LINQ verwendet wenn man es verwenden möchte. Einfach drauf los programmieren funktioniert bis zu einem gewissen Grad aber irgendwann muss man doch etwas mehr darüber lesen und verstehen was man da eigentlich macht.

Mehr kann ich dir da jetzt auch nicht an die Hand geben. In dem Link ist in ähnlicher Weise erklärt was du tun müsstest.

Versuch dich ein bisschen in unsere Lage zu versetzen wenn du eine Frage stellst 😃

Vita34.Data.VitaLab.VitaLab3.Liste.Liste.Get.GetViewExtraroehrchen(...) 

Wir können nicht verstehen was da passiert. Offensichtlich kommt da eine ObservableCollection zurück. Aber was in dieser Methode passiert und wie deine Entities in diese ObservableCollection gelangen sehen wir nicht. Dort ist aber scheinbar ein möglicher Platz für dein Wrapping.

Also ich packe meine Entities in ein extra ViewModel und befülle meine ObservableCollection dann mit dem ViewModel oder wie?

Jede deiner Entities ist ein eigenes ViewModel. Und ja deine ObservableColleciton ist dann eine Auflistung dieser ViewModels.

Mir scheint auch, dass dir sehr viele Grundlagen zu WPF, XAML und Databinding fehlen. Niemand setzt voraus, dass du das schon alles weißt wenn du hier eine Frage stellst aber zu sehr vielen Dingen ( grade zu Grundlagen ) findet man mit Google auch selbst schnell eine Antwort.

https://wpftution.blogspot.com/2012/05/mvvm-sample-using-datagrid-control-in.html

Und in was oder wie konvertiere ich ein DBSet?

Das machst du doch schon. In deinem Code oben scheinst du ja eine ObservableCollection zu verwenden. D.h. nach dem Holen von Daten bist du ja gar nicht mehr von deinem DBSet abhängig.

Statt halt einfach die Entities in die Collection zu packen wrapst du sie halt vorher in einem ViewModel.

Technisch bemerkt dein RadGridView eigentlich nichts sondern die WPF Engine sorgt bei dafür, dass Objekte die INotifyPropertyChanged implementieren, auch in der UI aktualisiert werden wenn das Binding stimmt.

Anhand deines Snippets sieht man halt recht wenig was du vor hast und wie bestimmte Dinge bei dir momentan umgesetzt sind. z.b. hab ich keine Ahnung wie du momentan überhaupt Daten bis zu deiner UI bringst.

Sprich: Ja wir müssen hier sehr viel Vermuten weil wir nicht an deinem Projekt beteiligt sind und nicht in deinen Kopf schauen können 😃. Viele Probleme du grade hast hatten wir auch schon 100x und haben gewisse Standardlösungen parat. Dir sollte aber klar sein, dass wir hier nur gewisse Lösungsansätze geben können und du es ansonsten schon selbst schaffen musst die Ansätze in die Tat umzusetzen.

Was du da machst ist halt keine Lösung deines eigentlichen Problems sondern ein kostenintensiver workaround.

Was wir meinen ist z.B. folgendes:

public class MyViewModelForGrid : INotifyPropertyChanged
{
      public MyViewModelForGrid( MyEntity entityToWrap )
      {
		 this._entityToWrap = entityToWrap;
      }
	  
	  public string MyProperty
	  {
		get { return _entityToWrap.Property; }
		set 
		{ 
			this._entityToWrap.Property = value;
			this.RaisePropertyChanged();
		}
	  }
}

Ist jetzt nur schnell im Editor zusammengeschrieben und daher unvollständig. Aber die Idee ist hoffentlich ersichtlich.

Dann bau ein Objekt ( ViewModel ) welches du stattdessen in deinem RadGridView darstellst. Entities sind nicht dazu gedacht diese direkt in der UI anzuzeigen. Im Zweifelsfall wrap deine Entities zumindest in deinen ViewModels

https://stackoverflow.com/questions/541420/how-to-i-access-an-attached-property-in-code-behind

Wir machen das genauso. Nutzen auch GIT, MSSQL, haben viele Branches und viele interdisziplinäre Teams.

Suchen da auch schon länger nach einer alternativen Methode. Ideen dazu würden mich auch interessieren.

Moment ... arbeiten wir in derselben Firma 😄 ?

Ich liebe es an Foren, dass als Antwort immer auf die Standardsuchmaschine google verwiesen wird, das zeugt von hoher Intelligenz.

Vielleicht fällt es dir einfacher folgendes nachzuvollziehen:

Deine Frage lesen X Leute die sich nach deiner Meinung die Mühe machen sollten, dir zu erklären, was du überall im Internet auch selbst recherchieren könntest. Somit kommt dabei ein nicht unerheblicher Aufwand zustande.

Klar ist das für dich ein Benefit, weil du ja diese Recherche Zeit einsparst. Auf der anderen Seite kann man Argumentieren, dass es ziemlich egoistisch von dir ist.

In diesem Forum geht es um die Lösung von Problemen die nicht offensichtlich sind, oder um Meinungen zu bestimmten Themen einzuholen. Es geht hier aber nicht darum, dass andere deine Arbeit machen.

[Hinweis] Wie poste ich richtig?

Ich glaub es ist einfacher, wenn du eine Schaltfläche "Wiederherstellen (=Normal)" hättest die nur sichtbar wird wenn dein Fenster Maximiert ist. Anders herum wenn deine Anwendung nicht maximiert ist, ist an derselben Stelle der Maximize Button sichtbar.

Das macht eigentlich jede Anwendung so.

Warum gehst du nicht im XAML einfach direkt auf die jeweilige Ressourcendatei? Was möchtest du mit der Extension erreichen?

Falls du zur Anwendungslaufzeit die Sprache ändern können möchtest ohne neu zu starten hilft dir dieser Artikel ggf. weiter -> http://www.grumpydev.com/2009/09/08/localising-wpf-applications-using-resx-files-and-standard-data-binding-without-a-markupextension/

Wenn das keine Anforderung sein sollte würde ich an deiner Stelle einfach hart auf die ResX Datei gehen.

Nein, das heisst das er welche haben soll oder müsste. In private Hände (oder die der Privatwirtschaft) dürfen diese Daten IMO niemals gelangen. Solange man darauf als Staat angewiesen ist, bedeutet das für mich pauschal, dass man tunlichst die Finger davon lassen sollte. Private Unternehmen haben nämlich im Gegensatz zum Staat weder die Aufgabe Freiheit noch Sichheit zu gewährleisten, und somit in meinen Augen keinerlei Berechtigung auch nur entfernt in die Nähe solcher Daten zu gelangen.

Gilt dasselbe Prinzip in deinen Augen auch für Banken? Die Regeln von Konzernen können ja unter anderem durch den Staat vorgegeben/beeinflusst werden.

Also ich bin jetzt nicht ganz sicher ob deine Frage noch offen ist oder nicht, aber ich kann ja einfach mal von meinen Erfahrungen zu deiner Frage was sagen.

Kurz ausgeholt:

In der Welt der Softwareentwicklung gibt es Meinungen in sehr großem Maße. Viele Ideen die sich in sehr kurzem Zeitraum entwickeln. Eine Meinung und Idee von vor 3 Wochen ist morgen schon wieder anders. Du kennst das vielleicht selbst. Den Code von vor 3 Monaten würdest du selbst nicht mehr so schreiben.

Ich denke das geht fast jedem so, auch Buchautoren, Speakern und Frameworkentwicklern. Ist ja auch klar wir entwickeln uns alle durch unsere Arbeit weiter.

Warum sage ich das? Ich habe das Gefühl du suchst nach einer allumfassenden richtigen Antwort die es nicht gibt. Du willst Erfahrungen und Meinungen hören die unterschiedlich sind. Es gibt einfache schnelle Lösungen und es gibt aufwändige "saubere" Lösungen. Was davon letztlich für dich wichtig ist können wir aber nicht beurteilen. Versuch dich ein wenig davon zu lösen, dass dein Code in 6 Monaten noch "toll" ist. Code ist wie reales Produkt mit einer gewissen Lebenszeit versehen.

Zu deinem Code:

1.) Ich würde ein UserControl verwenden. ViewModel als DataContext. UserControl selbst steuert nur UI Interaktion, ggf. mit Hilfe von Behaviors um spezielle Anforderungen umzusetzen.

2.) Das UserControl würde ich in eine Library packen sofern es von mehreren anderen Libraries verwendet wird. Ansonsten würde ich einen Namespace im selben Projekt erstellen.

3.) Das ViewModel hält für mich immer nur einen UI State. Es tut selber eigentlich nichts sondern delegiert lediglich aufrufe an ein Model.

4.) Mein Model gestalte ich möglich so, dass es mit UI NICHTS mehr zu tun hat und optimalerweise sogar in einer UI unabhängigen Library liegt. So lässt sich Businesscode leichter extrahieren.

5.) Static ViewModels würde ich persönlich nicht machen sondern vielmehr meiner Applikation ( diese ist ja bereits static ) einen ViewModelLocator ( muss kein DI Container sein ) geben der mir ViewModels bereitstellt. Ob dieser dann immer diesselbe Instanz gibt oder jedes Mal eine neue hängt von deinem Use Case ab ( z.B. soll beim Aufrufen der View alles so sein wie zuvor ).

Ich hoffe ich habe jetzt nicht völlig am Thema vorbei geredet.

Viel Erfolg weiterhin.

[FAQ] NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt

OK ich sehe deine Anmerkungen ein.

Leider ist ein solches UI Test Szenario für uns noch relativ weit entfernt. Unsere Anwendung besteht noch aus einer C++ Shell in der lediglich C# Code aufgerufen wird. Das wird sich zwar künftig ändern aber bis es soweit ist wäre eine Zwischenlösung schon nett.

Ich würde daher ( auch aus Interesse ) die eigentlich Frage offen halten wollen. Dein Ansatz scheint schon die gängigste und flexibelste Lösung zu sein, leider aber für mich momentan nicht umsetzbar.

Daher weiterhin: Kennt jemand eine Roslyn Regel mit der man eine Solution auf fehlende StaticResources überprüfen kann bzw. hat sowas jemand schon mal gemacht?

Ich halte UI Tests für notwendig um zu sehen ob die UI so funktioniert / aussieht wie es sein soll.

Was in diesem Fall aber passiert ist ein Crash wenn eine StaticResource fehlt. Warum muss das im UI Testing erst passiert wenn man das schon viel früher feststellen kann?

Mmn. sollte man jeglichen Code der als fehlerhaft identifiziert werden kann schon beim MergeRequest abgelehnt werden.

Ich denke zwar, dass du recht hast bzgl. automatisierter UI Tests aber dennoch halte ich meine Frage für berechtigt, lösbar und auch "besser" da sie schon Probleme vor dem UI Test abfangen kann. ( Zumindest in diesem Fall mit statischen Resourcen)

Insbesondere als Entwickler find ich es angenehm schon früh zu sehen wenn ich was falsch gemacht hab. Auf einen UI Test zu warten kann bedeuten, dass andere Entwickler bereits durch meinen falschen Checkin blockiert sind.

UI Testing ist halt aufwändig und bei uns noch nicht automatisiert.

Ich denke das sich solche Fehler auch schon vor der Laufzeitprüfung testen lassen, warum also drauf verzichten?

Außerdem wäre es halt nett wenn man "fehlerhaften" Code schon beim Buildprozess abfangen könnte. Wenn der Fehler erstmal in der Codebase ist braucht man wieder nen kompletten Durchlauf um den Fehler zu korrigieren. Nach meinem Verständnis von Resourcen lässt sích das eigentlich schon vorher vermeiden und erspart vielen Zeit und Arbeit

Hallo zusammen,

bei uns in der Firma arbeiten viele Leute gleichzeitig an einer größeren Lösung. Es kann daher vorkommen, dass StaticRessourcen sich ändern die andere nicht mitbekommen und somit die Namen nicht mehr stimmen.

Blöd ist jetzt, dass das erst zur Laufzeit auffällt.

Da es über MSBuild nicht möglich zu sein scheint das abzufangen, dachte ich daran das ganze über NDepend oder eine Roslyn Regel die eine Warning erzeugt abzufangen.

Frage wäre jetzt: Hat sowas jemand von euch vielleicht schon mal gemacht? Meine Suchergebnisse haben da leider gar nichts ausgespuckt.

Lg

Der Nutzer soll vorher ein kleines Programm runterladen, welches im Hintergrund läuft und gewisse Befehle abarbeiten soll und am Ende auch die Programme runterladen und starten soll.

Mach es doch gleich so, dass dieses Programm dein eigentlicher Auswahlclient ist und dieser bei "webbasierten programmen" die entsprechende URL im Browser aufruft und im C# Fall das lokal installierte programm startet bzw. zuvor runterläd.

Erscheint mir irgendwie einfacher und wäre diesselbe Vorgehensweise wie bei Steam.

Rechtklick auf deine TestMethode -> Test debuggen

Dadurch landest du an der Stelle wo der Fehler auftritt. Damit sollten du einen solchen Fehler schnell finden und beheben können wenn du deine Strukturen entsprechend umstellst.

Hinweis : Es ist leichter Unittests zu schreiben wenn du weniger "StateCode" schreibst. D.h. häufiger mit Parametern einer Methode arbeitest statt deine Objekte irgendwo in lokale Felder zu werfen und zu einem X-beliebigen Zeitpunkt wieder darauf zugreifst und hoffst das grade das richtige drinsteckt.

Stichwort "Nebenwirkungen"

Das ist genau für solche reaktiven Anforderungen gedacht - und sollte eigentlich in keiner UI Applikation mehr fehlen.

Hey Abt. Kannst du das etwas weiter ausführen? Also insbesondere warum es deiner Meinung nach in keiner UI Anwendung mehr fehlen sollte? Bei uns in der Firma steht die Frage momentan im Raum -> RX Ja/Nein . Was für Richtlinien sollten wir da mitgeben? Bei uns arbeiten > 18 Entwickler und ein solches Framework gibt viele Möglichkeiten sich ins Knie zu schießen.

Ich weiß es gibt da viele Quellen zu im Netz aber mich würden da deine bisherigen praktischen Erfahrungen interessieren.

Fang das Klickevent der Textbox ab. Alles andere ist Handarbeit ( analyse wo der cursor steht, analyse was der rest des wortes ist, Behandlung )

Damit meinte ich private eigene Projekte. In der Firma gehe ich davon aus das ich nie der einzige bin der es liest da bei uns jede Zeile Code durch Codereviews geht.

War missverständlich ausgedrückt 😃

Kommt mMn. immer auf diejenigen an die es später lesen sollen. Ich dokumentiere keinen Code von dem ich weiß, dass nur ich ihn jemals wieder sehen werde. Beim umgekehrten Fall gehe ich davon aus, dass es der unerfahrendste Entwickler im Umfeld verstehen soll. Da sind Kommentare nicht immer vermeidbar. Informationen in Kommentaren müssen halt auf den Punkt gebracht werden.

Passende Bezeichnungen für Identifier sind extrem wichtig aber auch nicht immer so möglich, dass komplexere Zusammenhänge verständlich sind.

API's sollten meiner Meinung nach gut dokumentiert sein. Das ist Code den andere nutzen und verstehen müssen. Sowas dokumentiere ich gut und gerne. Alles weitere ist Geldverschwendung.

Wie willst du gewährleisten das auch die dümmsten Entwickler genau verstehen was du dir überlegt hast? -> Es geht nicht.

"Und ja, Parallelität und Access fliegt Dir um die Ohren."

Kann man das noch etwas spezifizieren? IdR fliegt Code ja nirgendwo hin 😃

Wenn ich das richtig verstehe will er die Access Datei auslesen. Von Schreiben war ja nicht die Rede. Das das Schreiben problematisch wird verstehe ich.

Warum ist der reine Lesevorgang ebenfalls gefährlich? Wird die Datei auch bei lesenden Zugriffen gesperrt? Gibt es hier bedenken bzgl. Performanceverlust statt Gewinn?

Wäre super wenn das mal jemand auflisten kann.

Achso ich hatte es schon so verstanden, dass du für jedes ViewModel ein eigenes DataTemplate hinterlegt hattest.

Aber gut wenn es gelöst ist 😃

Verwendest du irgendwo einen ContentPresenter? Ich hatte glaub ich schon mal so ein ähnliches Problem wo die UI sich nicht an einen geänderten DataContext angepasst hat und da lag es daran, dass ich statt einem ContentControl einen ContentPresenter verwendet hab

Erster Gedanke:

Schreib ein Behavior welches du an das TransitioningContentControl packst und reagier da drin auf das DataContext Changed des Controls. Wie das dann für das Control selbst funktioniert müsstest du in der API von MahApps schauen.

Ich glaube es handelt sich hierbei nicht um ein .NET / WPF Problem sondern um ein allgemeines Windows Problem. Zumindest hab ich dasselbe Problem wenn ich die Windows Systemeigenschaften aufrufe.

Habe das Problem auch nur auf einem "nicht primär Ausgabebildschirm"

Mir ist aber auch nicht bekannt woher das Problem kommt. Hab es aber mit vielen Windows Fenstern

https://stackoverflow.com/questions/5728599/when-would-using-assembly-loadfrom-or-assembly-loadfile-be-appropriate

Da sollte eigentlich alles zu dem Thema stehen was du brauchst.

"LoadFile() doesn’t bind through Fusion at all – the loader just goes ahead and loads exactly* what the caller requested. It doesn’t use either the Load or the LoadFrom context."

e.Column sollte eigentlich sowas wie ColumnIndex und evtl. auch RowIndex haben. Über den Rowindex solltest du dann aus dem Grid die gewünschte Zeile bekommen.

Oder verstehe ich das Problem hier falsch?

Hab eine minute gegoogled

https://github.com/noxad/windows-toast-notifications

Wieso jetzt noch auf Blend-Zeug setzen? Oder ist das davon abgekapselt?){gray}

Zu Expression Blend:
Expression Blend als Anwendung existiert jetzt als Blend Suite for Visual Studio und wird seit 2015 ( glaub ich ) direkt mit ausgeliefert.

Zum SDK:
Im WPF Bereich wird sie mittlerweile in jedem großen Framework eingesetzt. Das SDK ist losgelöst vom eigentlichen .NET WPF Framework und dient mehr als Erweiterung.

Zur Umsetzung:
Sieht gut aus. Würde ich glaub ich genauso umsetzen und trifft das wovon ich gesprochen hatte. Vorteil hier : Das Behavior lässt sich an beliebige ListView's anhängen. Zugegben das geht mit Attached Properties auch. Vorteil ist an dieser Umsetzung jedoch, dass man Zugriff auf die konkreten ListView Event's hat und diese behandeln kann. In einem statischen Kontext ist das nicht möglich / schwierig.

Nachteil an dieser Lösung. Es gibt UI Elemente die sich vom Visual Tree lösen und dadurch das Detach aufgerufen wird ( z.b. bei Popup Elementen / Flyouts ). Hier muss meine eine Mechanik einbauen die ein "Re Attach" ermöglich sobald die UI Elemente erneut an den Visual Tree angehangen werden.

Ja vielleicht besteht dort auch der Konflikt. Mir waren sie bisher immer nur als Attached Properties geläufig und nie als Attached Behaviors.

Das Behaviors ausschließlich über die Behaviorcollection angehangen werden bezog sich auf eben solche Blend Behaviors. Denke wer sie noch nicht kennt sollte sie doch mal betrachten auch wenn sie Teil eines externen SDK's sind. Man kann damit viele Problem grade im Bezug auf Memory leaks in WPF lösen.

Aber back 2 topic.

In meinen Augen ist das was ihr das macht ein Attached Property. Sieht man am einfachsten daran, dass ihr das bestehende Control um ein Property erweitert welches dann dazu führt, dass ein Verhalten ausgelöst wird. Außerdem ist alles in der Klasse auf statischer Ebene implementiert. Zugriff auf eine bestimmte Klasseninstanz ist praktisch nicht vorhanden. Behaviors werden aber ausschließlich über die System.Interactivity.BehaviorCollection an ein Control angehangen.

Ich hab jetzt grade leider nicht so die Zeit euer Beispiel nach meiner Behavior Interpretation umzusetzen aber vielleicht hänge ich das nächste Woche mal hier an.

Hab hier das noch dazu gefunden auch wenn es schon was älter ist :

http://briannoyesblog.azurewebsites.net/2012/12/20/attached-behaviors-vs-attached-properties-vs-blend-behaviors/

PS : Nicht falsch verstehen, ich will damit nicht sagen das das eine schlechter / besser als das andere ist. Aber genau wie der Artikel es bestätigt gibt es keinen namentlichen Konsens darüber was ein Behavior eigentlich ist.

Die System.Interactivity Dll bekommst du in der Regel über den NuGet Package Manager von Visual Studio. Einfach mal nach Suchen.

Behaviors sind nach meinem Bauchgefühl her wirklich nicht so verbreitet. Warum weiß ich leider nicht. Im Grund genommen sind sie den Attached Properties sehr ähnlich, funktionieren aber auf Instanzebene und nicht auf statischer Klassenerweiterungsebene.

Im Netz findet man einiges dazu. In Büchern ist es meist nur angerissen oder in Form von attached Properties erwähnt.

Du könntest hier mit einem DataTemplate arbeiten und in dein an dein TabControl eine Liste von ViewModels binden. Jedes der ViewModels stellt dann in sich über ein DataTemplate eine von dir definierte Listenansicht dar und enthält auch die Liste von Items die im DataTemplate an deine visuelle Liste gebunden wird.

Den Headernamen des Tabs kannst du ebenfalls aus dem ViewModel auslesen.

Hier ein snippet

 <TabControl
        ItemsSource="{Binding DetailsViewModels, Mode=OneWay}">
        <TabControl.ItemTemplate>
            <DataTemplate DataType="{x:Type local:DetailViewModel}">
                <ListBox ItemsSource="{Binding Layouts}" />
            </DataTemplate>
        </TabControl.ItemTemplate>
        <TabControl.ItemContainerStyle>
            <Style TargetType="TabItem">
                <Setter Property="Header" Value="{Binding DisplayTitle}" />
            </Style>
        </TabControl.ItemContainerStyle>
    </TabControl>

Falls du noch weitere Tabs hast in denen anderes Zeug dargestellt werden muss so müsstest du einen DataTemplateSelector verwenden und pro unterschiedlichem ViewModelTyp dann ein eigenes DataTemplate schreiben.