@TE: Hmm - wie gesagt, ich kann nix testen, aber deine Codebehind-Lösung hätteste doch ebensogut jederzeit anpassen können, ohne iwie in die eigliche Funktionalität des Viewmodels einzugreifen?

Sogar wenn im nachhinein die Anforderung auftritt, das Verhalten auch auf annere ListViews zu übertragen - dann kann man ja immer noch die Codebehind-Logik als Behavior extrahieren (Prinzip "Yagni: du brauchst es vlt garnet")

Müsste die Problemlösung mit der Blend Behaviors etwa so aussehen? jo - täte mich auch interessieren. Ich kanns ja nicht testen, weil hab kein Blend.

Zwei weitere Fragen an dich ätte ich:

1. funktioniert das, wie's soll? Und wie solls eiglich funzen - ist mir immer noch nicht klar: soll einfach das Item unter der Maus gehighlighted sein?
2. welchen konkreten Gewinn hast du davon gegenüber deiner Lösung hier, von vor 2 Tagen? Die ist immerhin nur ca. 1/3 des Aufwandes.

Jo, das ist genau mein Begriff eines Behaviors: Eine attached Property, die durch Event-Verarbeitung das Verhalten des Controls, an das sie attached ist, modifiziert.

Ich wusste garnet, dass Blend ebenfalls eine Behavior-Technologie bereitstellt, halt eine andere.
Weil ich hab kein Blend.
Daher verstund ich unter "Behavior" im Wpf-Kontext bislang immer attachedBehavior.

Behaviors werden aber ausschließlich über die System.Interactivity.BehaviorCollection an ein Control angehangen. "ausschließlich" ist nu bischen iwie begrifflich "unverschämT" 😉 , weil Behaviors im hier gezeigten Sinne gibts ja schon viel länger und unabhängig von dem Kram, den man zum Framework hinzuinstallieren muss, um System.Interactivity ühaupt verfügbar zu haben.

Aber wenn ich dein Link richtig verstehe, steht das dort auch garnet so. Sondern dort wird zw. attached-Behaviors und blend-Behaviors unterschieden. (Oder? Ich habs nur überflogen, weil englisch lesen ist für mich sehr aufwändig)

Wie dem auch sei - aktuell primäres Problem ist, dass das hier gezeigte Behavior so ühaupt nicht funktioniert (zumindest ich kriegs nicht hin).

Hmm - sieht interessant aus, aber wenn ichs einbinde laufe ich auf eine InvalidcastException:> Fehlermeldung:

Das Objekt des Typs "PersonListboxBehaviorTester.ViewModel.Person" kann nicht in Typ "System.Windows.Controls.ListBoxItem" umgewandelt werden. bei foreach in

   public static class UndoListBehavior {
//...
      private static void ListBox_MouseMove(object sender, System.Windows.Input.MouseEventArgs e) {
         var listBox = sender as ListBox;
         var listBoxItem = listBox.GetContainerAtPoint<ListBoxItem>(e.GetPosition(listBox));
         bool isSelected = false;
         foreach (ListBoxItem item in listBox.Items) {
            SetIsPreviewSelected(item, isSelected);
            if (item == listBoxItem) { isSelected = true; }
         }
      }

Ist auch iwie logisch, weil ich hab keine ListBoxItem in meine listBox.Items, sondern - in meim Falle - Instanzen meiner Person-Viewmodelklasse.

mein Xaml noch:

 <ListBox Grid.Row="2"  Grid.Column="2" ItemsSource="{Binding UndoItems}"  DisplayMemberPath="Name" Padding="4"
        Style="{StaticResource UndoListBoxStyle}"/>

Also die als UndoItems angebundene Mainviewmodel-Property ist eine ListcollectionView mit Personen drinne, nicht ListboxItems

Von DockPanel erben hab ich schon versucht (siehe zweiter Post, letzer abschnitt). sorry - kannst du das verlinken? Wie immer ich "2. Postm letzter Abschnitt" auch aiuffasse, von Erben von Dockpanel finde ich da nix.

Jo, Behaviors hatte ich zu erwähnen vergessen.
Aber muss man auch aufpassen - oder zumindest überlegen, obs was bringt.
Der Sinn eines Behaviors ist ja, ein bestimmtes GUI-"Verhalten" darzustellen. Nun sind aber viele Anforderungen ganz ganz spezifisch für die eine Anwendung, oder auch nur für eine einzige View, und sind prinzipell nicht auf andere Anwendungen übertragbar.

Was nützt in dem Falle ein Behavior aus dem Codebehind auszulagern, wenn mans eh nur für genau dieses eine Gui-Element, in Verbindung mit genau dem dazugehörigen Viewmodel-Element verwenden kann?

Jo - das ist gewissermassen meine "Definition" eines Behaviors: Eine Klasse, die das Verarbeiten von ViewElement-Events aus dem Codebehind auslagert in eine eigene Klassem die dann per Xaml ans View attacht werden kann.

Wie gesagt: hat nur Sinn, wenn man das ausgekoppelte iwo anners auch wieder "einkoppeln" kann - ansonsten kann mans eiglich auch da lassen, wo's ursprünglich herkommt - dann hat man einfacheres Xaml.

Überleg auch, ob du wirklich ein IWindowService-Interface brauchst. Vor allem brauchst du ja den WindowService, der die Arbeit auch macht.
Ob da noch zusätzlich ein Interface rumfährt - das trägt zur eiglichen Funktion ühaupt nichts bei.
Sondern son Interface dient bestenfalls iwelchen weiteren Zwecken, die hier noch weder gefragt noch sonst iwie thematisiert wurden.
Ich sag immer, man soll sich eratmal überlegen, ob und was man braucht.

Naja - musste halt in irgendeiner Weise die entsprechenden Events verarbeiten, die betroffenen Daten ermitteln und iwei markieren.
Schon zu ersterem gibts 2 prinzipielle Vorgehensweisen:

1. good old Codebehind-Code
2. iwelche "EventToCommands" - Klimmzüge, um den View-Zustand ins Viewmodel zu melden.

Nach meiner Erfahrung ist das eine wie das andere nicht ganz einfach, Crux ist halt, dass View und Viewmodel stärker miteinander verbunden werden müssen, als es normale DelegateCommand-Bindings hergeben.

Mit meim ersten Satz ist übrigens auch gleich gesagt, dass du im Viewmodel ühaupt etwas vorsehen musst, dass Daten auch als selektiert markiert werden können.

(Und was noch ganz aussen vor steht ist die Frage, ob du ühaupt nach dem MVVM-Pattern entwickelst - sonst ist das erstmal das Thema, denn was anneres als MVVM zu verzapfen kommt nach glaub einhelliger Ansicht nicht in Betracht.)

ich hab mal gehört, Xaml hätte bischen Probleme mit Intrfaces.
Probierma, den Original-Datentyp zu veröffentlichen statt nur des Interfaces - wird ja ein DelegateCommand sein oder sowas.

Danke für die Tipps, aber inzwischen hat es sich von selbst aufgelöst:
Ein paar mal noch kam dieses Zeugs zum wegklicken, aber ich hatte keine Zeit, dem weiter auf den Grund zu gehen, und heute kommts auf einmal nicht mehr.
Dabei hab ich an der Solution meist garnix gemacht, aber an meiner SVN-Konfig hab ich einiges rumgefummelt, hin und her, weil damit bin ich Anfägner und muss mich einarbeiten.

erb doch spasseshalber mal von DockPanel

Ich könnte mir vorstellen, die funktionierenden Standard-Panels haben iwelche Attribute mit Informationen für den Xaml-Designer

Hi!

Ich hab von CodePlex eine Solution gezogen.
Wenn ich die im VS2015 öffne, bekomme ich ehe es losgeht immer 2 Messageboxen zum wegklicken:

---

Microsoft Visual Studio

Team Foundation Server-Versionskontrolle

Die Projektmappe, die Sie gerade öffnen, ist für folgenden Team Foundation Server-Computer an die Quellcodeverwaltung gebunden: > . Möchten Sie diesen Server kontaktieren, um zu versuchen, die Quellcodeverwaltung zu aktivieren?

Ja Nein Hilfe

Ich klicke Nein, dann folgt:

---

Quellcodeverwaltung

Die Projektmappe befindet sich unter Quellcodeverwaltung, aber die Bindungsinformationen wurden nicht gefunden. Da fehlende Informationen nicht automatisch wiederhergestellt werden können, werden die Projekte ohne Bindungen als nicht unter Quellcodeverwaltung stehend behandelt.

Ok Hilfe

Ich klicke Ok und kann starten.
Von früher kenne ich das, aber das war nur beim erstmaligen Öffnen einer Codeplex-Solution - danach hat er iwie verstandne gehabt, dass ich ohne (diese) Quellcodeverwaltung arbeite.

Mein VS2015 ist auch neu, und AnkSvn ist installiert.

(Übrigens frug ich diese Frage schon gestern auch auf vbParadise, aber die Site ist grad down)

Dann bist Du aber auch gezwungen, ein solches ViewModel zu implementieren, dass zum UC passt. Ja, allerdings - bzw andersrum gedacht:
Ich implementiere Ucls, die zum Viewmodel passen 😁

Meine ucls kriegen über d: DataContext bereits im Designmode mitgeteilt, welches Viewmodel sie darstellen sollen.
Sie sind nicht als allgemein-verwendbar gedacht, wie etwa eine Textbox oder ein DatetimePicker.
Sondern wenn ich ein Viewmodel Person habe, mit Vor- und Nachname, und ich will Personen an mehreren Stellen im Programm anzeigen - oder auch nur allzu groß werdende Xaml-Dateien entzerren - dann bastel ich für Person ein ucl.

@TE: bei Interesse kannste auf Wpf-Sample son Sample downloaden - ich find die Vorgehensweise eiglich ziemlich überzeugend, weil man geniest beim proggen das Maximum an Wysiwyg und Intellisense-Hilfe.

Eiglich müsste man das doch viel einfaher mit Async/Await abhandeln können, ganz straight.forward:1.Splash anzeigen 1.async: Daten holen 1.Splash shliessen und App mit MainWindow starten

nix mit iwelche Modes umstellen, oder die Anwendung codeseittig "abschiessen".

komisch - bei mir haben die UserControls meist keinerlei DepProps - weil üflüssig und widerspräche MVVM.
Die werden einfach alle schön ans Viewmodel gebunden, und wenn im MainWindow was geklickst wird, dann ereignet sich nix inne UserControls, sondern im Viewmodel.
Und die Veränderung im Viewmodel spiegelt sich natürlich inne Ucls wieder - das ist ja das Prinzip Databinding.

Also genau genommen binde ich nicht die Ucls ans Viewmodel, sondern die einzelnen Controls, die auffm Ucl drauf sind.
Und - klar - Controls haben DepProps, aber die sind ja schon da, die brauch ich ja nicht dran-zu-coden.

hübsche Knobelaufgabe.
Eine denkbare Lösung wäre, dass bei jeder Änderung die Summe berechnet wird, und falls drüber wird der höchste Slider ausser des aktuellen gesucht und erniedrigt.
Falls das nicht ausreicht, nochmal: den (dann) höchsten suchen und erniedrigen usw..

vielleicht stimmt der angegebene propertyName nicht

ja, Bindings funktionieren control-seitig über DependancyProps.

Hast du aber nix mit zu tun, die DpdPs sind ja im xceed-control implementiert.

Du musst nur wie gesagt ein geeignetes Vievmodel bereitstellen - daran kannst du das xceed-Dingens dann binden.

Also ich vermute, "MVVM" ist eher das Stichwort, was du recherchieren müsstest.
Gibts jede Menge im netz zu, das meiste findich aber irre aufgeblasen.
Und anderereseits gibts auch samples, die zu simpel sind - etwa den Use-Case "Auswählen und Löschen aus einer Liste" geflissentlich weglassen.
Weiters verderben die meisten Samples die Intellisense-Unterstützung des Xaml-Designers, indem DataContexte per CodeBehind gesetzt werden, statt im Xaml.

Lange rede kurzer sinn: guck dir Wpf-Sample an, obwohls VB.net ist.
Oder gugge codeproject unter "MVVM für anfänger" - da findste aufgeblasenes, unzureichendes, und verdorbenes - aber dafür in c# 😉

(Edit: nochmal geguckt: ich hab ja sogar eine c#-variante bei meim sample!)

du musst diese Properties natürlich an geeignete Viewmodel-Properties binden.

Bietet xceed keine Samples?

Bist du dir sicher, dasses das ist, was du möchtest?

Oder möchtest du nicht vielmehr das ParentElement des selektierten Viewmodel-Items haben?

komisch.

Wenn ich Dataset.WriteXml() aufrufe, sind damit die Daten auf Platte, das Schema ühaupt nicht.

(Edit: Ups - sorry - das hatte BerndfFm ja auch schon gesagt)

Das stimmt nicht. Bei Zuweisung an die Image-Property wird keine Kopie erstellt.

Daher sollte man, wenn man einer Picturebox die Image-Property wechselt, natürlich auch das vorherige Image disposen (falls es nicht noch an anderer Stelle vonnöten ist)

In welcher Weise sich nu schnelleHelga geholfen hat, ist also noch nicht klar.
Mir ist auch garnet klar, wieso ein Code "frühestens nach ein paar Wochen das erste Mal aufgerufen wird" solche Auswirkungen haben kann - tatsächlich ists doch sehr ungewöhnlich, dasses solch Code ühaupt gibt - läuft das Proggi denn im Dauerbetrieb?

ja, guter Hinweis.
Kann auch mit zusammenhängen, wo die PB befüllt wird.
WinForms hat leider den katastrophalen Bug, wenn im Form-Konstruktor oder im Form_Load ein Fehler auftritt ohne Fehlermeldung abzubrechen und fortzufahren.
Es kommt dann also dazu, dass Codezeilen ab dem Fehler einfach nicht mehr ausgeführt werden.
Feststellen lässt sich das sehr leicht mit Haltepunkt und Einzelschritt.

ich denke, da kannst du nehmen was wolle. Button, Label - oder ein Shape: Rectangle, Ellipse, Path.
Am Block selbst wird ja garnet gebunden, sondern nur an die AttachedProperties Grid.Row, Grid.Column.

Aber ist es nicht eher so, dass du vom ItemsContainer die AttachedProperties binden musst?
Glaub da braucht man einen ItemsContainerStyle, um das hinzukriegen.

Wie kommts, dass du zur Laufzeit Relationen erstellen willst?

Normalerweise macht man erst das Datenbank-Design, dann baut man die Datenbank dementsprechen, inklusive Relationen.

Zur Laufzeit benutzt man die Datenbank, verändert aber nicht nachträglich das Datenmodell.
Das kann ja verheerende Folgen haben für den Rest des Programms, welches ja noch das vorherige Datenmodell in der Db annimmt.

Also normalerweise, daher meine Frage, wies kommt, dass du zur Laufzeit Relationen erstellen willst?

Was hälst du für völlig falsch?
Und warum - kannst du es vlt. kurz in eigenen Worten sagen?

generell würde ich empfehlen, langlaufende Vorgänge vom Gui abzutrennen.
Also wenn in einer Schleife 10000 Werte berechnet werden, ists nicht sinnvoll, jedes einzelne Ergebnis via Databinding+thread-Delegation ans Gui zu melden - solch frisst ungeheuer Performance, und so schnell gucken kann auch niemand.

Hingegen in Einzelfällen mags auch mal sinnvoll sein, threadsicheres Databinding zu implementieren.

Ich würde aber eine effizientere Variante wählen, das mit dem Auspopeln der InvokationList, und dann jeden Abbonenten einzeln und mit Thread-Delegation invoken - das ist ziemlich lahm.

Und vor allem lässt sich die Collapse-Funktionalität, wie beschrieben, ausschließlich mit WPF umsetzen? Ich bin mir ziemlich sicher dass das geht, obwohl ich selbst das bislang nur mit DataGrid umgesetzt habe.
Groups und CanGroup etc. sind ja bereits im ICollectionView-Interface vorbereitet, also bereits inne Grundlagen des Bindings von Auflistungen überhaupt.

ich weiß jetzt nicht, ob das hiesige Modell ein model ist oder ein business model.
Jdfs. scheint mir der Model-Postfix auch sehr üflüssig.

Bei einer Klasse, die Machine heisst, weiß jeder, dasses ein Model ist - was soll es sonst sein? Weil wirkliche Maschinen gibts ja nicht in c#.

Wenn du magst, kannste dir BeispielAnwendung angucken - da hast du eine OrdnerStruktur, und es kommt auch was mit Comboboxen und Einzel-Controls vor usw. - vlt. ist ja die eine oder annere Anregung dabei.

Dein Problem habich noch nicht recht verstanden - mir kommt es vor, als wollest du einen "DetailView" implementieren.
Was dabei eine Flut von Klassen helfen kann ist mir nicht klar.
Meist genügt, die EinzelControls an die Liste zu binden, aber mit '/' am Ende zu spezifizieren, dass eben nicht die ganze Liste gebunden ist, sondern nur das CurrentItem.
Aber gugge Sample - ist glaub auch sowas mit dabei.

also ich weiß da nix.
reicht es nicht, den Treeview auf einen SplitContainer zu tun, dass dann der User sich den so breit ziehen kann, wie es ihm genehm ist?

Mir ist nicht recht klar, wonach du eiglich fragst.
Ob es Resharper ist oder das ItemsControl selbst, was es bewerkstelligt, dass in seim Inneren der Item-DataContext gilt statt des umgebenden?

Es liegt am ItemsControl, nicht am Resharper.

Wenn du allerdings fragst wie ItemsControl das bewerkstelligt, muss ich passen. Und wie man das selber hinkriegt - passe ich ebenfalls.

Wenn ich sowas haben will, dann erbe ich eben von ItemsControl - dann habe ichs ja.

Oder was genau ist die Frage?

Für ein Spiel finde ich eine Datenbank - auch embedded - ziemlich oversized und overcomplicated.
Du kannst alle Daten in einem typisierten Dataset unterbringen, und direkt auf Platte schreiben - ohne einen DB-Provider bemühen zu müssen.
guggemol DatasetOnly - Abschnitt DatasetOnly, und natürlich das CodeSample.

Ich find bei deim Code schlecht gelöst ist, dass du deine ZeichenObjekte in einer Listbox verwaltest.
In diesem Listbox-Control kann ja eiglich nichts vernünftiges angezeigt werden.
Da nimm lieber eine List<Object> - die ist eh kein Gui-Element.

Auch kannst du bei diesem Problem sehr schön Vererbungslehre und OOP walten lassen:
Schaff dir eine abstrakte Basisklasse "ZeichenObjekt", von der deine verschiedenen ZeichenObjekte erben, und die je nach ihrer Art die Basis-Zeichen-Methoden überschreiben.
Dann kann jedes Objekt - egal welcher Art - sich selber zeichnen, mit seiner je spezifischen Überschreibung, und die ganzen Typ-Überprüfungen sind überflüssig.
Tu die ZeichenObjekte dann nicht in eine List<Object>, sondern in eine List<ZeichenObjekt>.

Hier ist sowas vorgeturnt mit noch paar weiteren Schikanen: Performantes OwnerDrawing

in ein TabItem kann numal nur ein Control rein.
Tu ein ItemsControl rein, etwa ein StackPanel - da hinein wiederum kannst du werfen was wolle.

Hihi - die Fehlermeldung sagt dir einfach den Fehler (dazu ist sie ja da): Du versuchst, 2 gleiche Objekte einer Auflistung zuzufügen, die sowas nicht akzeptiert.

Logischerweise tritt dieser Fehler nur deshalb zutage, weil du die GetHashCode() - Methode richtig! überschrieben hast.
Ohne sie zu überschreiben bleibt die Fehlermeldung natürlich aus, denn die Default-Implementation von GetHashcode() returnt einfach die Objekt-Addresse - und so definiert sind nie zwei Objekte gleich.

Also sei froh, dass dir der Fehler gemeldet wird, und mach dich auf die Suche, wie es kommt, dass du zwei gleiche Objekte zu adden versuchst, wo das halt unzulässig ist.

Viel schlimmer wärs, wenn der Fehler nicht gemeldet würde - dann entstünde nämlich der schönste Daten-Kokolores, und iwann viel später würde ein Fehlverhalten auftreten, dem du nie und nimmer auf die Schliche kämst.

PathFigure hat eine ganz fabelhafte Syntax, mit der man Figuren ausserordentlich kompakt formulieren kann.
Ist eine eigene kleine "embedded Language", hab ich mal Tut zu verzapft:
Linien, Figuren, Formen

Hier ein Tut, was Databinding an typisierte Datasets schritt für schritt entwickelt (3 aufeinander aufbauende Artikel):
Data-Modelling for Beginners
Vlt. hopfst du als erstes zum Code-Download des letzten Artikels, und probierst das aus, um einen Eindruck der Möglichkeiten zu gewinnen - als Motivation, die Artikel wirklich durchzuackern.

Wie du offsichtlich erlebt hast, sind beim Selber-Basteln von Datenklassen eine erhebliche Menge an Fussfallen zu umschiffen, bevor man ühaupt ein erstes Ergebnis zu Gesicht bekommt.

typDataset kann einem da enorm (stupide) Arbeit abnehmen, sodass man sich besser aufs Wesentliche, aufs Datenmodell konzentrieren kann.

Hat man das Wesentliche verstanden und zum Laufen gebracht, steht einem ja immer noch offen, es selbst und quasi "handmade" nochmal zu versuchen - warum auch immer.

ich glaub nicht, dass eine Wpf-Animation für ein Kart-Rennen geeignet ist.
Eine Animation ist ja ein fest voreingestellter Ablauf, der abläuft.
Ein Kart-Rennen ist aber etwas, wo in die Geschwindigkeit vmtl. per User-Interaktion einzugreifen ist.
Deshalb (und weil Animation imo kein Anfänger-Stoff ist) die Bewegung im Viewmodel abbilden.

Ein Beispiel, wie man mehrere Objekte eigenständig sich bewegen lassen kann, habich ja verlinkt - was hälst du eiglich davon?

Naja - ich glaub halt nicht, dass ihr selber das wirklich durchzieht, was ihr propagiert.
Das würde ja bedeuten, dass man überhaupt jede Methode, die irgendwo auf ein Control zugreift, mit InvokeRequired absichert - weil "man kann ja nie wissen!"

Solange du nicht kontrollieren kannst, woher die Routine aufgerufen wird, musst du auf InvokeRequired testen, das ist einfach sauberer Stil. Gibts iwelche Anhaltstpunkte, dasser das nicht kontrollieren kann?

Und ein Invoke, wenn InvokeRequired false ist, führt zu einer Ausnahme, nicht zu "bisserl langsamer" laden. Naja, das müsste ich mal probieren.
Ich verwende nie Control.Invoke, sondern wenn, dann Control.BeginInvoke.
Und heutzutage auch das nicht mehr, sondern die Progress<T> - Klasse.
Bei Control.BeginInvoke kommts nach meiner Erfahrung nicht zum Crash, mit der Progress-Klasse hab ich noch nicht probiert, hab aber auch keine Idee, warum die in sonem Fall crashen sollte.

Und meine Aussage ist nicht "na wenns crasht, hat er die Methode wohl falsch aufgerufen", sondern: "Wenn er sie falsch aufruft, soll es crashen".
Also wenn man unbedingt InvokeRequired testen will, dann um eine Exception werfen, die darauf aufmerksam macht, dass die Methode falsch aufgerufen wurde.

Die Routine ist nicht dafür vorgesehen, aussm MainThread aufgerufen zu werden, denn das würde das GUI stocken lassen (nehme ich mal an - ist das eiglich mal getestet worden?).
Wenn man sie dennoch aussm MainThread aufruft, ist das ein (vergleichsweise geringfügiger) Programmier-Fehler, aber wenn das nur einmalig im Form-Konstruktor erfolgt wird das keiner bemerken, es lädt halt bisserl langsamer.

Und wenn man dabei nicht auf InvokeRequired testet - dann passiert auch nichts schlimmeres: Dann delegiert der MainThread eben die UI-Aktualisierung an den MainThread.
Idiotisch, aber macht keinerlei Probleme.

Imo - wenn man unbedingt auf InvokeRequired testen will, dann soll man eine Exception schmeissen, falls es zutriftt - denn dann liegt wie gesagt ein Programmier-Fehler vor, denn die Methode ist nicht für Aufrufe aus dem MainThread vorgesehen.

Der Timer läuft im Main Thread.

Nicht [im NebenThread], wenn er dieselbe Methode zum Start einmal im Mainthread aufruft.

Hmm - als ich mich mittm System.Timers.Timer beschäftigt habe, da wars noch so, wie ichs hier behaupte:
Der Tick des System.Timers.Timer erfolgt im NebenThread - nicht im Gui-Thread.

Ich vermute, ihr verwechselt das mittm System.Windows.Forms.Timer, aber das ist halt ein anderer Timer.

nochmal aufgenommen:
Es ist nicht nötig, zu testen, ob InvokeRequired, denn du verwendest ja - sinnvollerweise - den Timers.Timer, und der tickt mit Sicherheit im NebenThread - da brauchst du nichts zu testen, das weisst du auch so.

Meine Wenigkeit hätte dir ja die Progress<T> - Klasse empfohlen, um vom NebenThread aus die Gui-Aktualisierung in den Gui-Thread zu delegieren.

Aber dann ging die Diskussion iwie durcheinander, und ich hab den Faden verloren.

Das sollte nur repräsentativ für die Kreise in dem Beispiel stehen bzw. eben das Control was an den Punkten dargestellt werden soll.){gray} ist mir schon klar.
Ich bin nur dafür, schrittweise vorzugehen.
Also erstmal überhaupt die 2-dimensionale Datenstruktur erfolgreich in entsprechend geschachtelten Listboxen anzuzeigen.

Erst wenn das funktioniert es weiter umbauen, dass das auch mit Itemspanel und Canvas etc klappt.

ins innere DataTemplate kannst du natürlich kein Viereck reinmachen - Viereck ist ja kein UIElement!
in ein DataTemplate muss ein Control hinein.
Das Control kannste dann evtl. ans Viereck binden.

Als Control nimm doch erstmal ein StackPanel mit 2 Textblöcken drauf, und die Textblöcke bindeste an Viereck.X, Viereck.Y - dann sieht man evtl. schoma was.

ja, aber was ist das

<MyControl X="{Binding X}" Y="{Binding Y}" />  

?

und nicht "vor dem Task machen", sondern der Timer ersetzt den Task.

ich sagte doch: Nimm einen Timer. Solls im NebenThread laufen, nimm einen Threading.Timer, oder einen Timers.Timer.
So Timer kann man einfach stoppen.
Bei Tasks muss man tatsächlich - wie du vermutest - vom Prinzip her einen Marker setzen, gegen den der Thread pollt - man nimmt dafür CancelationTokenSource Kannste zB im verlinkten Tut nachlesen - aber das ist unnötig kompliziert.
Nimm einen Timer, und stoppe den halt. Spart ausserdem Resourcen.

Du hast vollkommen recht. Das habe ich mir fast gedacht. Habe ich richtig verstanden, dass ein Timer auf UI Elemente zugreifen darf oder? Wenn es so ist, dann werde ich alle Tasks in meinem UserControl durch ein paar Timers ersetzen. Dadurch brauche ich keine async Methoden mehr! Es gibt verschiedene Timer.
Der WinForms-Timer tickt im Main-Thread.
Ist nun die Frage, ob die auszuführende Methode länger dauert.
Wenn nicht, dann brauchst du ühaupt kein Threading.

Wenn doch (und bei Abfragen an den ManagementSearcher befürchte ich das) könntest du einen Threading.Timer nehmen, der tickt im NebenThread.
Und dann musst du das UI-Updaten aber auch an den MainThread zurück-delegieren.
Früher wurde das mit Control./Dispatcher.Invoke gemacht (s. Abts Link) - heuer täte ich wie gesagt, dafür die Progress<T> - Klasse empfehlen.

Ein weiteres Problem mit Threading ist, dass du Vorkehrung treffen musst, dafür dass der User die Anwendung bereits geschlossen hat, und der Thread danach noch das UI updaten will.
Daher probier erstmal ohne Threading auszukommen - ein WinForms-Timer macht da kein Problem.