Suchergebnisse

Zitat von KaskadekingDE: „var slideTimeSpan = new TimeSpan(0, 0, 0, 0, slideTimeSpan);“Diese zeile kann unmöglich kompilieren.

Die "WPF-Methode" wäre übrigens, MediaElement.Position an Slider.Value mit einem entsprechenden Converter zu binden, genau dafür wurden Bindings in WPF geschaffen und son Rumgepfusche im Codebehind führt dieses Konzept ad Absurdum.

Gebunden wird an Properties im DataContext, also (hoffentlich) deinem ViewModel, nicht an Properties anderer Controls. Leg in deinem ViewModel eine neue Propertie vom Typ Timespan an, implementiere INotifyPropertyChanged korrekt dafür und binde dann das MediaElement und die TrackBar mit Mode=TwoWay daran.

Das ist soweit richtig, du solltest dein ViewModell aber noch als Singletone implementieren, etwa so: C#-Quellcode (12 Zeilen) Dann musst du das ViewModel als DataContext für das Window festlegen (damit wird dann automatisch der DataContext für alle Controls gesetzt): XML-Quellcode (1 Zeile) local ist der Namespace deiner Anwendung, in dem sich u.a. das ViewModel befindet. Wenn du jetzt Bindings setzt wird dir der Editor die Properties des ViewModels als Path anbieten.

Ja klar static, hab ich später noch rein editiert.

Du hast den Namespace, in dem sich das ViewModel befindet, definiert und dann neu kompiliert?

Den Converter hast du doch oben schonmal gesetzt, solltest doch eigentlich wissen wies geht. Einfach als Ressource verfügbar machen und dann als StaticResource dem Binding zuweisen. Beim Mediaelement bindest du logischerweise die Position-Eigenschaft.

Das wusste ich nicht. In dem Fall musst du dir wohl selbst eine DependencyProperty erstellen. Ich hab dir einfach mal ein Beispielprojekt angehängt.

Die Audiosource hat ja nichts mit dem View zu tun, von daher kannst du die einfach über das ViewModel steuern, wenn sich die Eigenschaften ändern.

Ergibt für mich jetzt irgendwie keinen Sinn. Die AudioSource hat mit dem View nix zu tun und muss deshalb auch dem View nicht bekannt gemacht werden. Die Audiosource gehört zu den Daten der Anwendung und muss von der Logik (dem ViewModel) angesprochen werden.

Das ViewModel muss die AudioSource instanzieren und bei Meldungen aus dem View (Commands oder Änderung von Eigenschaften) entsprechend reagieren? Wie machst du das denn aktuell? Hast du die AudioSource etwa in der MainWindow-Klasse erstellt?

Naja ich hab ja gesagt, was jetzt zu tun ist. Jegliche Logik muss ins ViewModel wandern, im Codebehind des MainWindows darf nur Code stehen, der alleine das View betrifft. Sachen wie Start und Stop, die du wahrscheinlich auch haben möchstest, werden in Form von Commands, die ebenfalls das ViewModel bereitstellt, an die entsprechenden Controls gebunden, Events kommen hier nicht zum Einsatz. Dort kannst du dann alles tun, was du möchtest, unter anderem auch die entsprechenden Aktionen an der Audio…

Kannst du schon so machen, halte ich nur für etwas viel Aufwand. So wie hier tuts auch schon: codeproject.com/Articles/238657/How-to-use-Commands-in-WPF Die RelayCommand-Klasse gibts leider nur mit TeamFoundation, aber du kannst sie dir selber ganz einfach anlegen. (Versteckter Text)

Zitat von KaskadekingDE: „Der Code ist wahrscheinlich nicht der schönste“Also ich finde der ist absolut in Ordnung, kannst du so lassen.

Das wird etwas komplizierter. Du musst mehrere Commands mit einem Button ausführen, dafür muss du Commands gruppieren können: codeproject.com/Articles/25808…ommands-with-CommandGroup Der zweite Command wäre dann aber kein RelayCommand, sondern ein RoutedCommand, das per CommandBinding an das MediaElement geleitet wird. Da ist es dann ganz praktisch, dass du sowieso schon ne neue Klasse dafür hast.

Ich kann auch bei Gelegenheit ein Tutorial über Commands für die Tipps & Tricks schreiben, falls das gewünscht ist.

Das ist die konkrete Implementierung für das Beispiel-Command dort. Wenn dein Command das nicht braucht (wovon ich mal stark ausgehe, denn das ist speziell für das Focusen einer Textbox), dann kannst dus natürlich weglassen.

1. Schwer zu sagen. Ich könnte mir vorstellen, dass es etwas mit der Reihenfolge der Commands in den Groups zu tun hat oder auch mit der Reihenfolge, in der der Commandmanager die Commandbindings und die RelayCommands updatet. Da musst du mal etwas rumprobieren. 2. Du hast doch Value an eine Property im ViewModel gebunden. Wenn also die Sliderposition geändert wird, wird der Setter dieser Property aufgerufen.

Ja, genau dafür sind Setter doch da, um etwas zu setzen.

C#-Quellcode (1 Zeile) v liegt zwischen 0 und 1, wenn du das in einen Ganzzahlwert umwandelst kann nur exakt 0 rauskommen, das Audio fängt also wieder von vorne an. Ich meine, bei CSCore konnte man auch gleich mit TimeSpans arbeiten.

Kann ich mir vorstellen. Liegt daran, dass das Mediaelement durchgehend die Position verändert und dann quasi ein endloser Strom an Positionsneusetzungen an die Audiosource kommt. Da müsstest du gegebenenfalls für das Mediaelement und den Slider zwei verschiedenen Properties anlegen und zwischen denen so delegieren, dass die Position der Audiosource nur gesetzt wird, wenn die Änderung vom SLider aus kommt, nicht vom Mediaelement.

Du bindest Slider.Value an eine Property und MediaElement.Position an eine andere. Die Position der Audiosource wird nur gesetzt, wenn sich die Property, an die der Slider gebunden ist, geändert wird. Dann musst du nur noch bei Änderung der einen Property die andere setzen, allerdings über das Backingfield, nicht über den Setter, weil ansonsten eine Endlosschleife ausgeführt wird. Nicht vergessen, dann auch PropertyChanged für die jeweils andere Property aufzurufen.