ah, danke.

kann ich aber aufgrund jedes der Requirements nicht öffnen:

Visual Studio 2015 Update 1  
Microsoft Band 2 SDK (integrated as NuGet Package)  
Microsoft Band (1 or 2) or FakeBand

ich bin iwie zu dumm zum Downloaden - gibts da einen Sample-Solution-Zip?

Ich sehe da nur im Browser präsentiertes c#, müsste ich auskopieren, und überhaupt erst ein Sample-Projekt drumrum erstellen, was den Fehler reproduziert.

nanU?
Ich hätte diese 2 Punkte für die kernsache gehalten:

1. Zu diskutieren, wie die best practice sei, und da hab ich vermutet, dass deine Lösung, so, wie sie in post#1 steht, unnötig viel Speicher belegt.
2. Auch die Gestaltung, sodass auch Anfänger von der FAQ profitieren.

Was wäre in deinen Augen die Kernsache?

(Ich trau mich kaum, es abzuschicken, denn zu diskutieren, was die Kernsache ist, ist ganz sicher nicht die Kernsache.
Meinetwegen kannste meine Posts auch rauslöschen, wenn das hilft, den Thread wieder mehr @Topic zu bringen.

(Was ich noch nur ungern zugebe: )
Ausserdem könnte ich tatsächlich kein DI umsetzen. Ich weiß zwar im groben, was das ist, aber alle meine Versuche einer praktischen Test-Umsetzung führten zu mehr Uständlichkeit statt zu weniger.
Wäre jetzt ein neuer Anlauf, wenn mir hier jetzt was praktikables präsentiert würde.

(Auch hierfür fürchte ich, harsche Ablehnung zu erfahren: )
Zur Gestaltung hätte ich noch die Bitte um ein lauffähiges Code-Sample. Ist für mich ein "Tutorial-Prinzip": Solange ich die Tutorial-Aussage nicht in Code umgesetzt auf meiner Platte habe, solange ist das Tut nichts als unbewiesene Worte.
)(Klammer zu 😉 )

hmm - ich dachte, das sei hier für eine FAQ vorgesehen, also gedacht als Hilfe für weniger fortgeschrittene.
Aber ob die mit Fach-Chinesisch wie "Wrap Deine Factory mit einem IMyFactoryWrapper Service, lass eine einzige Instanz davon existieren, injecte sie via DI und jut is." was anzufangen wissen? 🤔

Es ist - nach bestem Wissen und Gewissen - genau wie bei dir aufgebaut.
Deshalb ja meine Bitte, ob du das Werk mal downloaden kannst und ausprobieren.

Aber vlt. frag ich besser woanders

ich verstehe nicht, oder du 😉

Ich meine, jede Viewmodel-Instanz erhält ein neues (new) TaskFactory-Objekt. Ich weiß nicht, wie fett diese Factories sind, und obs was ausmacht, wenn man 10000 Datensätze lädt, dass damit dann auch 10000 TaskFactory-Objekte erstellt sind.

<Button Command="New" ToolTip="{x:Static resx:Strings.TbTooltipNew}">

x:Static kommt mir komisch vor.
Normal greift man doch übers StaticResource - Schlüsselwort auf Resourcen zu.

ist das nicht ein bischen böse zu den Resourcen, wenn jedes Viewmodel seine eigene TaskFactory mit sich rumschleppt?

sorry - ich kann iwie nur eine Datei pro post anhängen

Wie gesagt - laufen tuts - kannst du vlt. mal probieren?

höchst eigenartig.
Also anbei mal meine Sources - magst du mal ausprobieren?

Hier MainViewmodel:

   class MainViewModel : NotifyPropertyChanged {

      public string AText { get { return _AText; } set { ChangePropIfDifferent(value, ref _AText); } }
      private string _AText = "AText";

      public CommandMap Commands { get { return _Commands; } }
      private CommandMap _Commands;

      public void AnAction(object o) {
         AText += "\nClick!";
      }
      public MainViewModel() {
         _Commands = new CommandMap();
         _Commands.AddCommand("AnAction", AnAction, o => true);
      }
   }

Und ein Bild des Xaml-Editor-Fails:

Bei mir funktioniert die CommandMap nicht richtig.
Wenn ich an eine CommandMap binde, dann geht die Xaml-Vorschau flöten, und erzählt iwas von einer NullReference.

Die Laufzeit hingegen funktioniert.

Verhält sich das bei dir/euch anders?

Das Problem: ich komme nicht an den durch den User geänderten Wert der TextBoxen. Ich nehme an, du willst beim Button-Click da drankommen.
Ja, da ist dein Command nicht gut für geeignet. Nimm ein RelayCommand, (oder "DelegateCommand", wies oft auch heißt), und löse damit die UpdateMethode genau in dem Viewmodel aus, wo du updaten willst.
Oder besser, du löst es im übergeordneten Viewmodel aus, und übergibst das zu updatende Viewmodel als CommandParameter.

BeispielCode zur RelayCommand-Usage (beide Varianten) gibts hier: https://www.vb-paradise.de/index.php/Thread/115475-MVVM-Anwendungs-Struktur/?postID=1005812

Das lausige mit den RelayCommand ist, dasses im Framework nicht enthalten ist.
Also kopierste dir entweder meine Version, oder bindest irgendein Wpf-Toolkit ein - Delegate-/Relay-Command haben alle.

Hi!

Wenn wolle, kannst du auch mal das hier angugge:
https://www.vb-paradise.de/index.php/Thread/102270-Kein-Pong-Erstaunliches-mit-ItemsControl-Itemspanel/?postID=875309

Aber es ist kein lupenreines MVVM, weil bei dragging-Geschichten wird MVVM in einer oder anderer Hinsicht etwas unhandlich.

Und ich dragge da auch nicht, sondern bewege Moveables per Tastatur.

vlt. hat ContentControl ja eine ContentTemplate - Eigenschaft?
(ih weisses nicht, guck halt mal)

Ansonsten legt man DataTemplates gerne in Resourcen übergeordneter Elemente, mit einem Resourcekey.
Will man das Template dann auf ein bestimmtes Control anwenden, dann kann man ihm per StaticResource resourceKey das Template der Wahl zuweisen.

Das scheinen mir 2 recht anspruchsvollte Fragen in einer - könnemer und nicht drauf konzentrieren, erstmal nur für einen Datentyp den User das Template wählen zu lassen?

Und zunächstmal konzeptionell: Wie willst du dem User denn die Auswahlmöglichkeiten präsentieren?

@p!lle: Ich denke, son krypto-post bringt nix, ausser dass der TE sich dumm fühlt.

Ansonsten stimmt schon, dort wird ein AulaMedia erstellt, was ja ein Form ist, aber das Form wird nirgends angezeigt - seine .Show()-Methode nirgends aufgerufen.
Also sieht man auch nix, wenn man einen Button darauf neu betextet.

@TE: Ich denke, du musst einige Grundlagen dir erarbeiten, etwa die Bedeutung des Schlüsselwortes new, und das dahinter stehende OOP-Konzept, dass es normalerweise von jeder Klasse beliebig viele verschiedene Objekte geben kann.

Ohne derlei Grundlagen binnich pessimistisch, ob das Form2Form - Tut dir was bringt, oder genügend bringt, dass du das Prob gelöst kriegst.

ok, aber ganz generell kanns ja eiglich nicht anders sein, als das du den falschen Button um-beschriftest.

ob du nun ein Form geladen hast, aber nciht angezeigt oder was auch immer.

oder der button ist aus sonst einem Grund nicht sichtbar.

oder button1 ist überhaupt kein button.

mach dich drauf gefasst: es wird iwas dummes sein. 😉

klingt alles ganz i.o., nur stutzig macht mich das this.Close();.

evtl. wird da ein anderer Button um-beschriftet, aber das siehst du nicht, weils Form schon closed ist.

lass doch mal das this.Close weg, und guck, ob sich iwas verdächtiges zeigt.

jo, klappt alles bestens:

      public frmDataRowLoad() {
         InitializeComponent();
         GenerateToLoLoadData();
         loadToolStripMenuItem_Click(null, null);
      }
      private void GenerateToLoLoadData() {
         entityDts2.ReadXml(_Data.FullName);
         var tb2 = entityDts2.SomeData;
         tb2[0].Name = "Halo Walt";
         tb2[2].ID = 5;
         tb2[1].Delete();
      }
      private void LoadDataRowTest_Click(object sender, EventArgs e) {
         DataTable tbl1 = entityDts.SomeData;
         foreach (DataRow rw in entityDts2.SomeData.Rows) {
            var objects = rw.ItemArray;
            tbl1.LoadDataRow(objects, false);
         }
         var rws = entityDts.SomeData.ToList(rw => new { rw.ID, rw.Name, rw.RowState });
         0.Dbg();
      }

Es sind zwar typDataTables, aber sie werden ausschliesslich über die untypisierte Basisklasse angesprochen.
Und objects ist eh ein Object-Array und weiß nix von Datatables.

LoadDataRow verhält sich wie es soll: Die erste Row wird eingepflegt, denn deren ID gibts schon. Und die 2. Row wird geadded, den die ID 5 gibts zunächstmal noch nicht

Kannste sogar besonders nett angugge, wennde Haltepunkt auf die Zeile 0.Dbg(); setzst, und dann die rws im Lokalfenster untersuchst.

Daraus folgt:
Dein Ansatz ist völlig richtig, und beim Problem handelt es sich um was anderes.
Inkompatible Daten, iwie doch falsch konfigurierter Primkey, TryCatchens, die Fehlermeldungen verschlucken, was weiß ich.

nunja, deine Kenntnisse vom typDataset sind nicht ganz vollständig und nicht ganz richtig.
Da könnte ich jetzt eine längere Richtigstellung versuchen, aber kann ich auch lassen, ich denke nicht, dass du es daraufhin einmal typisiert probieren wollen würdest.

Aber halt das mit den Gestaltungsmöglichkeiten, das interessiert mich halt.
Also vermutlich (naja, ist eiglich die logische Konsequenz deiner Vorgehensweise) hast du keine Vorstellung davon, welche Menge an Gestaltung man bei typisiertem Vorgehen bereits im FormDesigner abhandeln kann - ohne Code, aber dafür mit WhatYouSeeIsWhatYouGet.
Daher meine wiederholte Bitte, wirf doch mal einen Blick drauf, vor allem auf die Samples zur Laufzeit.
Und meine Frage schließt sich an, ob dir das ebenso leicht fiele, so etwas zu konstruieren.
Also so Views, wo man Kategorien wählt, und alle Artikel angezeigt bekommt, oder Bestellungen, die ihre Beträge selbst zusammenrechnen, oder auch das advanced Bestellformular, wo man in den Artikeln browsen kann, und einfach zu jedem hinschreibt, wieviel man möchte.
Diese Gestalterei kann man kaum coden nennen, bzw. nur im weiteren Sinne, denn der Code, den ich zu schreiben habe ist extrem wenig, und konzentriert sich auf wirklich wesentliches.

Im Gegenzug mach ich dann jetzt auch mal Versuche mit diesem lausigen LoadDataRow - also ich täte ja denken, das muss hinhauen.
Ich hab halt deine Db nicht, aber ich kanns ja auch mit meine DataTables (typisierte übrigens) testen.
Am Rowstate werde ich ja ablesen können, ob und wie ein DataAdapter die Rows mit der Db synchronisieren würde.

Tja, warum weiß ich auch nicht.
Ich finds eiglich schon erstaunlich, dass eine DataTable überhaupt so viel Information über die Db-Tabelle hat, keine Ahnung, warum nun den Primkey nicht.
Aber irgendwo muss ja eine "InformationsGrenze" sein, sonst könnte man ja auch erwarten, eine Tabelle solle selbst wissen, wie und mit welchen anderen Tabellen sie verknüpft ist (und das geht nu wirklich über die Zuständigkeit hinaus).
egal.

Also du lehnst typisierte Datasets ab, weil "undurchschaubar"?
Ich finde die im Gegenteil überaus durchschaubar.
Und du gibst ja auch einen immensen Haufen an Gestaltungsmöglichkeiten auf - hast du mal vom Tut die Sample-Application gedownloaded?
Und das Sample im letzten Artikel der Serie ist noch ein Stück weiter entwickelt (und deshalb auf zusätzliche aufwändige selbstgebastelte Infrastruktur angewiesen, was aber eiglich nicht zählt, denn die Infrastruktur ist ja nur einmal gecodet und fertig).

Jdfs. grausts mich regelrecht, wenn ich mir vorstelle, all den Kram, der in diesen Anwendungen in Designern gestaltet ist und typsicher programmiert - also wenn ich das alles hätte mit untypisierten DataTables versuchen müssen.

Aber du sagst, du seist imstande, sowas auch untypisiert hinzuhauen, und würde dir sogar leichter fallen?

jepp - ich rede von Dataset, und nicht von DataTable. Und zwar von typisiertem Dataset, dassis nochmal was anderes, nämlich ein System typisierter Erben des untypisierten Datasets.
Jo, in einem Dataset sind mehrere DataTables drinne, ebenso wie ja auch in einer Datenbank mehrere Tabellen enthalten sind.

Und wie man in einer Datenbank Beziehungen zwischen Tabellen definiert, so definiert man in einem Dataset auch DataRelations zwischen DataTables.

Kann man natürlich auch lassen, aber wie gesagt: Auch nur minder-komplexe Datenmodelle sind sehr bald nicht mehr zu bewältigen.

Ich lege dir nochmal das verlinkte Tutorial ans Herz, damit du einen Begriff bekommst, wovon ich überhaupt rede.

Und ja: Ein DatagridView kennt die Spalten der DataTable, wenn es an eine DataTable gebunden wird.
Eine DataTable kennt aber nicht die Spalten der Datenbank, jedenfalls nicht, was detailliertere Spalten-Konfigurationen betrifft wie AllowDbNull, PrimKey, ForeignKeyConstraints und dergleichen.
Jedenfalls nicht von selbst.

Edit: sorry, sehe jetzt erst, dass du inzwischen ja etwas unternimmst, um der DataTable einen Primkey anzudrehen.
Hab ich so noch nie gemacht - funzt das? (jo, wird wohl)

ich lass mir meine typDatasets immer von VS-Assistenten generieren, bzw. ich hab mir ein Tool gebastelt, was den Vorgang umdreht: Aus meinem typDataset generiert es die Datenbank.
Das sind meine beiden Vorgehensweisen, und die stellen tatsächlich die notwendige 100% Übereinstimmung der Tabellen sicher.
Und ist halt typisiert - mit den weitreichenden Folgen für die ganze Anwendungs-Entwicklung - gucks dir wirklich mal an.

Doch, das ist genau das Problem.

Offensichtlich hast du den Primkey in der Datenbank festgelegt, aber deine DataTable weiß ja nix davon. Für die DT ist das eine Spalte wie jede andere.

generell täte ich von untypisierten Datasets abraten. Verwende typisierte Datasets oder EntityFramework, aber kein untyp Dataset.

Ein Datenmodell ist normalerweise sehr komplex, da kriegt man einen Vogel, wenn man sowas mit einem untyp Dataset nachbilden will.

Und nachbilden muss mans - so oder so. Sonst passen die DataTables nicht zur Datenbank, und es läuft gar nix bzw. nur Bugs laufen, aber in Massen.

Das ist aber nur das eine. TypDatasets bieten darüberhinaus auch die Möglichkeit der Databinding-getriebenen Oberflächen-Entwicklung - sagt dir das was?

Ansonsten guggemol in
http://www.codeproject.com/Articles/1033145/Databinding-for-Beginners
die Sample-Anwendung, ob du den Eindruck gewinnen kannst, mit Databinding könne man vergleichsweise einfach auch komplexere Oberflächen entwickeln.

Ich empfehle immer, bevor man sich auf Datenbanken stürzt, erstmal zwei andere Dinge zu lernen:

1. Datenmodellierung - denn ein Datenverarbeitungsprogramm scheitert mit Sicherheit, wenn das Datenmodell nichts taugt
2. Databinding.
   Databinding ist eine hochentwickelte Technologie, um Daten zu präsentieren (meint: angucken + bearbeiten + rückspeichern)
   Wenn man beim DB-Zugriff ungeschickt vorgeht - etwa so wie in BerntFfms Tutorial - dann verbaut man sich diese enormen Möglichkeiten von vornherein.

Also zu Datenmodellierung und Databinding habich Tut verzapft - achtung - es sind 3 Artikel, aufeinander aufbauend:
http://www.codeproject.com/Articles/1030969/Relational-Datamodel

Dort wird nur Arbeit mit typisiertem Dataset gezeigt, kein Db-Zugriff.
Weil dem Dataset ists letztlich egal, wie du es befüllst, und da käme nun auch wieder BerndFfms Tutorial ins Spiel, aber entsprechend abgewandelt, um die Databinding-Funktionalität zu erhalten.

Evtl. kannste dir auch alles sparen, und überlegen, deine Infos einfach in eine Log-Datei zu loggen. Das wäre aber sehr lowlevel, und nicht besonders komfortabel zur Weiterverarbeitung.
Und auch beim Loggen sind Prinzipien der Datenmodellierung im weitesten Sinne nützlich, um den Log-Einträgen eine Struktur zu geben, die die Weiterverarbeitung zumindest erleichtert.

zustimm.
List<T> und Array stellen übrigens finxnfertige BinarySearch-Funktionalität bereit, auch Überladungen mit benutzerdefinierten Sortierkriterien.

Ob das optimal ist, ist andere Frage, BinarySearch ist zumindest sehr sehr schnell - afaik kaum noch zu toppen.
Das langsamste dabei ist das Inserten, aber auch das ist bei Array und List<T> hochoptimiert, also "langsam" ist da sehr relativ.

vermutlich letzteres.

Kann man nix zu sagen, denn man sieht ja nicht, wie du den Primkey in der DataTable festlegst.

Äh - nirgends.

(naja, warn Witz, weiß nur nicht, ob er gut war)

Ich denke aber, wenn dir Databinding noch kein Begriff ist, ists völlig verfrüht, sich mit EF oder sonst irgendeiner Datenbank herumzuärgern.

Das gilt ebenso für den Begriff Datenmodellierung - beides erlernt man besser ohne Datenbank.

Hier hab ich Tut dazu verzapft:
http://www.codeproject.com/Articles/1030969/Relational-Datamodel-for-Beginners
Das sind 3 Artikel: 1) Datenmodellierung 2) Databinding 3) Programmierung am typisierten Dataset.

Der Db-Zugriff selbst kommt nicht vor.

Auch ist das das olle blöde typisierte Dataset, und EF ist ja soo viel Toller!
Nur dass man typDataset-Anwendungen prototypisch auch ohne Db entwickeln kann, während man mit EF gleich mit einem Heiden-Heckmeck anfangen muss, und am Ende hat man immer noch keine funktionierende Löschweitergabe oder sowas.

Also ich halte es nicht fürs schlechteste, Datenmodellierung und Databinding am typDataset zu erlernen - wenn man die Denkweise verstanden hat, dann kann man sich auch in EF leichter einfinden, und Fehlentwicklungen frühzeitig erkennen.

Aber vlt. meldet sich ja noch einer mit einem geeigneten EF-Tut - ich hab sonst nur noch eine EF-CodeFirst-Wpf-Sample-Anwendung, und wenn man der auf den Zahn fühlt, zickt die auch rum, etwa bei der Löschweitergabe.
https://www.vb-paradise.de/index.php/Thread/112373-EntityFramework-CodeFirst-Sample/

Hier mal neben der Einfachheit auch eine theoretischere Fundierung:

Ich stehe dem Interface-Fimmel sehr reserviert gegenüber, weil in meiner Programmier-Welt alles einen Grund haben muss. Weiß man für etwas keinen Grund anzugeben, soll mans lassen, ist meine Devise.

Interfaces dienen der Entkopplung, und Entkopplung ist sinnvoll, wenn man etwas austauschen möchte.

Nun will man das Viewmodel eines Views aber garnet austauschen, sondern das View soll das Viewmodel anzeigen und sonst garnix.
Und dazu musses das Viewmodel kennen.

(Andersrum ists eher denkbar, dass man das View eines Viewmodels austauschen will. Das ist auch kein Problem, denn das Viewmodel kennt das View ja eh nicht.)

ich hätte in mehrfacher Hinsicht Verbesserungs-Vorschläge, manche direkt an deim Code, aber wichtiger wären architektonisch Änderungen oder gar ein kompletter konzeptioneller Umschwung.
Aber erstmal Code: Es ist grotesk, dass du für einen Delete-Vorgang 2 EntityContexts in Anspruch nimmst. Mach einfach:

        private void mnu_Delete_Click(object sender, EventArgs e)
        {

            Kabelgewicht kabDel;
            using (var ctx = new KabelgewichtContext())
            {
                kabDel = ctx.Kabelgewicht.Where(t => t.Id == dgv_index).FirstOrDefault<Kabelgewicht>();
                ctx.Entry(kabDel).State = System.Data.Entity.EntityState.Deleted;
                ctx.SaveChanges();
                UpdateData();
            }

        }

oder sowas.
Dann architektonisch: schreib dir eine Methode, der du die Indizees der Items übergibst, die zu löschen sind, und führe die Löschung in einer Schleife durch.
Die mehreren selected Items eines DGVs kannst du als DGV.SelectedRows abrufen.

Architektonisch wäre noch jede Menge anderes zu tun, aber ich gehe gleich ans konzeptionelle:
Verwende Databinding.
EF ist auf Databinding hin konzipiert, und wenn du es richtig einsetzt, entfällt dann die Methode UdateData() - ich vermute nämlich, die ist bei dir aufwändig und buggy.
Hingegen Databinding ist ein generelles Konzept, wo die Daten-Präsentation sich selbst updatet.
Das erfordert eine andere Denkweise, eine andere Strukturierung, aber dann funzt das fehlerfrei, und ohne dass eine Zeile Code dafür zu schreiben wäre - denn die ganze Infrastruktur dazu ist im EF längst eingebaut.

nach kurz googeln gewinne ich den Eindruck, dass man besondere Vorkehrungen treffen muss, um Xaml an Interface-Properties zu binden.

mein suchbegriff:
bind xaml to interface

einer der Treffer: http://stackoverflow.com/questions/15023441/how-to-bind-datatemplate-datatype-to-interface

Könntest auch mal probieren, weniger mit Interfaces zu machen - ist meist einfacher.

Kannst dir auch mal angugge, wie einfach das Binding-Setzen sein kann, wenn man dem View zugesteht, das Viewmodel wirklich zu kennen:
https://www.vb-paradise.de/index.php/Thread/83442-MVVM-Binding-Picking-im-Xaml-Editor/

Ich wäre hier auch einem Behavior gegenüber skeptisch.
Behavior (wie eiglich jede Klasse) scheint mir nützlich, wenn es wiederverwendbar ist.
Aber hier ist die MouseWheel-Aktion ans Viewmodel gekoppelt, soll ja eine Methode darin aufrufen.
Ein Behavior wäre also zunächstmal ebenso daran gekoppelt, und somit nicht wiederverwendbar.
Oder man bastelt sich iwie ein besonders geschicktes MouseWheel-Behavior, dem man per Xaml auch mitteilen kann, was es aufrufen soll ... aber ob was dabei herauskommt, besser wird, als was zB die Interactivity-Libs anbieten?

Und der Einzeiler ist nu wirklich super-trivial - ein wiederverwendbares Behavior wird viel komplexer werden müssen.

Also ich bin ühaupt kein Freund von CodeBehind, aber manchmal ists wohl doch das geringere Übel.

gute Idee mit eigenem ResourceDictionary 👍

Aber warum erbst du von MarkupExtension?

Zur Frage:

Hast Du vielleicht eine Idee, was ich beim Binding falsch mache? Beim ContentPresenter scheint der DataContext mit dem Content identisch zu sein.

Also wenn du ohne Pfad bindest, dann ist an die MyViewmodel-Instanz gebunden, und die hat ja die Value, und ValueType.Name - Property.

Wenn du den Content aber auf den Pfad 'Value' setzst, dann hat das keine Value-Property, und erst recht kein ValueType.Name.

Das sagt ja auch der Binding-Mismatch-Error im Output-Fenster:

System.Windows.Data Error: 40 : BindingExpression path error: 'ValueType' property not found on 'object' ''Int32' (HashCode=50)'. BindingExpression:Path=ValueType.Name; DataItem='Int32' (HashCode=50); target element is 'ContentPresenter' (Name=''); target property is 'ContentTemplate' (type 'DataTemplate')

Also das hatten wir glaub schon, als ich sagte, ein Binding könne alle Properties des gebundenen Objektes ändern, aber nicht das gebundene Objekt selbst.

genau - eine Lookup-Tabelle.
Der Aufbau im Xaml ist ein bischen komisch / unsicher, weil der Kram Spaltenweise aufgebaut wird, nicht zeilenweise. Aber das ergibt kompakteres Xaml - sonst müsste man jedes WertePaar einzeln in eine zusätzliche WertePaar-Zeilen-Klasse einpacken.

Und ja - ist das erste Mal, dassich damit nach DataTemplates lookuppe 😉
Hab mir auf msdn jetzt auch den TemplateSelector-Beispielcode geguckt - wenn man will kann man nach demselben Prinzip ja auch einen LookupTemplateSelector basteln.

Ich könnte mir vorstellen dasses ein Problem gibt, weil ja beides genau gleichzeitig per Binding bestimmt wird: Sowohl der neue Wert, als auch das neue DataTemplate.
Könnte mir vorstellen, dass, wenn ein Wert gewechselt wird, dasses es da im Übergang kurzzeitig zu Mismatches kommen kann - meine Versuche sahen tw. danach aus.

Aber ein LookupTemplateSelector wäre ja genau dazu da, für jeden Wert erstmal das Template zu selecten.

Edit - PS: ContentControl ist ein Control, da kann man ein ControlTemplate dran machen. Allerdings habich noch nie Verwendung für gehabt - wohl aber für HeaderedContentControl.

scheint ungefähr zu gehen

lieber du das Test-Projekt.

Mein Converter ist noch in vb, und am Ende gehts garnet so, wie ich mir das denk.

wenn ich mich recht erinnere ist das mit dem TemplateSelector recht lausig.
Der muss ja in c# gecodet sein, soll aber in Xaml erstellte Templates selektieren.

Wie gesagt, wenn du ein Testprojekt aufsetzst, probier ichs mal mit meim LookupConverter.
Da kann man Schlüssel-Werte-Paare im Xaml reinschmeissen, und dann daran binden, und der wählt anhand des ConverterParameters aus, das müsste eiglich hinhauen.

Aber vlt. kriegst du ja auch iwie einen überzeugenden TemplateSelector hin.

Wie gesagt: Imo sollteste die DataTemplates aufs Viewmodel münzen, nicht auf die einzelne Property darinnen.
Dann hast du aber das Problem, dass sie sich nicht mehr am Datentyp unterscheiden (sind ja alle aufs Viewmodel gemünzt).
Wäre ein Fall für einen TemplateSelector, oder einen Converter, der Templates selectiert.
Ich hab son Converter, der sollte das können, also wenn du eine Sample-App bastelst, und anhängst, wo man per Buttonklicks verschieden typisierte Objekte an ein Viewmodel zuweisen kann, dann kann ich probieren, ob man das VM mit je spezifischen DataTemplates präsentiert bekommt.

Ich weiß aber nicht, ob das einfacher ist als die Lsg, die du bereits hast.

ich hab noch kein Plan, wie eiglich dein Viewmodel aussieht: Ist das eine List<object>, und was darinnen ist, ist mal ein bool, mal ein bool?, mal ein string, mal ein int, mal ein int?, ... ?

Oder gibts nicht wenigstens eine Container-Klasse, mit einer Value-Property, die all dies Datentypen enthalten könnte, oder wie sieht das aus?

ich glaub, das ist zu "kleinräumig" gebunden. Also ein Binding kann zwar alle Properties des Viewmodels ändern, aber nicht das Viewmodel selbst austauschen.

Und bei dir ist das Viewmodel ein Double, oder ein Int

Oder ach nee:
Innerhalb des Datatemplates solltest du an Properties des Datatypes binden - nicht an iwas externes.
Und dann ähnliches Problem: Int oder Double haben halt keine Properties.

Die Entscheidung, wie sie dargestellt werden, übernimmt ein Converter anhand der ValueType-Property. Das ist eiglich nichtmal nötig.
Man kann für verschiedene Datentypen DataTemplates in die Resourcen packen, und dann die Daten einfach in einen ContentPresenter schmeissen.
Der ContentPresenter sucht sich dann automatisch das passende DataTemplate aus den Resourcen.

Selbiges funzt auch mit ItemsControls oder Listboxen - da sind schon von Haus aus ContentPresenter eingebaut.

Aber ich hätte noch paar Anmerkungen zu deim Stil:
DataContext = this ist iwas anderes, aber kein MVVM.

Und ein DataTemplate sollte seinen DataType angeben, das eröffnet auch etwas mehr Unterstützung im Xaml-Editor.
Und die von mir beschriebene Template-Selbst-Such-Funktionalität basiert darauf.
Also ein für die Selbst-Suche vorgesehenes DataTemplate darf keinen Key haben, muss aber den Datatype gesetzt haben.

Ein Beispiel für die von mir genannte Funktionalität findeste hier:
https://www.vb-paradise.de/index.php/Thread/63653-MVVM-Pattern-DataContext-und-DataTemplates-im-Treeview/
Dort der Treeview präsentiert polymorphe Daten (Folders und Files), und in den Resourcen des Treeviews sind 2 DataTemplates, die automatisch richtig zugeordnet werden.

Also ich sehe da ein Grid mit 3 Spalten zugrunde liegen, von dem die mittlere nur 8 pix breit ist, und von einem GridSplitter belegt, damit man die beiden Bereiche verschieben kann.
Links kann ein Dockpanel sein, in dem die Suche-Textbox Top gedockt ist, die Member-Listbox (oder ListView) Fill.
Rechts ist ein anderes Grid drin, diesmal mit 3 Zeilen, von denen die mittlere wieder mittels GridSplitter dafür sorgt, dasss der untere Bereich variabel ist.
Im Oberen Bereich dann wieder ein DockPanel mit oben iwas, was das MemberInfo anzeigt, darunter halt eine Listbox (oder ItemsControl) mit den Meldungen.
Die Meldungen mit dieser komischen Sprechblase kann man mittels ItemTemplate gestalten.

Es gibt zig weitere Möglichkeiten, dieselbe Optik zu erzeugen, also fass diesen Post am besten einfach als Stichwort-Lieferant auf - Stichworte, in die du dich einarbeiten musst:
Grid, GridSplitter, DockPanel, Listbox, ItemsControl, ItemTemplate.

Weiters würde ich aber empfehlen, entwickel erstmal die Oberfläche so simpel wie möglich, aber im Zusammenhang mit einem Viewmodel - das Viewmodel wird nämlich kompliziert genug.
Was deim Exposee zB noch ganz fehlt ist ein Template für deine Antworten - die müssen ja in eine iwie anders gestaltete Sprechblase.
Also entwickel erstmal einen Testlauf-fähigen Prototyp.

So Suchbox-Gimmix und Sprechblasen kannste dir für später aufheben.

@ErfinderDesRades:
Mich würde deine Vorgehensweise bzgl. ViewModels schon interessieren Also wie ich oft anfange, hab ich hier mal erläutert:
https://www.vb-paradise.de/index.php/Thread/115475-MVVM-Anwendungs-Struktur/?postID=1005812
Also ich hab ein MainViewmodel, wo meist (nicht immer) alle Viewmodels zusammenfließen, und als Properties enthalten sind. Das sind dann garnet so viele, weil was da zusammenfließt kann ebenfalls wieder komplex aufgebaut sein, also zB ein MainViewmodel mag mit 2 - 3 Workspaces schon ziemlich viel abdecken.
Der MainViewmodel-Konstruktor ist parameterlos.

Wie gesagt: So mach ich das oft, und was dabei rauskommt, sieht mir oft auch sehr kompakt, übersichtlich und plausibel aus.
Natürlich erfüllt es nicht alle Ansprüche aller Szenarien, die es geben kann, aber oft genug passt es eben doch auch sehr gut.

[schlechter Tag]

hmm - ja, iwie schon, aber egal.
ich vermute halt, den TE wird so eine Beratung in alle Richtungen gleichzeitig nicht wirklich weiter bringen.
Aber alles was ich beitragen kann, wäre auch nur eine weitere Richtung, also ich klink mich daher jetzt aus, es sei denn, der TE ist nu speziell an "meiner Richtung" noch besonders interessiert (etwa weil die anderen iwie doch nicht ausreichen).

Also vorgesehen ist, dass das View in app.xaml geladen und gestartet wird - in keiner anderen Klasse sonst.
...
Und da hat man halt die App.Xaml, und darin ist das StartupWindow definiert, und da gibts auch eine Resource mit dem Root-Viewmodel.

Es ist auch möglich eine App.cs anzulegen. Wir verwenden hier z.B. keine App.xaml zum Starten unserer Programme. ja schön und gut. Jo, in Wpf kann man alles auch ganz anders machen und hat immer zig Möglichkeiten.

Mir ist jdfs aufgefallen, dass es einen Property App.StartupUri gibt, die man im app.Xaml setzen kann.
Daher hätte ich es für eine Standard-Vorgehensweise gehalten, das auch zu tun (und einfach ists obendrein).
Aber das ist offensichtlich vollkommen naiv von mir, und iwas mit Containern, Injection, und eine App.cs ohne Xaml ist viel besser - app.Xaml und den StartupUri hat MS nur erfunden, um uns zu verwirren und vom rechten Weg abzubringen.

Deinen letzten Post verstehe ich nicht.
Wann braucht man kein ucl erstellen? Wenn man auch ein Datatemplate nehmen könnte?

Also ich nehme gerne ein ucl, um die View zu modularisieren. Etwa ein uclPerson, wenn ich ein PersonViewmodel anzuzeigen habe.
Jo, geht vlt. auch mit eim DataTemplate, aber ein ucl kann ich beim Entwerfen angucken.

Und welche UserControls meinst du, die im Framework bereits vorhanden sind?
Und ja, kann sein, dass bei denen das Binden von Daten über DepProps funktioniert - wobei ich da in Erwägung ziehen würde, gleich ein richtiges (lookless) CustomControl zu entwickeln - also keinen UserControl-Erben.

Die App.Xaml ist doch kein View.

Und wenn MainWindow und UserControl dasselbe Viewmodel nutzen, dann wird das UserControl wohl zwangsläufig was über das Viewmodel der View wissen. (Und schließlich ist es ja auch Teil der View, also wieso solls das Viewmodel nicht kennen?)

Eine Alternative ist, zur Designzeit im ucl mit d:DataContext zu arbeiten, welcher Viewmodel-Mocks zur Designzeit bereitstellen kann.
Und zur Laufzeit erhält das ucl seinen DataContext ja vom Window, wo's eingebettet ist.

Auf jeden Fall muss das Ucl zumindest so viel Viewmodel kennen, wie es anzeigen soll. Andernfalls kann man nicht vernünftig Bindings setzen.
Viele Wpf-Progger kennen garnet, welche Unterstützung zum Binding-Setzen eiglich vorgesehen ist - guggemol https://www.vb-paradise.de/index.php/Thread/83442-MVVM-Binding-Picking-im-Xaml-Editor/

ich glaub nicht, dass das so gemeint war.

Schon der Name: Die Klasse sollte nicht View heissen, denn sie ist kein View, sie ist nichtmal sichtbar.

Ansonsten denke ich, dasses einfach ein Fehldesign ist, im UserControl ein Viewmodel in die Resourcen zu legen, auf dass das MainWindow auch zugrabschen soll.

Lege das Viewmodel in die Resourcen von App.Xaml, dann hat sowohl das MainWindow darauf zugriff (StaticResource-Binding) als auch das Ucl.