ich denke, "UserControl" und "in einer Dll veröffentlichen" passt nicht zusammen.

UserControl ist etwas für ein bekanntes, komplexes Viewmodel, ist also ein Control, was in der Hauptanwendung zu gestalten ist, nicht in Dlls.

In Dlls gehören Controls, die an primitive Viewmodels binden, und sowas sollte man auch eher als Control ausführen, nicht als UserControl.
Betrachte mal die Controls, dies gibt, etwa Textbox, Textblock bindet an String, DateTimePicker an DateTime - sowas sind sehr primitives Viewmodels.

Erzähl doch bischen mehr, was das Control soll, evtl. kann man auch mit einem schicken Style für HeaderedContentControl was reissen - kommt ganz drauf an.

Variable viele Messstellen und variable viele Messungen in einer Tabelle - das kann man als Kreuztabelle auffassen.
Hab ich neulich mords was kompliziertes gecodet, mit IPropertyDescriptor-Objekten.

Hmm, sorry, mehr Hinweise hab ich grad keine Zeit für, und ist auch ziemlich vertrackt.

Das ist vlt. leichter gesagt als getan: "Evaluiere WebService".
Mir scheint nicht mal klar genug, was damit eiglich gemeint ist - rum-googeln?

oder "einfach anschauen" - wo bitte gehts zum WebService-Zoo? Ich würde mir gerne einen mit hinterlegter Datenbank anschauen. 😉

Zeige ich jetzt aber in einer DataGrid die Rows zweier Tabellen an, die mit einem Join verbunden sind kann ich nicht mehr eindeutig feststellen, welche row sich geändert hat. Naja, vermeide es halt, mit Join verknüpfte Tabellen von der DB abzurufen.
Ansichten, die mehrere Tabellen kombinieren (Joins) kann man auch auf andere Weise bereitstellen.
Diese - ich nenne sie "JoiningViews" bieten sogar weitere Möglichkeiten, die definitiv über das hinausgehen, was ein Sql-InnerJoin leisten kann.

Aber ich hab nur Beispiele mit typisierten Datasets dazu, und Abt wird glaub schon ungeduldig, wann du endlich deinen Webservice aufsetzst 😉

viele Picboxen ist oft bisserl problematisch. Meist will man dann auch was auswählen, und da ist dann wieder Aufwand zu treiben etc.

Eine vergleichsweise einfache Möglichkeit ist, Bilder in einer ListView zu präsentieren:
https://www.vb-paradise.de/index.php/Thread/113775-ImageListView/

ah - aber da versteh ich auch nicht recht, warum er meint "alles" (was immer damit gemeint ist) neu laden zu müssen.
Er sagt doch selbst, der sqlDependancy-Mechanismus informiert ihn über genau die geänderte Row.

Dann sollte es auch reichen, diese nachzuladen.
Ansonsten schiene mir das clientseitige Datenmodell iwie unzulänglich, wenn man da auf einzelne Änderungen mit Daten-Massen-Abruf reagieren müsste.

Nur bin ich noch nicht ganz zufrieden, da ich noch eine Lösung für verknüpfte Tabellen brauche. Nun weiß ich zwar welche Tabelle sich geändert hat aber muss trotzdem alles neu laden oder mergen um auch hier den aktuellen Stand anzeigen zu können. Versteh ich nicht.
Alle Tabellen sind doch (üblicherweise) miteinander verknüpft, was meinst du nun speziell mit "verknüpfter Tabelle"?
Und wieso musst du alles neu laden, wenn du in einer (verknüpften) Tabelle (nicht wahr, sind ja alle verknüpft) was änderst?

Kann es sein, dass du iwie ein ungeschicktes clientseitiges Datenmodell hast?
Weil wenn ich was ändere, dann zunächst im Datenmodell, und dann ist es da geändert, da muss nix neu geladen werden.
Und wenn ich dann abspeicher, ja, dann stehen die Änderungen auch in der Datenbank.
Aber deswegen muss ich auch nix neu laden (ausser die db-seitig generierten Primärschlüssel im Falle von INSERTs)

kommt drauf an.
Wenns besser ist, sie direkt im DG zu editieren, dann sollte man sie direkt im DG editieren.
Andernfalls einen Edit-Dialog verwenden.

Fühle mich sehr geehrt, dass du mir zutraust, Methoden zu verbessern, die ich garnet kenne, aber leider muss ich dich enttäuschen - das kann ich nicht.

Aber ich kann dir ein EF-Sample liefern: https://www.vb-paradise.de/index.php/Thread/112373-EntityFramework-CodeFirst-Sample/
Und das kannst du Code-First weiter-entwickeln (zB ieine Property zufügen), und wenn alles gut geht, updated sich die DB dabei mit.
So steht es jedenfalls im Tut, was ich dir in post#2 verlinkt habe.

ich denke, man muss nicht die ganze tabelle laden.
Man kann bei Änderungen doch einen Timestamp im Datensatz hinterlassen, dann braucht man nur den Datensatz mit dem aktuellsten Timestamp abrufen.

vlt. kann man auch iwas mit Triggern basteln, also dass es in der DB eine ChangeLog-Tabelle gibt, die Angaben macht, welche Datensätze kürzlich geändtert wurden.

ich verwende gerne typisierte Datasets.
Da kann man dann mittels CommandBuilder DataAdapter konfigurieren, die je Tabelle alle 4 abdecken: Select,Update,Insert,Delete.
Auch hat ein Dataset eine Änderungsverfolgung, sodass man eine zentrale Methode coden kann, die jegliche Änderung erfasst, und in einem Rutsch updated, sogar für alle Tabellen.

Auch kann man dann mit Databinding arbeiten, sodass man in den Genuss einer sehr leistungsfähigen Anwendungs-Architektur kommt.
Den letzten Punkt halte ich für die Hauptsache, und ich empfehle immer, Anwendungen erst ohne Datenbank zu entwickeln, und sich dabei das Thema Databinding zu erschließen.
Weil wenn man zu früh eine DB integriert, kommt was raus wie hier: wo der Datenzugriff von vornherein vereitelt, dass ein klares clientseitiges Datenmodell überhaupt konzipiert wird, und Databinding ist so natürlich auch unmöglich.

also wenn du dir den DatasetOnly-Ansatz mal angucken willst:
http://www.codeproject.com/Articles/1030969/Relational-Datamodel
es sind 3 aufeinander aufbauende Artikel.
Und am Ende steht eine kleine databinding-getriebene Anwendung, allerdings ohne Datenbank.
Aber da noch eine Datenbank nachträglich zu hinterlegen ist vergleichsweise pillepalle, denn einem Dataset ist es völlig schnurz, wie es befüllt wird.

irgendwie irrsinnig kompliziert, findeste nicht?
Das ist jetzt ja nur das Ändern eines Task-Datensatzes, für Abrufen, Hinzufügen und Löschen muss derselbe Sermon jeweils ja nochmal gecodet werden, so ähnlich.

Und evtl. gibts auch noch eine Client-Tabelle in der DB, also das ganze ganze nocheinmal.

Und jede weitere Tabelle ebenso...

kannst du das sicher sagen?
Ich denke, es ist nichtmal so einfach, das richtige Feld überhaupt zu identifizieren.

Dazu müsste man 2 SpeicherVersuche machen: einen erfolgreichen, und einen, der den Fehler reproduziert.

Kannst du die Codes davon zeigen?

Naja, vlt. sollte ich mich auch raushalten - ich habe noch nie so einen Fehler gehabt, und kann ihn auch nicht reproduzieren. Die Meldung mit dem "Genauigkeitswert" macht mich auch misstrauisch - ich weiß nicht, ob mit "Genauigkeitswert" wirklich die Länge des Strings gemeint ist, oder ob sich das nicht auf die Genauigkeit eines Fliesskomma-Typs bezieht.

egal. evtl. ists auch deine AddWithValue-Methode, die da iwas verdaddelt, probierma stattdessen, die Parameter richtig zu klonen:

      public static bool Execute(String SqlCommand, List<OdbcParameter> parameters = null) {
         OdbcCommand odbcCommand = new OdbcCommand();
         odbcCommand.Connection = _odbcConnection;
         odbcCommand.CommandText = SqlCommand;

         if (parameters != null)
            foreach (OdbcParameter parameter in parameters)
               odbcCommand.Parameters.Add((OdbcParameter)((ICloneable)parameter).Clone());

         odbcCommand.ExecuteReader();
         odbcCommand.Dispose();
         return true;
      }

möglicherweise ist das Feld in der Datenbank so konfiguriert, dass es nur eine begrenzte Anzahl Zeichen aufnehmen kann.

Dazu müsste man wissen, wie das Feld in der DB konfiguriert ist, also welchen Datentyp es hat.
Und hier ist der Access-Datentyp gemeint (char, nchar, varchar, nvarchar, memo, ...), eine Datenbank hat ja recht viele verschiedene Darstellungsformen für das, was im Framework einfach ein String ist.

man kann scheints mit EF-Code-First einiges reissen, auch Update-Migrations-mässig.

Hier Tutorial: http://www.entityframeworktutorial.net/code-first/entity-framework-code-first.aspx

Aber jedes denkbare Aktualisierungs-Problem ist damit sicherlich auch nicht lösbar.

ja - iwo habich das neulich auch in einem MSDN-Artikel erwähnt gefunden - weiß aber nicht mehr welchen.
Ging iwie um Initialisierung von Anwendungen.

Das "in die Doku schauen" ist garnet mal so trivial - vlt. kann ich hier mit meim Tut ankommen: [Tipp] Schau in die Doku! - Möglichkeiten der Informationsgewinnung

Sofern ich "SizeToHeader", "SizeToCell" oder "Auto" nutze, erscheint eine weitere Spalte beim Maximieren, was ich aber nicht möchte. Die Lösung besteht vmtl. darin, dass eine Spalte - und zwar die mit dem breitesten Inhalt - auf * zu setzen ist - alle anneren auf SizeToCell, Auto oder wasses da gibt.

Also ich verwende für sowas gerne ein TabControl, wo ich die Reiter zur Laufzeit ausblende.
Weil ein TabControl ist ja im Grunde genau das: viele übereinander liegende Panels.

Weiß grad nur Sample in vb:
https://www.vb-paradise.de/index.php/Thread/71491-TabControl-ohne-Reiter/?postID=584025#post584025

ach - hier: TabControl als Basis für Assistenten und sowas

aber gugge trotzdem auch den vb-Link, denn der enthält bereits eine Lösung mit Treeview als Navi-Panel

vlt. willst du auf die Geometry.FillContains()-Methode hinaus?

was verwendest du denn als Report-Technologie?
Ich kenne es so, dass man den Report an eine DataTable hängt - das hat eiglich mit der DB garnix zu tun.

Die DataTable kann man sich dann aufbauen wie wolle, und auch nach belieben befüllen.

mir erscheints am logischsten so:

<TextBlock Text="{Binding Converter={StaticResource EthernetOptionConveter}}" />

Also wenn man keinen Path angibt, gibt man ihn halt nicht an (folglich auch kein Komma hinmachen).

Es ist übrigens kein Self-Binding, das wäre was anneres.
Sondern "Datacontext-Binding", oder "Total-Datacontext-Binding" wären evtl. treffendere Bezeichnungen.

Viel Zeit kann ich da jetzt nicht investieren. ok - an dem Punkt geb ich auf.
Meiner Ansicht nach muss man sich die Zeit nehmen, die man braucht - das ist die schnellste Vorgehensweise, bereits mittelfristig.

Hier zum beispiel hast du deinen Mischmasch-Ansatz bereits so weit vorangetrieben, dass du glaub allein stehst.
Weil beim Versuch, da jetzt im Codebehind Progressbars zu generieren und in richtiger Weise ins Datagrid einzufrickeln - dabei kann dir evtl. keiner helfen, denn in Wpf geht man halt anders vor.

Und es ist wirklich DevComponents?

Weil die haben eiglich nicht son schlechten Ruf, und werden auch viel verwendet, also das wäre schon wichtig zu wissen.

andererseits - 2008 - gut möglich, dasses bei denen längst gefixt ist in aktuellen Versionen.

Ich denke, du musst deine Anwendung komplett neu konzipieren, und dich zuvor überhaupt noch in die Prinzipien einarbeiten, nach dem man Wpf-Anwendungen konzipieren sollte - ich rede vom MVVM-Pattern.

Einer der ersten Schritte ist ein Umdenken im Kopf, dass man aufhört, über Controls wie Datagrid, Progressbars etc. nachzudenken, sondern sich der Strukturierung der Daten zuwendet.

Oder anders: Denken über Controls beantwortet die Frage "Wie kann ich etwas anzeigen?"
Denken über Daten beantwortet: "Was will ich überhaupt anzeigen".

Und es hat numal keinen Sinn, sich mit dem "Wie anzeigen" auseinanderzusetzen, wenn die Frage "Was anzeigen" nicht geklärt ist.

Aber MVVM ist ein umfangreicheres Thema, wie gesagt: zum einen muss man DatenModell-Klassen erstellen, zum andern muss man die Binding-, Style- und Template-Mechanismen kennenlernen, die Wpf zur Verfügung stellt.
Und eine gewisse Anzahl weiterer "Tricks" muss man auch kennen, die einem das Leben erleichtern (bzw. erst erträglich machen).

Interesse?

Jo, Databinding.

Nun muss man sich klar machen, dass man dafür auch ein Datenmodell braucht. Also wenn man keine Klassen hat, an die man bindet, gehts halt nicht.

Hab ich 3 Artikel zu auf Codeprojekt veröfflicht - dieses ist der erste: http://www.codeproject.com/Articles/1030969/Relational-Datamodel

Das Geheimnis besteht darin, dass aus diesen vielen kleinen Linien im Endeffekt eine Kurve entstehen soll. Leider darf ich die dafür vorhandene Funktion nicht nutzen, sondern soll diese durch eine rekursive Funktion selbst implementieren.

Es handelt sich um eine Übungsaufgabe, die an einige Vorgaben geknüpft ist 😉 Tja, solche Übungen, bei denen man lernt, das, was dafür da ist, nicht zu benutzen - also finde ich ja von sehr sehr zweifelhaftem Lern-Wert.

Und es geht eigentlich auch garnet.
OwnerDrawing sieht vor, dass du deine Zeichnung vorbereitest, und sie dann jederzeit abrufen kannst.
D.H. wenn das iwie kompliziert zu zeichnen ist, führt man das nicht bei jedem Abruf aus, sondern, man macht das einmal, und speichert die Figur dann in einem GraphicsPath, den man dann ja jederzeit - zack! - hinmalen kann.

Na, egal, dann musst du halt rekursiv dein Point-Array erstellen, und wenns zum Zeichnen kommt, mit Graphics.DrawLines() ausgeben - ist eiglich genauso gut.

Wie gesagt: Wenn die Daten der Figur sich ändern, dann wird die Zeichnung vorbereitet - sie wird noch nicht gezeichnet, sondern vorbereitet. Normale Menschen würden einen GraphicsPath vorbereiten, aber zur Übung kannst du halt ein Point-Array vorbereiten.
Hauptsache vorbereitet, und wenn die Zeichnung angefordert wird, kann sie mit Graphics.DrawPath() / .DrawLines() hingeschmissen werden.

Wichtig ist auch, das Neuzeichnen eigenständig anzufordern, wenn die Daten sich ändern, die Figur also neu zu zeichnen ist. Das kann man schön optimieren, indem man nur den Bereich neu zu zeichnen anfordert, wo sich auch wirklich was ändert. Die Methode ist die Control.Invalidate(Rectangle)-Überladung, wo man genau das Rechtech angibt, sodass nicht die ganze Oberfläche zu erneuern ist.

Dazu ich ein Tut gebastelt:
"Gezieltes OwnerDrawing" - schnelles Zeichnen bewegter Objekte

ich versteh den ganzen Vorgang nicht.
Also du hast ein Datagrid, dann hast du wohl auch eine Auflistung von Addressen.

Wieso willst du dann nur eine Addresse abspeichern?
Und was machst du, wenn du eine Addresse löschst? Oder wenn eine bestehende geändert wird?

Also In meiner Welt würde man die Addressen bearbeiten nach Belieben, und dann alle auf einmal abspeichern.
Also alle, die geändert, gelöscht oder hinzugefügt wurden, unveränderte würde man natürlich nicht abspeichern.
Dieses zu unterscheiden ist Aufgabe des sog. ChangeTracking - EF sollte das draufhaben.

Also laden, was man will, ändern was man will, und dann ein einziger Aufruf: objectContext.SaveChanges(), und alles ist in trockenen Tüchern.

jo, immer auf ein Control malen.
Dann kannst du auffm Form immer einen Platz auch freihalten von Gezeichnetem, wo man iwelchen anderen UI-Kram plaziert.

mach doch iwas bei

            if (notifyCollectionChangedEventArgs.Action == NotifyCollectionChangedAction.Move)

ist das nicht insgesamt sehr unpraktisch, ein ListenControl zu haben mit 1000 Bildern drinne, in so großem Format?

Ich würde dazu neigen, die mit Namen zu präsentieren, und als ThumbNails, und wenn man dann eins anklickt kriegt mans in einer beigeordneten Picturebox in groß präsentiert.

und in diesem DGV zeigst du jetzt Bilder größer 250*250 an?

hier ein Tut mit Videos zum Thema Layout in WinForms.
https://www.vb-paradise.de/index.php/Thread/80559-Layout-in-Windows-Forms/?postID=802148#post802148

Geht weit über die Frage hier hinaus, aber imo sollte man sich mit dem Instrumentarium auf jeden Fall sehr gut auskennen.
Eine schlecht gelayoutete Anwendung ist ein Gräuel, und "ist das Aushängeschild für schlechte Programmierer" - findich immer.

Das mit dem Scrollbalken regelt man iwie über die ScrollableControl.AutoScrollMinSize - Eigenschaft. Hab ich mal gemacht, aber vergessen, wie.

ah - hier: http://www.activevb.de/tipps/vbnettipps/tipp0081.html
aber das ist auch bischen begrenzt.
Die ZeichenFläche des Controls wächst ja beliebig an, nur bei ca. 160000000 Pixeln steigt iwann GDI aus.
Ups - sorry. Das Sample hat Scrollbalken, weil eine übergrosse Picturebox auf einem Panel liegt - das ist ein anderer Weg, zu Scrollbalken zu kommen.

Ich würd aber vorschlagen, dreh die Probier-Reihenfolge mal um:
Ehe du versuchst, eine Bild-ListenControl selbst zu programmieren, probier doch einfach mal den Tipp mit der ListView aus.
Listview hat alles, was du bisher anfragst, eingebaut:
zufügen, löschen, scrollen, selectieren, ToolTips.

Beim Selberbasteln liegst du bislang nicht so daneben, was dein OwnerDrawing-Verständnis angeht 👍, aber nur OwnerDrawing macht noch kein Bild-ListenControl.
Mausposition zuordnen (auch bei gescrolltem Control), Selektionen sichtbar machen, Selectionen auch verwalten, und und und... das zieht sich ganz schön in die Länge.

Also dreh die Reihenfolge um: erst Listview probieren, und wenn das nicht zusagst, kannste dich ja immer noch mit OwnerDrawing verkünsteln.

mit Konzipieren muss man glaub anfangen.
Als erstes Input - Output klären.

dieses "Etikettenbild" - was ist das für ein Datentyp?

Dann überlegen, was mit "einen designer darüber zu legen" gemeint sein mag X(

sehr schön kann man viele Bilder auch in einer ListView anzeigen, die mit einer ImageList verknüpft ist

guggemol https://www.vb-paradise.de/index.php/Thread/113775-ImageListView/

Die Grundversion kann man sogar ohne jeden UserCode hinhauen.

Und netterweise ist mit einer ListView ja auch gleich ein Selectier-Mechanismus gegeben.

eine Klasse auf die ich per Indexer zugreife und deren Elemente an eine DataGrid gebunden sind. ich wüsste nicht, dass man einen Indexer überhaupt an ein DG binden kann.

Evtl. ist garnet der Indexer gebunden, sondern die Klasse als ganzes ist gebunden? Solch ist ja möglich, wenn sie IEnumerable implementiert.

Also müsste man wissen, wie die Klasse gebunden ist, und was sie implementiert.

Weil ObservableCollection kann ja einzelne Elemente updaten, weil sie INotifyCollectionChanged implementiert.

Die obige Methode wird auch ausgelöst, wenn ich eine Zeile aus der Quell-Datagridview in die linke Senk-DataGridview bewege. Evtl. machste dann beim bewegen was falsch.
Weil afaik ists nicht zwingend, dass ein Bewegen automatisch ein CellValueChanged auslöst, auch noch im anderen DGV.
Auch verwirrt mich, dass du mal das rechte, mal das linke DGV als "Senke" bezeichnest.

ja, das ist der richtige Ansatz.

Problem ist nur, die Combo richtig zu konfigurieren.

Aber zunächstmal hast du sie ja im CellTemplate angelegt, da gerhört das nicht rein.
Editing gehört ins EditingCellTemplate.

Ich hab jetzt nicht jedes Element im Kopf (es waren glaub 4 Sachen, die richtig zu konfigurieren waren.

guckste mal in https://www.vb-paradise.de/index.php/Thread/112373-EntityFramework-CodeFirst-Sample/

Was meckert sie denn, die IDE?

achso - montag... =)

und mein Vorschlag, hast du den übersehen, oder gehst du davon aus, es interessiere mich nicht, ob er dir nütze war?
Da kann ich dich beunruhigen: es interessiert mich durchaus 😉

keine Ahnung.

Aber probierma einfach:

MyDataGrid.ItemsSource = dt;

(Wobei ich grad sehe, dass du scheints Wpf wie WinForms programmierst, also ich erahne da einen ziemlich schaurigen Stil)

hier 3 Artikel, die Databinding mit allem Drum und dran von 0 an entwickeln: http://www.codeproject.com/Articles/1030969/Relational-Datamodel

Vonne Optik her machen aber glaub meine Videos mehr her: vier Views-Videos Also das zeigt mehr das Spektrum der Möglichkeiten, allein davon zu lernen geeeht auch, aber man muss dann glaub sehr sorgfältig lesen und zugucken.

Der Db-Zugriff wird nur am Ende der Videos kurz erwähnt - wie gesagt: Was immer verkannt wird ist, dass die Datenbank in einer Datenverarbeitung nur eine Nebensache ist, austauschbar, die "Daten-Senke" halt.

Der dort gezeigte Ansatz verbaut aber von vornherein, jemals einen typisierten Datenzugriff zu erhalten, oder in Designern databinding-getriebene Oberflächen zu entwickeln.

Falls dich interessieren sollte, was das ist, sag bescheid, dann schmeiß ich dich mit Tutorials tot. 😉

ich bin zu faul, alle deine Fragen hier zu behandeln.
Zum Problemkreis habich paar Tuts verzapft - ist bestimmt einiges dir nützliches dabei:
https://www.vb-paradise.de/index.php/Thread/83442-MVVM-Binding-Picking-im-Xaml-Editor/
https://www.vb-paradise.de/index.php/Thread/115475-MVVM-Anwendungs-Struktur/?postID=1005812

also normalerweise (TrivialFall) sollte es so funzen:

<Button.Command>
  <Binding Path="CmdApplyPLCSettings"/>
</Button.Command>

keine Source angeben, dann gilt der geerbte DataContext.
funzt natürlich nur, wenn du dich auch im richtigen DataContext befindest.

Liegt der Kram in Resourcen, Styles, Templates, oder eingeschachtelt in Listboxen, ItemsControls etc., dann gilt evtl. ein anderer DataContext, also die Logik, wie der DataContext sich durch den VisualTree vererbt (und wasses da für Ausnahmen gibt) kann im Einzelfall nicht ganz trivial sein.

Also empfehle ich, probier erstmal mit wirklich trivialen Samples.

jou.

Nur wenn du den Datacontext jetzt nicht mehr im lokalen Xaml festlegst, dann können im Xaml-Editor Intellisense und PropertyGrid nicht mehr plausible Bindings vorschlagen.

Also falls du das Feature genutzt hast, und es nun vermisst, kannst du dir mitte d:DataContext - MarkupExtension behelfen - Interesse?

So, jetzt reden wir glaub über 3 oder 4 verschiedene Dinge, und keins davon kann ich testen - weiß nicht, obs euch da anders geht.

Also falls jemand sich die Mühe gemacht hat, eine Test-Solution für diese Fragen zu erstellen, wäre ich zumindest dankbar (ich weiß nicht, wie's den anderen geht), wenner die Sources hier anhängen könnte.

echt - da war SynchronisizeContext eingebaut?

Dann ist gut möglich dasses recht sauber ist, denn in WinForms geht Control.BeginInvoke intern auch über genau diesen SynchronisizeContext.
Und die SynchronisizeContext-Choose ist sauber nachm Strategy-Pattern aufgezogen, um verschiedene Präsentationstechnologien entkoppeln zu können.

Trotzdem ist gut möglich, dass ein Dispatcher deutlich bessere Leistung bringt - zumindest in WinForms muss man sich ja nicht grade überschlagen vor Begeisterung.

Es würde wahrscheinlich 5 Minuten brauchen selbst eine entsprechende Beispielumsetzung zu realisieren, wenn hier die App nicht ausführen kann. (OT: Solche Bemerkungen kriegen es immer wieder hin, dass ich das Gefühl hab, ich soll mich dumm fühlen.
Du schaffst es sicherlich in 5 Minuten, ich aber vermutlich nicht. Allein die fehlerwerfenden Funktionalität - das müsste ich erst konzipieren, aufsetzen, testen, korrigieren...)

Wenn es um das "Beweisen" geht...... Bingo! 👍 - es geht genau ums Beweisen.
Und ich sehe immer den Autor einer FAQ/Tutorial in der Beweispflicht, nicht den Leser.
Und bewiesen ist erst, wenns auf meinem System funktioniert, wie erwartet, und der Code auch sonst Tut-Aussagen bestätigt.

Beweis-Suche ist bei mir automatische Reaktion, und das hat mich tatsächlich erstmal von abgehalten, deinen Kernpunkt aufzufassen (ich kann halt nur eins nachm andern)

Und die Kernsache ist für mich die TaskFactory im entsprechend synchronisierten Kontext statt ein Dispatcher. Also pros und cons, die TaskFactory zu nehmen, wenn kein Dispatcher gegeben.

Da fällt mir tatsächlich was zu ein, sogar trotz misserfolgter Beweissuche - ist aber auch nix wirklich originelles:
pro:
Es funktioniert (nehme ich mal an). Das ist zunächstmal das entscheidende

con:
vermutlich wesentlich langsamer als Dispatcher.BeginInvoke. Ich hab bisserl IL gespickelt, Dispatcher macht was ganz anderes als TaskFactory.

Schlussfolgerung:1.Wenn verfügbar, immer den Dispatcher nehmen 1.vlt. kann man sich noch iwas ausdenken, einen Dispatcher iwie doch noch herzukriegen
Ich jdfs. akzeptiere nicht unbesehen, dass das ganz unmöglich ist, weil zumindest im Gui isser ja da.
Ist halt die Herausforderung, es mit möglichst wenig Kopplung hinzukriegen, aber für solch gibts ja einige Mechanismen und Pattern.

1.Testen.
Wie schlimm ist der Performance-Nachteil?