es geht darum, dass Konstruktoren einen Sinn haben. Ein Konstruktor macht nichts anderes, als Variablen zu initialisieren oder Instanzen zu erzeugen. Programmiertechnisch gibt es keinen Unterschied. Das wäre bei dir jetzt so ein Fall, wo man sagen kann, dass man hierfür Konstruktoren verwenden sollte. Das ist auch üblich so.
gibt es eine sichere Möglichkeit ein WPF Fenster immer aktiviert zu halten.
das verstehe ich so, dass er ein "TopMost" haben möchte.
Zitat von david.ka
Ich meine damit nicht unbedint TopMost, es sollte ständig auf Befehle (in meinem Fall, von der Fernbedienung) reagieren, auch wenn andere Programme geöffnet werden.
Hierfür gibt es sicherlich eine API.
So verstehe ich das. Falls ich es falsch verstanden habe, nehme ich meine Antwort zurück. Er hat sein Vorhaben auch wirklich sehr oberflächlich beschrieben. Ich weiß nicht, wo das Verständnisproblem liegt.
um tallas Beitrag zu ergänzen: Such mal nach DataContextSpy von Josh Smith. Die Klasse wird dir weiterhelfen können. Siehe auch Artificial Inheritance Contexts in WPF.
ich sehe das so, dass die Generic.xaml nicht erkannt wird. Du hast du Datei nirgends angegeben. Also passiert auch nichts. Versuch mal den Code aus der Generic.xaml in die App.xaml zu packen. Dann sollte es eigentlich funktionieren.
die Grundlagen müssen gegeben sein. Da dafürt kein Weg dran vorbei. Hast du mal gegoogelt(oder gebingt)? Du findest in englischensprachigen Foren meist die selben gestellten Fragen. Deine Frage ist sichersich auch dabei und samt einer Antwort. Das als Tipp am Rande.
in WPF gibt es Methoden zur Sortierung. Du kannst auch deinen eigenen Sortierer programmieren. Wenn du trozdem LINQ verwenden möchtest, dann filter einfach die ObservableCollection.
beides falsch. Er möchte mit den Interactions von Blend arbeiten. Das ist sein Problem. Klar, man kann das auch so lösen, das erfüllt aber nicht die Frage.
Das Problem ist, dass die Funktionen aus dem Blend SDK nicht built-in sind. Die wurden nachträglich veröffentlicht. Die lassen sich wunderbar in WPF integrieren. Das ist kein Problem. Man sagt dem Control, dass es dieses und jenes Verhalten annehmen soll. Was du aber haben möchtest, ist, dass in einem Style das vorhanden sein soll. Warum das jetzt nicht built-in ist, kann ich dir leider nicht sagen. Das Problem hierbei ist, dass der Setter nicht darauf zugreifen kann, weil einfach das Property der TextBox(allen Controls) fehlt. Jetzt stehen wir da und wissen nicht weiter. Und genau das ist auch dein Problem.
Schreib dir eine Helferklasse, in der die Attached Property drin sind. Über diese machst du dann einfach den Umweg. Dann sagst du, dass du über diese Klasse Behaviors füttern möchtest. Der Typ des Attached Properties ist natürlich auch von Behavior. Die OnPropertyChanged-Methode setzt dann alles richtig um. So kannst du dann in .Value sagen, was du haben möchtest.
schreib direkt einen Parser. Dann bist du auf der sicheren Seite. Mit RegEx würde ich das nicht lösen, weil es an einigen Stellen "unsicher" ist. Wenn du direkt einen Parser verwendest, kannst du viel einfacher auf die Inhalte zugreifen oder auch nach Inhalten suchen. Du hast dann feste Objekte in der Hand. In RegEx musst du alle manuelle machen. Schau mal auf den Seiten von CodeProject oder CodePlex. Dort findest du bestimmt was.
du kannst den logischen Tree hoch und runter laufen. So kannst du dann auf die Controls zugreifen. Voraussetzung ist, dass du es richtig filterst, sondern bekommst du Probleme. Besser ist es natürlich, wenn du direkt den Controls Namen gibst, sodass man die Control dann besser identifizieren kann. Hier findest du ein gutes Beispiel.
Das, was du vor hast, ist nicht gut! Lies dich ermal lieber in WPF ein, bevor du anfängst. In WPF gibt es viel mehr Möglichkeiten. Die sollte man auch ausschöpfen.
das MVVM-Pattern ist sehr flexibel. Man kann ein Problem auf mehreren Arten lösen. Der eine macht das so, der Andere so. Das Problem ist einfach, dass man sich fragen sollte, wie man es am besten umsetzt. Das ist jedenfalls meine Meinung dazu.
So wie ich das sehe hast du das Problem, dass du eine Kommunikation zwischen den ViewModel brauchst. Ein Mediator oder EventAggregator würde das lösen können. Du könntest noch einen Schritt weitergehen und die ViewModels durch einen IoC/DI-Container leiten. Die ViewModel kannst du dann auch ein Stück weit abstrahieren. So kansnt du dann sagen, ob du eine neue Instanz oder die gleiche Instanz(Singleton, Monoton) haben möchtest.
Beachte bitte, dass es mehrere Herangehensweisen gibt. Darauf möchte ich jetzt nicht weiter drauf eingehen, sondern dich auf diesen Arikel aufmerksam machen. Dort ist es ganz gut beschrieben. Wie genau hast du das bei der zweiten Frage gelöst?
Für mich sind deine Aussagen/Fragen zu schwammig und sehr oberflächlich. Kannst du ein konkreteres Beispiel nennen? Beispielcode wäre auch ganz nett.
deine Frage ist sehr oberflächlich. D.h. kann ich auch nur sehr oberflächlich antworten. Ich persönlich würde dafür Behaviors einsetzen. Die Behaviors sollen dazu dienen, dass das Standardverhalten der Panels richtig in die ViewModel weitergeleitet werden. Du programmierst dir also die entsprechenden Behaviors und leitetest dann die An- und Abfrage ins ViewModel. Die Behaviors sind also nur "Zwischen-Dinger". Beider Kommunikation würde ich einen EventAggregator und/oder einen Mediator verwenden.
wir greifst du auf die ObservableCollection zu? Wenn du über _infos zugreifst, aktualisiert sich zwar die ObservableCollection, aber nicht die UI. Greif auf die Infos zu, da du auch an diese dran bindest.
ohne den Code jetzt zu testen, behaupte ich mal einfach, dass es mit den logischen und visuellen Tree zusammenhängt. Was ich glaube, ist, dass WPF das nicht auflösen kann, weil entweder Base nicht von DependencyObject erbt und/oder es keine Freezables sind. Schau dir mal Artificial Inheritance Contexts in WPF und DataContextSpy an. Steht bei dir was im Output-Fenster?
du kannst ViewModels in ViewModels schachten, das ist absolut kein Problem. Was du wissen musst, ist das es mehrere Möglichkeiten gibt, ein ViewModel darzustellen. Der einfachste Weg wäre dafür ein DataTemplate zu schreiben. Hier findest du einen sehr guten Einstieg in das MVVM-Pattern. Dort sind auch alle Möglichkeiten übersichtlich aufgelistet.
Du sagtest, dass du nur in C# programmierst. Du bist gewissermaßen gezwungen, in XAML zu programmieren! Ich verstehe deine Aussage nicht. Kannst du näher drauf eingehen?
Das PropertyChanged-Event implementiert du nicht direkt in einem ViewModel, sondern in einer Basisklasse. Es ist doch unsinnig, wenn du für jedes ViewModel von INotifyPropertyChanged implementierst und immer den Handler programmierst. Dies ist unter anderem auch in dem Artikel sehr gut beschrieben(s. oben).
Mehr oder weniger ist MVVM keine Richtline, sondern ein Pattern, also im Sinne von "du kannst es so oder auch so machen". Das Pattern ist sehr flexibel, es gibt also keinen "richtigen" Weg. Es mag mehrere Wege geben. Welchen du nimmst, bleibt dir überlassen.
kannst du ein wenig Beispielcode posten? Das, was du uns veruscht zu beschrieben, ist sehr oberflächlich. Ich denke, dass es an den Focus Scope liegt. Versuchs mal hiermit.