Welche Antwort erwartest du dir hier? Soll hier jemand das Konzept von DependencyProperties und WPF im Generellen für dich vorkauen? Vielleicht ließt du dir zuerst mal die Grundlagen dazu durch: DependencyProperties und stellst dann gezielt Fragen wenn du dich wo nicht auskennst.
Wenn du ein konkretes Problem hast, dann poste es auch und Frage gezielt nach einer Lösung.
Ich kann nicht erklären warum, aber irgendwie wird die View "wegrationalisiert" oder so und ist anscheinend im VisualTree nicht vorhanden weswegen sie mit RelativeSource nicht aufspürbar ist.
Was aber gehen sollte ist zuerst die ListView suchen und dann über die View Eigenschaft wieder runterhangeln:
Ich schaffs nicht auf nur irgendeine Weise deinen Fehler nachzustellen.
Was ist local:CPlainView für ein Control?
Ist ItemTemplate ein eigenes Property? Wenn ja wie definiert und wo und wie verwendet?
Lg, XXX
//PS: Der Fehler sagt eigentlich eh schon alles aus und drückt auch meine Vermutung aus: In deiner Objekthierachie ist anscheinend vom DockPanel bis zum Window rauf nirgends ein Element vom Typ CPlainView dazwischen. Zumindest bekomm ich nur in solchen Fällen diesen Fehler.
Leider verstehe ich noch immer nicht was du damit bezwecken willst. Ich kann mir nicht vorstellen in welchem Szenario ich eine generische Klasse brauche, die aber ein nicht generisches Interface implementiert.
Du musst darauf nicht eingehen. Ich kann nur nichts weiteres dazu beitragen da ich den Sinn und Zweck deines Vorhabens nicht verstehe.
Wenn es ausschließlich intern verwendet wird, kannst du ja auch einfach object verwenden? So wie ich das verstehe, willst du einfach die Handhabung mit dem Generic Constraints einschränken. Das machen die zwei Methoden auch. Wie du die Objekte intern behandelst ist dann wieder eine andere Geschichte.
Dumme Frage,
aber warum lässt Du das Constraint nicht ganz weg? Wenn eh alles als item übergeben werden kann. Allerdings sehe ich in diesem Konstrukt gar keinen Sinn, in Sachen Typsicherheit.
LG, Marko
Stimmt, du willst einschränken aber doch alles zulassen. Ohne Constraint funktionierts wunderbar:
Alternativ könntest du einfach ein Testprojekt schreiben in dem du einen Operator deklarierst und dich per Reflection und GetMethods zum Ziel durchhangelst?
Lg, XXX
//Edit: was aber nichts daran ändert, dass wenn deine Klasse irgendwo generisch verwendet wird, der Operator _nie_ greifen wird. Insofern ist es wohl sinnvoller das ganze mit der Operatorüberladung nochmals zu überdenken. Evt. ist deine Klasse besser als Struct implementiert bei dem automatisch beim Vergleich alle Member verglichen werden.
Das wird auch so nicht funktionieren. Wie du schon selbst irgendwo oben geschrieben hast, sind Operatoren statische Funktionen. Statische Funktionen unterliegen daher auch nicht den klassischen Vererbungsprinzipien sodass der Operator der in einer SubKlasse definiert wurde nicht aufgerufen wird, wenn er auf eine Basisklasse angewendet wird. Der Typ T in deinem Code ist abstrakter als der Typ der den Operator implementiert weswegen dieser nicht aufgerufen wird.
class Program
{
static void Main(string[] args)
{
Sub a1 = new Sub();
Sub b1 = new Sub();
Console.WriteLine(a1 == b1); //prints "Operator in Sub called: ..."
Test a2 = new Sub();
Test b2 = new Sub();
Console.WriteLine(a2 == b2); //prints "Operator in Test called: ..."
object a3 = new Sub();
object b3 = new Sub();
Console.WriteLine(a3 == b3); //prints "..."
}
}
public class Test
{
public static bool operator ==(Test test1, Test test2)
{
Console.Write("Operator in Test called: ");
return Equals(test1, test2);
}
public static bool operator !=(Test test1, Test test2)
{
return !(test1 == test2);
}
}
public class Sub : Test
{
public static bool operator ==(Sub test1, Sub test2)
{
Console.Write("Operator in Sub called: ");
return Equals(test1, test2);
}
public static bool operator !=(Sub test1, Sub test2)
{
return !(test1 == test2);
}
}
Lg XXX
//Edit: Ich denke das es auch eine schlechte Angewohnheit ist mit == zu arbeiten(wie ich es selber auch permanent mache) eben, weil == oft irreführend sein kann.
Scrollviewer hört auf MouseMove Events wenn zB linke Mouse Down und MousePosition > Rand dann Scroll um die Differenz und evt. setze MousePosition wieder zurück? sodass die Maus nie über den Rand raus bewegt werden kann.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Windows;
using System.Windows.Controls;
namespace WpfApplication2
{
public partial class MainWindow
{
public MainWindow()
{
InitializeComponent();
DataContext = new MyViewModel();
}
}
public class MySelectedValueTextBox : TextBox
{
public string SelectedValue { get { return (string)GetValue(SelectedValueProperty); } set { SetValue(SelectedValueProperty, value); } }
public static readonly DependencyProperty SelectedValueProperty =
DependencyProperty.Register("SelectedValue", typeof(string), typeof(MySelectedValueTextBox),
new PropertyMetadata(""));
protected override void OnSelectionChanged(RoutedEventArgs e)
{
SetCurrentValue(SelectedValueProperty, SelectedText);
}
}
public class MyViewModel : INotifyPropertyChanged
{
public List<Person> Items { get; set; }
public MyViewModel()
{
Items = new List<Person> { new Person { Name = "Max Mustermann" }, new Person { Name = "Franz Huber" } };
SelectedText = "bla";
}
private string _selectedText;
public string SelectedText
{
get { return _selectedText; }
set
{
_selectedText = value;
if (PropertyChanged != null)
PropertyChanged(this, new PropertyChangedEventArgs("SelectedText"));
}
}
public event PropertyChangedEventHandler PropertyChanged;
}
public class Person
{
public string Name { get; set; }
}
}
Das Problem ist, dass wenn du im Codebehind deine DependencyProperty setzt, überschreibst du damit automatisch das Binding und es wird daher kein set mehr aufgerufen.
Statt dem direkten zuweisen musst du daher einen anderen Weg nehmen:
Also beide Varianten _müssen_ funktionieren. RelativeSource sowie die mit ElementName. Es reicht eigentlich schon direkt an den DataContext der ListView zu binden.
wenn dem nicht so ist, dann ist hat der entsprechende DataContext diese Eigenschaft nicht oder der Pfad dort hin ist schlichtweg falsch.
Bindingfehler werden im Debugoutput ausgegeben. Ansonsten ist es mMn. auch ratsam immer vollqualifizierte Bindingpaths anzugeben, weil diese dann eine Exception zur Laufzeit werfen wenn sie nicht gefunden werden.
Naja und jetzt? Poste doch bisschen mehr Code... Am besten die komplette Hierarchie bis zum Fenster rauf und wo welcher DataContext verwendet werden soll.
Laut diversen Artikeln die ich jetzt überflogen bin musst du nur das QueryEndSession Event abhorchen und bei einem Abbruch "false" zurück geben was du in deinem Codeausschnitt nicht machst.
Bei QueryEndSession wird, zumindest laut Doku, noch nichts geschlossen. Erst bei EndSession.
Ich nehm alles zurück. :)
Zitat
When an application returns TRUE for this message, it receives the WM_ENDSESSION message, regardless of how the other applications respond to the WM_QUERYENDSESSION message
Man müsste sich irgendwie an erste Stelle der Windows Nachrichtenschleife reinhängen. Hätt aber keine Ahnung wie.