für diese Frage hast du dir den denkbar schlechtersten Datentyp ausgesucht weil String imuteable implementiert ist und somit nicht veränderbar. Natürlich kannst du in deiner Klasse Methoden erstellen die keine Rückgabewerte haben und die intern alles Mögliche manipulieren aber das sind Grundlagen der Objekt-Orientierten Programmierung und die solltest du dir aneignen.
Zu 2: Das DataTemplate bekommt ja als DataContext den Content des ContentControls zugewiesen. Wenn du also im DataTemplate irgendwelche Items brauchst um ein Container zu befüllen dann müssen diese Items schon im "Content" oder DataContext des ContentControls dabei sein.
Prinzipiell gibt es nur wenig Situationen bei denen man in WPF den Codebehind-Teil braucht. Im Normalfall sollte das meiste mit XAML + ViewModels zu lösen sein.
In dem Fall solltest du eher das Design überdenken: Deine Hierachie kann mit Sicherheit von nur einem Control gezeichnet werden welches als Datenhintergrund eine Hierachie von boolschen Objekt-Beziehungen hat.
Da hilft nur dein Control wieder Schritt für Schritt zu zerlegen bzw. erneut zusammen zu bauen bis zu dem Punkt an dem es funktioniert bzw. nicht mehr funktioniert um rauszufinden wo es hackt.
Starte den SQL Server Profiler und schau nach was EF für ein SQL ausführt. Das kannst du dann auch schön vergleichen.
Ich hatte einmal ein ähnliches Problem indem eine Abfrage über .NET langsamer war als im SMSS. Der Unterschied ist der, dass im SMSS die Option ArtithAbort standardmäßig auf OFF ist wogegen über .NET es immer ON ist.
Nachdem für jede Abfrage ein Plan erstellt wird und diese anhand des SQL-Strings identifiziert werden sind die Abfragen über .NET und SMSS _nicht_ identisch.
Der Link beschreibt _mein_(und vielleicht auch dein) Problem.
Und zur Behebung des Problems muss man sich mit Parameter-Sniffing auseinandersetzen.
lade nur die aktuell angezeigten Bilder asynchron nach. Und solange das Laden dauert, wird halt ein Platzhalter dargestellt. Windows Explorer machts auch nicht anders.
Meine Vermutung: Ortsteil != Ortsteil aufgrund doppelt oder an unterschiedlichen Stellen erzeugter Objekte.
Wichtig ist hier die Gleichheit der Objekte: Wenn du die Objekte in deiner Liste und im Schüler nicht identisch sind, werden diese auch nicht automatisch selektiert.
Wenn das der Grund ist, kannst du entweder dafür sorgen, dass jeder Schüler nur Ortsteil Objekte aus dem bestehenden Ortsteile-Pool bekommt oder du überschreibst die Equals Methode und vergleichst intern auf Id oder sonst was.
Ich habe gerade meine Vermutung lokal getestet und bestätigt die wie folgt lautet:
Deine Abfrage dauert keine 10 Sekunden! Jedoch kann das Übertragen evt. länger dauern oder das lokale Verarbeiten(DataTable generieren). Der Timeout bezieht sich offensichtlich nur auf die Zeit, die die Abfrage selbst dauert.
Getestet habe ich eine Abfrage auf eine Tabelle, die ich 2x als Kreuzprodukt ausgelesen hab, welche zig Millionen einträge produziert hat. Das Übertragen hat ewig lange gedauert und trotz 1 Sekunde CommandTimeout keine Exception geworfen. Wenn ich aber in die Abfrage noch eine Where Like '%abc%' oder sowas eingebunden habe hat die Abfrage eindeutig mehr als 1 Sekunde gedauert und somit auch die erwartete Exception verursacht.
Ja, den auf dem Client wird dann entwender ein Diagramm oder ein Datenfile erzeugt. Es handelt sich dabei um Zeitreihen von Messwerten.
evt. könnte man die Daten die fürs Diagramm notwendig sind noch einmal bereits Server-Seitig auf ein notwendiges Minimum aggregieren sodass evt. nur mehr ein paar Hundert Datenzeilen für das Diagramm geladen werden müssen.
Die Load Methode ruft ein Instance Property auf welches jedesmal eine neue Instanz deiner Cache Klasse erzeugt. Diese Property hast du jetzt erst eingefügt?(weil im obigen geposteten Code hast du noch einen statischen Member).
besser wird man nur durch Übung und durch die Probleme auf die man stößt. Und dort wo du nicht selbst auf die Lösung kommst, stellst du einfach hier die Fragen. Ich würd sagen, sei einfach interessiert und probier allerhand aus. Dadurch kommt automatisch die Erfahrung.
Und eins kann ich dir Versichern: jeder Programmierer und sei er noch so "gut", hat seine Schwierigkeiten in dem einen oder anderen Bereich und dort muss er halt dann auch wie ein "Anfänger" nachlesen und andere Meinungen einholen. :)
Also mach dir nichts draus. In dem du dich dafür interessierst und dich damit beschäftigst, sag ich mal, bist du am besten Weg "besser" zu werden.
Warum sollten Methoden wegoptimiert werden? Code optimieren != aufräumen. Dafür ist der Entwickler schon selber zuständig. Wie sollen den zur Laufzeit eingelesene Assemblies funktionieren, wenn alle Methoden vom Compiler wegoptmiert wurden weil sie zur Compile-Time keiner gebraucht hat?
Und sich wegen Methodennamen und 100kb ernsthafte Gedanken machen? Sorry aber hast du sonst nichts zu tun?
Binding mit einem eigenen string Property und kümmerst dich ums Sammeln der Zeilen selbst. Am besten Sammelst du die Strings in einer Queue<T> und bei überschreiten der Maximalanzahl wirfst du immer das letzte wieder raus. Evt. könntest du von Queue<T> erben und diesen Mechanismus gleich direkt einbauen.
Diese neue String Property, welches du in deinem ViewModel zur Verfügung stellst, macht dann nichts anderes als bei get die Queue zu einem String zusammenzubasteln.
Oder warte! Ganz andere Lösung:(funktioniert nur, wenns ausschließlich zum Anzeigen gedacht ist.)
Speichere die Strings in einer ObservableCollection wobei du hier auch selbst darauf achten musst, dass nach überschreiten der maximalen Strings die ersten wieder rausgelöscht werden müssen. Binde diese Collection als ItemSource an eine ListBox (statt der TextBox) und schon hast du deine Auflistung.
DependencyProperties braucht man dort, wo man auf Änderungen von gebundenen Properties reagieren will und wird soweit ich das sehe außschließlich in UI- bzw. FrameworkElementen verwendet.
Das DependencyProperty ist hier fehl am Platz. Ein einfaches Property mit INotifyPropertyChanged implementiert, reicht vollkommen:
public partial class MainWindow : Window, INotifyPropertyChanged
{
private string _problem;
public string Problem
{
get { return _problem; }
set { _proplem = value; OnPropertyChanged("Problem"); }
}
private void OnPropertyChanged(string propertyName)
{
//...
}
}
Dabei darfst du aber nicht vergessen den DataContext für dein Window zu setzen. In deinem Fall ist das Window selbst der DataContext, was aber nicht heißt das es automatisch gesetzt ist:
public MainWindow()
{
InitializeComponent();
DataContext = this;
}
und zuguterletzt musst du dann im Binding nurmehr auf das Property verweisen da sich der DataContext vererbt:
<TextBlock Text="{Binding Path=Problem}"/>
Lg, XXX
PS: Schau dir trotzdem die Links mal durch und versuch etwaige Beispiele nachzuvollziehen.
Tut mir leid, ich sehe hier kein Problem und keine Frage, die ich beantworten kann. In dem von mir geposteten Link steht mit Sicherheit alles drinnen was du zum Thema DependencyProperties anfänglich wissen musst.
Über die verlinkte Seite kommt man auch zu Bindings welche das Werkzeug sind um Daten von einem ViewModel an die View zu binden. Dazu könntest du dich auch gleich in das Thema MVVM einlesen um gleich den richtigen Umgang mit WPF zu lernen.
Wenn du dich nun einfach hinsetzen und Dinge ausprobieren würdest, würdest du schnell feststellen wie alles funktioniert und dort wo du nicht weiter kommst, ergibt sich automatisch eine Frage die man sicher leicht erklären kann. Ohne konkreten Problem gibts auch keine konkreten Antworten.