In diesem Wpf-Tutorial hab ich ja eine CollectionView vorgestellt, die die User-Selection hereinholt ins Viewmodel.
Hier jetzt gehe ich noch einen Schritt weiter, und verstoße richtig gegen den MVVM-Pattern: Ich hole mir nämlich ein Control selbst ins Viewmodel . Ich hab da irgendwie keine Moral: wenn ich die Tastendrücke, die an ein Control gesendet werden, verarbeiten möchte, dann brauche ich den Eventhandler im Viewmodel.
Man kann da nun iwas umständliches reißen, mit einem Attached Behavior, wo das Event empfangen wird, und was dann iwas ans Viewmodel sendet - aber imo ist das nur eine verkomplizierende Verschleierung desselben: Nämlich, dass im Viewmodel Control-Events verarbeitet werden.
Also ich habe für solche Fälle ein Universal-AttachedBehavior - nenne ich VisualSubscribe, weils dazu da ist, dass im Viewmodel Visual-Events abonniert werden (subscribe).
Die Anwendung sieht ganz harmlos aus:Im Viewmodel lungert dann eine Action(Of Object)-Property rum, an die das VisualSubscribe gebunden wird, und die genau dann genau einmal aufgerufen wird, wenn die Bindung erfolgt:Also im Bindungs-Moment wird die Property aufgerufen, und kann dann das _ItemsControl setzen (meine .Be()-Extension übernimmt den notwendigen Cast). Und weils WithEvents ist, kann ich alle dessen Events verarbeiten .
Aber vlt. sollte ich erstmal erzählen, wasses werden soll: Ich will eine Spielfläche haben, und darauf sollen Objekte herumfahren, deren Bewegungen vom User gesteuert werden.
Das Viewmodel der Objekte ist super-banal - einfach ein Dingens, was seine X/Y-Position angeben kann:
Das Mainmodel nun enthält viele solcher Dingense in einer ObservableCollection:Und man sieht auch, wieso ich die Tastendrücke haben will: nämlich um die Position des fokussierten Moveables (um StepSize) zu verändern (zeilen#23-#26).

Und wie ist im Xaml daran gebunden?Tss! - einfach ein ItemsControl (also eine abgespeckte Listbox)!
Und im .ItemTemplate (#13-#17) ist an garnix gebunden - da wird einfach nur ein Standard-Button generiert, für jedes Moveable einer.
Aber das listige ist das .ItemsPanel (#2-#6): Das ist nämlich ein Canvas - also ein Panel, was die enthaltenen Controls nicht von oben nach unten aufreiht (wies bei einer Listbox normal wäre), sondern im Canvas wird jedem Control einzeln eine X/Y - Position zugewiesen, also Canvas.Left/.Top, um genau zu sein.
Dummerweise nützt es nix, die Buttons im DataTemplate zu positionieren, denn die sitzen gar nicht direkt auf dem Canvas auf, sondern die Buttons liegen jeweils in einem ItemContainer, und der liegt im Canvas.
Also muss der ItemContainer positioniert werden - nicht der Button im DataTemplate. Die ItemContainer (es sind ja viele - für jeden Button einer) sind beim ItemsControl vom Typ ContentPresenter, und beeinflussen kann man die nur über einen Style (#7-#12), den das ItemsControl dann auf jeden ItemContainer anwendet, wenn die Daten-Präsentation generiert wird.

Uff!!
Dann aber ist lustig, weil: (fast) fertig.
Also das ItemsControl ist funktional immer noch eigentlich eine Listbox, nur es sieht überhaupt nicht mehr wie eine Listbox aus, weil die Items darin ganz beliebig angeordnet sein können, und sich sogar bewegen!

Aber wir haben noch ein Problem zu lösen, nämlich die Z-Reihenfolge.
Denn natürlich soll ein Item nach vorne kommen, wenn mans fokussiert - wie geht das? Naja, im ItemsControl werden die Daten-Präsentationen genau in der Reihenfolge generiert, die die Auflistung im Viewmodel vorgibt - das letzte Item wird also zuoberst dargestellt. Also muss man im Viewmodel einfach das angeklickte Item nehmen und an die letzte Stelle verschieben - dann kommt im View seine Präsentation (hier: der Button) nach vorne - Code:Das .GotFocus ist ein RoutedEvent, und zwar mit RoutingStrategy.Bubble. Das heißt: wenn man auf einen der Item-Buttons klickst, empfängt zuerst der dieses Event. Aber er leitet es weiter, an seinen Parent, den ContentPresenter. Und der leitet es noch weiter ans Items-Control, und so kommts am Ende hier heraus. Und mit meiner e.OriginContextAs()-Extension kann ich den DataContext von e.OriginalSource abrufen - den DataContext des geklicksten Buttons - mit anderen Worten: dasjenige Moveable, auf dessen Daten-Präsentation geklickst wurde .
Ja, und der weitere Code moved das Moveable an die letzte Position in der ObeservableCollection - ist nett, oder? - die hat extra eine Methode zum Verschieben von Elementen, und via Databinding benachrichtigt sie auch das ItemsControl.

Es ist übrigens noch ein zweites Projekt dabei, bei dem ich die Moveable-Class um ein Speed-Feature (zeile#26) erweitert hab:Speed ist ein Vector, und im Mainmodel die Tastendrücke ändern nun nicht mehr direkt die Position des Moveables, sondern sie ändern seinen Speed, und zwar in X- oder Y-Richtung.
Weiters gibts dort einen Timer, der alle 30ms die Move()-Sub aufruft, und dadurch wird die Position geändert.

Also Pong2 ist viel lustiger, da kann man wirklich alle Buttons und in jede Richtung herumsausen lassen.
(aber nicht zu schnell machen, sonst kannstese kaum noch anklicksen, zum abbremsen!)

Kein Pong
Übrigens - mancher hats wohl schon gemerkt: Die Anwendung ist kein Pong.
Pong-Grundlagen sind vlt. gelegt, aber ich scheitere an den physikalischen Berechnungen, wenn ein bewegtes, rundes Objekt auf die Ecke eines bewegten, rechteckigen Schlägers auftrifft.

Edit: Bitte glaubt mir - die Physik dazu ist ziemlich kompliziert - also Vorschläge dazu sind mir sehr willkommen, möchte ich aber nicht hier im Tutorial diskutieren.
Am liebsten wäre mir, wenn jmd, der das gebacken kriegt, die Source dann im SourceCodeAustausch veröffentlicht, oder auch gleich ein Tutorial.

Ich habe jetzt - in einem 3. Projekt innerhalb derselben Solution - ein klein wenig Kollisions-Behandlung eingebaut.
Nämlich jetzt gibt es Bälle und einen Schläger, der kontinuirlich hin und her-wandert. Basisklasse beider ist Moveable.
Der Schläger interagiert aber noch nicht mit den Bällen, sondern bislang ist nur die Kollision der Moveables gegen die Wandungen implementiert:(Übrigens, _Location bezeichnet den Körper-Mittelpunkt. Deshalb taucht an versch. Stellen _HalfSize auf, um die Körper-Grenze zu bestimmen)

Im Mainmodell sind Bewegen, Kollidieren und GuiUpdate nun getrennte Vorgänge:Das eröffnet die Möglichkeit, in einem "Frame" für jedes Moveable alle Kollisionen abzuarbeiten, welche auftreten können.
Wie man sieht, sind bislang Kollisionen zw. Moveable und Wandung (betrifft also den Schläger auch), und zusätzlich für Bälle Kollision zw. Ball und Schläger vorgesehen.
Wie gesagt: Bei der Schläger-Kollision passiert noch nichts - ich stelle hier nur die ich denke optimale Vorlage bereit, und hoffe, dass jemand, der mit Kollisions-Mathematik besser zurande kommt als ich, da "eben mal" die fehlenden Berechnungen einfügt.
Dazu sind keinerlei Wpf-Kenntnisse nötig, die vorgelegte Methode kann sich ganz und einzig darauf konzentrieren, beim Überlappungs-Zustand der beiden Körper des Balles Location und Speed zu ändern, sodass

1. der ungültige Überlappungszustand behoben ist
   
2. der Geschindigkeits-Vektor auf Physikalisch-ähnlich geändert ist
   

Ich sag "Physikalisch-ähnlich", weil das Modell (bislang) sehr grob vereinfacht:

• Massenverhältnisse zu berücksichtigen ist bislang nicht vorgesehen: Die Masse eines Balles wird als klein, die der Wandungen und des Schlägers als nahe unendlich angenommen.
  
• keine Reibung: weder bei Bewegung im Raum, noch bei den Kollisionen.
  
• Demzufolge auch keinen "Spin" der Bälle.
  

2-dimensionaler Stoss
Uih - die letzten beiden Tage hab ich mich doch nochmal in die Physik verbissen, und glaub immerhin das Problem des 2-dimensionalen elastischen Stosses prinzipiell gelöst.
Damit ist der Fall gemeint, dass ein Ball un-mittig getroffen wird, bzw. dass Bälle aus verschiedenen Richtungen aufeinander prallen, und so nicht nur ihre Geschwindigkeit ändern, sondern auch die Richtung. Und verschiedene Massen und verschiedene Radien.
Also da brauchts eine kleine "Physik-Engine", weil ich muss graden Stoss können, versetzten Stoss, und sogar den Schnittpunkt einer Kreis-Sekante.
Letzteres ist nötig für das allergemeinste Problem, nämlich die Korrektur des Kollisions-Punktes.
Weil eine Kollision detected man anhand der Überlappung der Körper, und somit immer einen Tick zu spät. Daher muss man aufwändig vom vorgefundenen Punkt mit Überlappung zurückrechnen auf den Punkt, an dem die Kreise sich grad berührteten Jetzt ballern die Bälle gegeneinander - aber der Schläger interagiert immer noch nicht.
Wie gesagt: Wer Lust hat...

(Update in Post#1)