Aber warum willst du manuell das Event der anderen (AbcForView) auslösen?
Das ist sehr ungewöhnlich - Normal braucht man das nicht.

Wie kriege ich jetzt die AbcForView (also die Property im ViewModel die Geometrien berechnet) dazu, ihrerseits die auf die Änderung einzelner Properties eines Elements von AbcList zu reagieren? Auf etwas reagieren tut man üblicherweise, indem man das entsprechende Event abonniert.

Ah - du hast ja grad INotifyPropertyChanged implementiert - da täte sich doch anbieten, einfach das PropertyChanged-Event zu abonnieren, um zu reagieren, wenn eine Property sich ändert.
Weil INotifyPropertyChanged .PropertyChanged benachrichtigt (engl: to notify) einen doch, wenn eine Property geändert wurde.

ich muss gestehen, wenn ich mich zum dritten mal wiederholen muss, wird es mir üblicherweise zu blöd.
Wieso machst du nicht einfach mal, was ich dir empfohlen habe? (INotifyPropertyChanged implementieren)

ich kanns nur wiederholen: Deine Abc-Klasse implementiert kein INotifyPropertychanged - das ist das Problem, und das zu korrigieren ist die Lösung.

Dass die Benachrichtigung zwischen den Controls trotzdem funktioniert, ist ein eigenartiges Wpf-Spezial-Feature, von dem ich hab sagen hören, es erzeuge ausserdem Memory-Leaks.
Und wie du gemerkt hast: Auf codeseitige Änderungen kann es nicht reagieren.

Man kann allerlei Figuren in eine einzige PathGeometry reinstopfen - das kann man dann mit einem einzigen Path-Visual darstellen.
Ob das besonders performant ist, weiß ich nicht - aber glaub performanter als viele einzelne Visuals.

Ein anderer Ansatz wäre, ein UIElement zu beerben, und im OnRender-Override selbst iwas zu malen.

Jo, damit ist das Problem endlich hofflich korrekt identifiziert: Deine ABC-Klasse implementiert kein INotifyPropertyChanged, und feuert folglich auch kein PropertyChanged-Event, und folglich wird auch kein View geupdated via Databinding.

Wie gesagt: INotifyPropertyChanged ist ganz ganz grundlegend, und das musste iwie nachrüsten.
Konkrete Anleitung hab ich grad nicht auf Pfanne, weil ich verwende immer eine ViewmodelBase-Basisklasse, die INotifyPropertyChanged auf eine schon recht advanced Art implementiert.
Aber müsste sich eiglich googeln lassen.

Jetzt verstehe ich auch, was du vorhin meintest. Leider kann ich die Klasse der Objekte nicht ändern. Diese ist vorgegeben und wird auch so im Model verwendet. Verstehe ich nicht.
Wenn du das Programm schreibst, dann schreibst du auch die Model-klasse.
Aber egal, wer die Model-Klasse geschrieben hat - imo für eine Model-Klasse höchst ungewöhnlich, dass sie kein PropertyChanged-Event feuern kann.
Zur Not schreibst du halt einen Wrapper, der die fehlende Funktionalität halt dran-patcht.

Wpf funktioniert nicht ohne INotifyPropertyChanged.

wie kann eine OC Margin und PosX, PosY enthalten?

Eine OC enthält eine Liste gleichartiger Objekte, also alle Elemente haben den gleichen Datentyp - keinesfalls kann eine OC sowohl Margins als auch Positionen enthalten.

Welchen Datentyp haben die Elemente deiner OC?
Ist das eine Klasse, die du gecodet hast?
Kannst du davon den Code zeigen?

In meiner ObservableCollection für das DataGrid sind relative Positionen.... Das ist ungeeignet, denn "relative Positionen" haben kein NotifyPropertyChanged-Event.
In deiner OC sollten Objekte sein, die PositionsAngaben als geeignete Properties haben. Und die Objekte müssen das NotifyPropertyChanged-Event feuern, wenn eine dieser Properties changed.

ich hab bei sowas immer Schwierigkeiten zu folgen.
Ewa was verstehst du unter Geometrie, und Eigenschaften der Geometrie an eine OC zu binden?

Die Wpf Geometry-Klasse kannst du nicht meinen, die hat kein PropertyChanged-Event (oder?)

jdfs. wenns dich interessiert kannste mal gugge, was ich einstens mit Wpf-Geometry-Dinger gebastelt und gebunden hab: Linien, Figuren, Formen.

Was anneres, mit mehr Bewegung hier: Kein Pong

genau mit dem Problem "Auswählen aus vielen Items" beschaftigt sich auch mein Cp-Artikel: Coercing AutoCompletion
Ich hab da aber keine Lösung mit Threads, sondern die Daten müssen auch von vornherein in die AutoCompletionSource eingelesen sein.
Dann aber ist das von mir angewendete Prinzip sehr effizient.

ah - hier noch eine Weiterentwicklung, für Comboboxen: AutoCompletion advanced

Ein Beispiel eines Viewmodels zu posten ist meist nicht sinnvoll - bei Wpf müssen ja alle Elemente MainWindow, UserControls, MainViewmodel SubViewmodels - das muss ja alles zusammenpassen und aufeinander abgestimmt sein - sonst siehst du garnix.

Du kannst dir mal Grundlagen - MVVM-Anwendungs-Struktur angucken, das ist ein System, was funzt.
Es kommen da auch MainViewmodel, SubViewmodel, ucls und TabControls vor, aber dennoch wirds wahrscheinlich immer noch nur teilweise auf deine Problemstellung übertragbar sein.

Weil es ist ein Konglomerat eiglich unabhängiger Beispiele, während bei dir die Teile vmtl. in einem sinnvollen Zusammenhang miteinander stehen.
Aber guck ma rein, was draus lernen kann man wohl fast immer.

Bisher hatte ich die Helper-Klassen direkt unter dem Namespace "Helper" eingefügt. ... Jo, mir stellt sich auch die Frage, was das für Helper-Klassen sind.
Ich zB habe recht viele static classes, und darin lauter Extensions, die mir Funktionalität bereitstellen, der mir im Framework fehlt.
Das habe ich inzwischen in 3 Bibliotheken organisiert:

1. GeneralHelpers: enthält Extensions für allgemeine Dinge, für FileInfo, IEnumerable<T>, IComparable<T> und so Sachen.
   Aber es finden sich auch eigene Klassen darin, zB eine Klasse namens NotifyPropertyChanged, eine Basisklasse, die INotifyPropertyChanged implementiert.

2)WinFormHelpers: enthält viel Kram zum Umgang mit Controls, und vor allem auch viel zeugs für Databinding mit typisiertem Dataset und BindingSources

3. WpfHelpers: diverse Converter, ein verbessertes Grid, eine CommandMap-Implementation etc.

Bei mir heissen also die Bibliotheken "XYHelpers", und die Klassen darin heissen wie das was sie tun, wobei ich Extension-Sammlungen mit X-Postfix kennzeichne (zB CollectionX) sind ganz stumpf in die Standard-Namespaces eingeordnet.
Also meine Extensions für IEnumerable<T> lege ich natürlich in System.Collections.Generric, meine NotifyPropertychanged-Implementation liegt natürlich in System.ComponentModel, diverser Wpf-Kram in System.Windows.Input.

Also ich denke mir kein neues Namespace-Gebäude aus, sondern meine Helpers kommen da hinein, wo sie helpen.

Aber ist natürlich ganz gräßlich, so zu tun, weil widerspricht den Guidelines von Microsoft 8o !
Das einzige,was dafür spricht ist, dass ich bislang gut damit fahre, und immer weiß, wo ich meinen Kram zu suchen oder einzuordnen habe.

Und ich sag nochmal: Das betrifft nur Helperleins, also wirklich Kram, der eigenständig kaum Sinn ergibt, sondern nur im Zusammenspiel mit dem FW gesehen werden kann, und da diverse Umständlichkeiten des FW-Standard-Instrumentariums erleichtert.

Nu wäre ich interessiert, ob du irgendetwas nützliches Und was) aus unseren Hinweisen und verlinkten Tutorials entnehmen könntest, oder ob der Thread eiglich ganz umsonst war, und eiglich besser garnet gefragt hättest.

vlt kann ich dich ja für eine (nicht so) kleine Einführung in Databinding interessieren:
http://www.codeproject.com/Articles/1030969/Relational-Datamodel-for-Beginners
Es sind 3 aufeinander aufbauende Artikel - je nach auf welchem Stand du bist kannste vlt. auch was überspringen (aber überspring nicht zuviel!)

Wirklich was zu sagen kann ich nicht. Ausser: Ich würde so etwas nur machen, wenns absolut tödliche Gründe gäbe, die mich dazu zwingen, so etwas zu verzapfen:

..., an einer WPF-Applikation, in der die Controls und ihre Bindings zur Laufzeit in Code-behind erzeugt werden. Das ist so ungewöhnlich, und konträr zum MVVM-Pattern, dass ich fast vermute, niemand kann dir da mit persönlichen Erfahrungen zur Seite stehen.

ich verwende zum Einkopieren immer:
SolutionExplorer, Ordner-Contextmenü "Add existing item".

Da kümmert sich VS, dass die erf Dateien alle mitkommen.

Beim Kopieren von Code-Dateien von eim Projekt ins andere ist auch immer der Namespace zu beachten. Die kopierte Datei nimmt ja "ihren" Namspace mit, der im neuen Projekt wohl kaum bekannt sein dürfte.

Also ich weiß nix besonderes, nur was ich hier aus der Fehlermeldung lese:

ich kann mir vorstellen, dass im Connectionstring ein Dateipfad angegeben ist, der nicht gefunden wird.

Oder sonstwo inne SqlBase-Konfiguration muss eine Datei spezifiziert sein, die offsichtlich nicht gefunden wird.

Wie kann ich festlegen, dass z.B. weiß transparent dargestellt wirdl? Wie Latino andeutet: Tranzparenz ist Sache der dargestellten Bitmap.
Eine Bitmap unterstützt Transparenz, wenn sie pixelformat 32bpp hat (also 4 Byte pro Pixel, eines als Alpha-Kanal).
Dann geht

bmp.MakeTransparent(Color.White);

sorry - ich weiß halt auch nicht genau.
ZB das mit dem Verschieben ganzer Infrastrukturen per Drag&Drop von einem Stockwerk ins andere. Da war halt bisserl was an Logik zu implementieren, zumal man Räume verschieben wollte, aber auch Stockwerke (glaub sogar Häuser).
Erfordert Logik, dass man beim Draggen nicht die eine Art Knoten auf einen ungeeigneten Zielknoten droppen kann - sowas.
(Aber nagel mich nicht drauf fest)

Ja, solange die Model-Klassen einfach bleiben, braucht das Repository ja nur aus der Datei den Model-Baum zu bilden ("Umfüllung1"), der dann als ganzes vom Viewmodel abgerufen werden kann ("Umfüllung2").
Soweit kein Problem.
Nur wenn das View die Knoten iwie besonders präsentieren muss, und dafür spezielle Unterstützung aus den Knoten heraus braucht, dann kann man die Knoten nicht mehr als dem Model zugehörig betrachten.
Aber da muss lhyn was zu sagen, sonst ists eine Diskussion über ungelegte Eier.

hmm - wies aussieht komm ich mal wieder nicht recht klar, mit dem was ich dachte, aus dem anderen Thread gelernt zu haben.

Zunächstmal zur genaueren Erläuterung für die anderen:
Bei deiner Anwendung gehts um Gebäude-Automation, es gibt Häuser, Stockwerke, Räume, und in den Räumen Sensoren und Servos und Kram.
Das ist in einem baumartigen Modell modelliert, und soll auch im Treeview angezeigt werden, und der Treeview soll dann auch dolle Sachen treiben können, zB die Infrastruktur eines Stockwerks komplett ins nächste Stockwerk kopieren und so Scherze.

Zurück zu die Modell-Geschichte:
Also wie ich Latino verstehe befüllt sich das Model von Platte, und das Viewmodel befüllt sich vom Model.
Das ist auch relativ praktikabel - also die Umfüllerei ist ein annähernd 100%iger Overhead, aber stirbt man nicht dran.
Und wie gesagt ist machbar, solche Adapter / "Umfüllstationen" zu schreiben, die die Model-Struktur auslesen, und eine Viewmodel-Struktur draus basteln.
Und andersrum auch, also das ein Viewmodel in ein Model rückübersetzt wird.

Aber wenn mans noch einmal betrachtet, isses doch wieder BrainF...k:
Weil das Model hat keine Funktion - es ist nur eine Zwischen-Station zum letztendlichen Lesen/Schreiben des Viewmodels von/auf Platte. Schön - die Schichten wären so getrennt, aber nur zum Zwecke, dass die Schichten schön getrennt sind - einen weiteren Zweck kann ich nicht erkennen.

Aber vlt. bringt Latino (oder wer anders) ja noch eine Erklärung, die iwie doch nochmal Licht ins Dunkel bringt.

also afaik kann man einen Treeview kaum ohne HierarchicalDataTemplate betreiben.

Ich weiß auch nicht recht, was du unter "ViewModel abklatsch der Models" verstehst, was du nun vermeiden möchtest.

afaik - willst du einen Baum anzeigen, brauchst du ein baumförmiges Viewmodel.

na, guck dein erfolgreiches Binding an - da steht was von {x:static ...
Beim unerfolgreichen nicht.

mit volatile gehts einfacher und performanter.
Edit: ach - verwendeste ja.
Wozu dann aber der Lock?

(Und mit true muss man niemals etwas vergleichen - da kommt doch immer nur dasselbe bei raus.

https://www.vb-paradise.de/index.php/Thread/110889-Boolean-Vergleiche-und-bedingte-Verzweigungen/)

Hab grad ein simpleres Tut gebastelt:
https://www.vb-paradise.de/index.php/Thread/118250-Usb-Anschl%C3%BCsse-%C3%BCberwachen

Werd noch eine c#-Version basteln

ich denke nicht, dass du einen DataAdapter mitten inne Arbeit unterbrechen kannst, unter Erhalt des bis dahin geladenen.

Für sowas musste wohl DataReader nehmen, und Zeile für Zeile hinzufügen

Ich würde gerne mein DAtagridView, welches durch einen Analogen Eingang Daten erhält plotten.
...
Was mache ich falsch ? Du denkst in Steuerelementen, nicht in Daten.
Steuerelemente kann man aber nicht plotten - Daten kann man plotten.

Ich empfehle dir daher, dich mit Databinding zu beschäftigen, ich zB würde die Daten nicht in ein dgv tun, sondern in eine typisierte Datatable eines typisierten Datasets.

Daran kann man ein dgv binden.

Und - nun wird es interessant - ein ChartControl kann man ebenfalls daran binden - an dieselbe DataTable!

Ein Sample hab ich hier gebastelt:
https://www.vb-paradise.de/index.php/Thread/72114-Chart-Sample/?postID=581438#post581438

Ja, ja, ja - es gibt viele Gründe für Properties, man kann damit mehr machen als mit fields, Apis, natürlich, Interfaces, Databinding und und und.

Aber es gibt auch Fälle, wo absehbar ist, dass man nichts davon braucht.

Und nu widerspreche ich mir selbst auch bisserl:

Mit Properties ist man wohl so gut wie immer auf der sog. "sicheren Seite".
public fields (ggfs readonly) sind gelegentlich eine Abkürzung für wenn man weiß, was man macht.

Mir ist halt immer wichtig, dass man quasi wach bleibt, und sich von patterns weder einschüchtern lässt, noch sich von ihnen das selber denken abnehmen lässt.

Ich "vermenschliche" Patterns iwie quasi als hohe Autoritäten, was die äussern hat großes Gewicht, und ich setze mich damit auseinander, um zu verstehen, was sie wollen.
Programmieren tu ich dann aber selber, und manchmal auch in Abweichung.

Hihi - habichs nicht gesagt?

Ach noch ein schlimmeres gibts: Alle Programmierer hacken auf eim rum, wenn man sich untersteht, ein public field zu verwenden.

Der verlinkte Artikel argumentiert ebensogut auch für das Gegenteil: Manchmal machts überhaupt nix aus, auch mal ein public field zu verwenden.

Bestimmte Sachen kann man dann halt damit nicht machen.

Das schlimmste, was eim passieren kann, ist, dass mans später vlt. umändern muss in eine Property, wenn man die bestimmten Sachen dann doch braucht.
(Wobei manchmal aber sogar absehbar ist, dasses nie auftritt)

Ach noch ein schlimmeres gibts: Alle Programmierer hacken auf eim rum, wenn man sich untersteht, ein public field zu verwenden. 😉

Ich finde BindingSources auch nicht überflüssig.
Ich binde einfach standardmäßig daran - so hab ich einheitliche-Funktionalität, und ist egal, ob ich dgv, Combobox, Listbox oder EinzelControls dran hänge - die eigliche Datenverarbeitung programmiere ich immer (naja, hauptsächlich) einheitlich gegen BindingSources.
Ich denke, grad bei 10000 Datensätzen werden Themen wie Sortierung, Filterung aktuell, und BS ist ~~ wie ~~ geschaffen dafür.

Ich kann ja mal versuchsweise auch mein Senf abgeben.
Sehr Gefallen habe ich an dieser klaren Aufgabenstellung (ich habs halt gern konkret):

Da müssen aus einem ASCII-File das in der Steuerung abgearbeitet wird, Parameter abgeändert werden. Dazu muss ich das ASCII-File aber erst aus der Steuerung auf die Festplatte des Maschinen-PC kopieren, dann die Parameter auswerten, darstellen (in View) damit sie der Bediener anpassen kann, dann wieder auf die Festplatte zurückkschreiben und in die CNC zurück kopieren. Für mich wäre erste Aufgabe, ein Datenmodell zu konstruieren, was die Verhältnisse einer Cnc-Steuerung abbildet.
Und zwar habe ich ein Faible dafür, relational-datenbänkerisch zu denken, also in Begriffen von Entitäten und Beziehungen.
Nu hab ich keine Ahnung von CNC, vermute aber, es gibt an Entitäten vlt.
Werkzeug
Werkstück
Bearbeitung
CncProgramm

Eine Bearbeitung stelle ich mir vor als den zeitlichen Einsatz eines Werkzeuges am Werkstück
Bearbeitung ist also eine Art Zuordnung von 1 Werkstück zu 1 Werkzeug - relational gesehen also beiden untergeordnet
Ein Programm ist eine Liste von Bearbeitungen, also den Bearbeitungen übergeordnet.

Ich komme also zu so einer relationalen Beziehungs-Struktur, die meine 4 Entitäten verknüpft:

CncProgramm => Bearbeitung
Werkzeug => Bearbeitung
Werkstück => Bearbeitung

Das wäre bei mir das Model, und das würde ein Cnc-Programm abbilden (nee, sogar mehrere - jede Entität entspricht ja einem Datentyp, und davon kann man viele Objekte instanzieren).
Das Modell wäre allein der Realität verantwortlich, auf Erfordernisse einer evtl. Präsentation braucht es keinerlei Rücksicht zu nehmen (bei mir darf es das aber, also Sortierbarkeit, NotifyPropertyChanged etc sind doch was nettes).
Und ein DataProvider (or whatever) müsste geschaffen werden, um aus einer Ascii so ein Modell auszulesen, bzw. so ein Modell wegzuschreiben.

Als nächstes muss man sich ein View überlegen, wie man was von dem Model anzeigen will und für Manipulationen verfügbar macht.
Optimalerweise kriegt man das ganz abstrakt komplett auskonzipiert, das wäre dann das Konzept des Viewmodels.
Und dann muss man was basteln, um die Model-Objekte ins Viewmodel rein/raus - zu transferieren.
Das kann auch sehr einfach sein, weil wenn die Model-Klassen zur Präsentation geeignet sind, kann man sie ja direkt in Listen des Viewmodels einfüllen.
Also verstößt nicht gegen MVVM, wenn das Viewmodel Model-Klassen enthält, sodass letztendlich der View via Databinding direkt die Anpressdruck-Property einer Bearbeitung-(Model-Instanz) erhöht oder sowas.

Was haltet ihr davon?
Also meine(?) Kern-Ideen:
Das Model modelliert die Realität einer Cnc-Steuerung (und vmtl. wird das relational modelliert sein müssen)
Das Viewmodel modelliert die Fensterle und was darauf herumfährt. Falls opportun darf es dabei auch Model-Klassen integrieren, ansonsten muss es halt spezielle VM-Klassen verwenden.
Mindestens eine spezielle Viewmodel-Klasse gibts immer, schon allein um für Buttons/Menüs eine Basis bereitzustellen.

Und es entstehen 2 "Umfüll-Stationen"

Ascii <=> Model
Model <=> Viewmodel

sobald dies eintritt, blockiert die GUI extremst. in dem mainform-text entscheind die schöne nachright "not responding", gui friert ein, zunächstmal ist ein dgv mit 10000 Zeilen vollzustopfen nicht nett.
Welcher arme User soll sich das übrigens angucken?

Dann geht die dgv-Performance gerne extrem in den Keller, wenn man Spalten mit AutoSizeColumnMode.AllCells oder sowas ausgerüstet hat.
Weil da bei jeder Zufügung/Entfernung werden alle Spalten-Werte erneut vermessen.

Paradox finde ich, dass du von DataTable befüllen redest, BindingSource, und zusätzlich auch das dgv befüllt.
Bei Databinding befüllt man kein dgv.

In deim Fall scheint ein Dialog vorzuliegen - das ist ein Spezialfall von SubForm, den man besser ohne Event implementiert.

Zeige die SubForm einfach mit .ShowDialog() an, dann ist das Hauptform so lange blockiert, bis das Subform schließt.
Und dann gehts genau da weiter, wo .ShowDialog() aufgerufen wurde.

Von der Kapselung her, und vonne Benutzer-Sicherheit das bestmögliche Design, und einfach ists obendrein.

In Vorüberlegung zur Form2Form-Kommunikation: Programm-Design überdenken , im "PasswordForm" ist das auch vorgeturnt zum Downloaden.

hübsch! 👍

spiel damit mal rum Jo, zB das Canvas kann man weglassen.

JSon (wie übrigens Xml auch) ist numal keine Datenbank, sondern ist ein Textformat.
"kleine" Datenmengen, so bis 20MB, evtl. auch 50, oder 100, liest und schreibt man damit performanter, und frisst auch weniger Platte als eine Db.
Dabei wird aber immer die Datei neu geschrieben (weil afaik sequentielles Beschreiben einer Datei technisch sehr aufwändig ist).

Und bei ieiner Größe wird eine "richtige" Db dann doch performanter.

Aber Frage: Auf wieviele Datensätze glaubst du je zu kommen? Weil ein Benutzer kann kaum jemals so viele Datensätze eingeben, dass eine Db wirtschaftlicher würde als eine JSon-Datei.
Ich spreche von 10000 - 100000 Datensätzen.

Es gibt übrigens ein anderes Kriterium, welches eine Db dann doch erzwingt, und das ist die Multi-User-Fähigkeit. Solch kann von Textformaten prinzipiell nicht abgedeckt werden.

Ich für mein Teil empfehle übrigens immer typisierte Datasets, und die als Xml zu persistieren (was bei dene eingebaut ist).
Damit hat man eine relationale, databindingfähige, typisierte Technologie im Client verfügbar, etwas, was sonst nur OR-Mapper leisten können (und die sind halt immer an Dbs gekoppelt).
Guggemol das Code-Sample von
typed programming the typed Dataset - for Beginners and others
was man damit so alles treiben kann, höchst übersichtlich, und mit minimalem Aufwandt.
(und / oder gugge hier inne Snippets: Kleine Datenverarbeitung DatasetOnly] )

Dann hast du ihn wohl nicht richtig verstanden.
bist du dem Link mal gefolgt, und hast das entsprechende Video dir angeguckt?
Evtl. auch das Sample gedownloaded und probiert?

Weil mit begrenzter Anzahl hat "DetailView" nix zu tun.

sone Darstellung mit vielen beschrifteten Pictureboxen wird sehr schnell ziemlich mühsam.
vlt. kann ich dich zum "DetailView" überreden?
Damit kann man eine Liste mit Artikel-Daten haben, und den man auswählt, davon das Bild wird schön groß angezeigt..

gugge "DetailView" auf http://www.vb-paradise.de/index.php/Thread/94955-die-vier-views-auf-video/#post798777

Ansonsten hätte ich noch ein ImageListview, aber das geht nicht so schön mit Databinding.

Also ich für mein Teil würde diese Meta-Diskussion eiglich lieber beenden.
Ich war wohl bisserl krass in meiner Kritik der Fragestellung, insbesondere fürs "Geschreibsel" möcht ich mich entschuldigen.
rasswet, du hast vmtl. noch nicht das dicke Fell, oder die Taktik, kleinere Entgleisungen zu ignorieren, ja und wenn man immer feste zurück-feuert, dann schaukelt sich das schnell auf, und die Inhaltlichkeit geht gänzlich unter.
Also meine Form bitte ich zu entschuldigen, täte aber empfehlen zu versuchen, meine Inhalte trotzdem aufzufassen - ich hab ja ziemlich viel geschrieben, zu 4 verschiedenen Themenbereichen.

Bis dahin können wir die weitere Unterhaltung einstellen. Wie du wolle.
Ist ja egal, ob du mich blöd, arrogant oder sonstwas findest, es wird sich einfach erweisen, obs stimmt, was ich bezüglich Begrifflichkeiten, Kommunikation und Konzeption gesagt hab.

wie dem auch sei - Performance ist hier garnet das Thema.

Sondern der TryCatch wird (ausser Folge-Fehlern) nix bringen, denn er kann die Exception ja garnet behandeln.

Hat auch niemand gesagt "TryCatch einbauen", sondern empfohlen wurde, den Fehler bewusst zu reproduzieren, einfach, um die Theorie, worans liegt, zu erhärten.

Zum Problem: von einem Unterprogramm aus einer selbsterstellten Klasse aufgerufen, sollte ab "TRUE-Werden" einer bool-Freigabe-Variable eine Zeitverzögerung gestartet werden. Am besten sollte es möglich sein über eine Int-Variable? die Zeitdauer einstellen zu können. Ist die Zeit abgelaufen, so sollte eine andere Ausgangs- bool-Variable den Wert "TRUE" annehmen und zwar solange die Freigabe besteht, sonst "FALSE". Erlischt die Freigabe während die Zeit noch läuft, so sollte der Ausgang gar nicht "Wahr" werden, es sei denn die Zeit wird durch erneute Freigabe irgendwann wieder gestartet und abläuft. Tja, so eine Problembeschreibung ist ziemlich untauglich.
Kein Mensch (ausser du) kann sich unter "TRUE-Werden" oder "bool-Freigabe" etwas vorstellen. Und wenn doch, dann höchstwahrscheinlich etwas anderes als du.

Imo gibt es 2 Arten, wie man ein Problem beschreibt:1.unter Verwendung definierter Fachbegriffe - das taugt meist nur, um über optimale, spezielle Algorithmen zu reden 1.Frei vonne Leber weg den Sinn und Zweck erläutern, also im Grunde, was der User erlebt, wenn er vorm fertigen Programm sitzt.. Hierbei sollten og. Fachbegriffe grad nicht auftauchen.

Also was ich mir zusammenreime aus deim Geschreibsel ist folgendes:
Es gibt iwie ein Dingens, das hat 2 bool-Werte, "Ausgänge", die können true/false annehmen. Ich nenne die Ausgänge mal "IsDelayRunnig" und "Open".
Im Urzustand sind beide false.
Wenn gestartet, wird zunächstmal IsDelayRunnig auf true gesetzt.
Wenn die Delay-Zeit abgelaufen ist, wird IsDelayRunnig false, dafür aber Open true.

Soweit korrekt?

Falls ja, hätte ich noch weitere Fragen, weil das Konzept ist so unfertig, bzw. sogar fragwürdig (imo sollte man statt des Open-Ausganges ein Event verwenden)
Ohne diese "soweit korrekt?" - Frage zu beantworten kanns imo also garnet vorangehen mit der Problemlösung

Aber ich sag gleich:

Habt auch Verstendnis dafür, dass mir die ganzen "members", "Delegate", Schlüsselwörter in deren Bedeutung auch nicht viel sagen. Das funktioniert mittelfristig nicht.
Wenn du c# programmieren willst/musst, dann musst du die Fachbegriffe erlernen, ansonsten ist gar keine Kommunikation möglich.

Hier habich mal eine schlampige Zusammenstellung von Fachbegriffen gemacht, von denen ich gemerkt hab, dass sie oft unbekannt sind: [Edit: Link entfernt - besteht wohl kein Interesse]
Die Erklärungen sind in vb.net erläutert, aber Gültigkeit haben sie auch in c#.
Und wie gesagt: es ist schlampig und kann das Lesen eines Fachbuches bei weitem nicht ersetzen.

Jo, mittels einer rekursiven Suche, die die Tiefe mit-berücksichtigt.
Oder besser vlt. eine BFT, eine "Breath-First-Traverse" - das ist die iterative "Konkurrenz" zur Rekursion, unbekannter, aber nicht minder leistungsfähig.

guggemol das "Bäume durchlaufen mit Rekursion"-Tutorial hier inne Artikel-Rubrik.

Hier ist eine Verschnellerung, weil iwie system-näher: https://www.vb-paradise.de/index.php/Thread/108606-Rekursive-Dateisuche-in-Net-4-5/?postID=939576#post939576

Aber dauert immer noch merklich Zeit.

Möglicherweise musst du den Code nur bisserl anders aufrufen als bislang. genaurers kannich nicht sagen, ich weiß ja nicht, wie du ihn aufrufst.

Eins darf aber wohl gesagt werden: Mit so unverstandenen Snippets aus dem Internet kommt man zu nix.

Grad im Bereich Wpf musst du wirklich c# erlernen, und dich darüberhinaus mit dem MVVM-Pattern bekannt machen.

(Dann kommt man auch garnet mehr auf die Idee, die Textboxen eines TabControls auf "0" setzen zu wollen.)

der Datentyp des einzelnen Verses ist ein primitiver, ein String.

Strings kann zwar als ganzes angezeigt werden, aber String hat keine Property, an die gebunden werden könnte (sondern string ist die Property)

Um aber per Binding in ein Objekt zu wirken, muss das Control an eine Property gebunden sein.

Oder ganz anders ausgedrückt: Der BindingPath "." ist readonly.

Lösung: richte eine Vers-Klasse ein, mit einer string-Property Value oder sowas.

Wie gesagt: Ich bin sehr gespannt, wie ein "Komplett-Anfänger" sich in Wpf einfinden wird.
Dein Einstieg ist imo denkbar schlecht: ZeitDruck macht dich für Quick&Dirty empfänglich.
Darauf hebt Latino auch schon ab, aber ich muss noch ein BonMot dazu loswerden:
"The problem of Quick and Dirty is, that the Dirt remains, while the Quick is long gone."

Und das ist noch nicht alles problematische am q&d, weiters besteht noch die Gefahr, es immer wieder zu reproduzieren, weil entscheidende Lernschritte ausbleiben.
Also q&d ist für Anfänger nochmal so brisant, weil sie daduirch Anfänger bleiben.

Und noch ein: lass dir ein gutes c#-Buch empfehlen, insbesondere eines, was auch einen Schwerpunkt auf die Arbeitsweise des VisualStudios legt.
Wenn man das VS nicht kennt, gleicht man einem 6-jährigen im Leitstand einer Fabrik: ungeahnte Möglichkeiten, aber leider ungeahnt.
Kleinen Einblick kann hier dieses Tut mit Video verschaffen:
https://www.vb-paradise.de/index.php/Thread/84166-VisualStudio-richtig-nutzen-Google-ist-nicht-deine-Mami/?postID=691374#post691374
Also die Sprache lernen aus einem Buch, aber gleichzeitig und zusätzlich muss auch das Werkzeug gelernt werden, mit dem man dann arbeitet.

Übrigens noch zu Latino: Ich glaub hier ist die Rede nicht von einem Datagrid, sondern von einem Grid.

Mir scheint es aber eine Wpf-Frage, und da haut das Vorgesagte in mehrfacher Hinsicht nicht hin: Zum Einen sind Wpf-Buttons was ganz anderes als WinForms-Buttons, zum anderen sollte man Wpf von Beginn an nur über den MVVM-Pattern nutzen, also mit Databinding an Viewmodel-Klassen.
Ich hab hier mal ein einfaches Beispiel produziert, was einigermassen die Struktur und Denkweise von Wpf aufzuzeigen versucht:
https://www.vb-paradise.de/index.php/Thread/115475-MVVM-Anwendungs-Struktur/?postID=1005812
Hier gibts ein weiteres, was sich insbesondere mit dem Setzen von Bindings beschäftigt - sogar als Video:
https://www.vb-paradise.de/index.php/Thread/83442-MVVM-Binding-Picking-im-Xaml-Editor/

Ich muss aber sagen, mein Stil ist umstritten, weil ich mir meist eine Trennung von Model und Viewmodel spare.
Insbesondere auf diesen Streit ist hier focussiert: Die Diskussion ist sehr lang, als Einstieg würde ich den Post empfehlen, wo ich mein Sample einführe:
Binding eine Spalte von einer DataTable
Etwas später legt Latino einen Gegenentwurf vor, in Gesamtheit kann man glaub sehr viel rausziehen.
Hier noch einer der GründerVäter-Artikel, ebenfalls mit Sample-Code, sogar auf Deutsch:
https://msdn.microsoft.com/de-de/magazine/dd419663.aspx

Du wirst aber feststellen, dass Wpf für Anfänger sehr sehr schwierig ist.
Glaub ich jdfs., und wäre interessiert, ob ich das richtig einschätze. Wissen tu ich das nicht, denn ich hatte wie die meisten eine lange "Vor-Schule" in WinForms.
Und wie gesagt, bin ich neugierig, wie sich Wpf wohl lernt, wenn man das nicht hatte.

Zu Wpf musste dir auch klarmachen, dass 2 Sprachen zu lernen sind, die verschiedener nicht sein könnten: c# und Xaml.
Aber das siehste dann ja.

Wenn man faul ist, kann man sich oft auch das "durchreichen" sparen:
Weil wenn zB iwo eine NullReferenceException auftritt - wieso die dann catchen, und Re-Throwen? (was anderes kann "durchreichen" ja nicht bedeuten)
Sie fliegt doch auch so, und wenn sie den Fehler genug genau bezeichnet, muss man nichtmal durchreichen, sondern kann sie einfach fliegen lassen.

Aber das hängt von der konkreten Implementation ab.