In dem Thread ist die Frage unter gegangen, mich würde es aber tatsächlich interessieren.

Ich habe ein Fenster wo ich ein string zusammen bauen kann mit platzhaltern.
Oben ist eine ListBox und eine ListView darunter, sobald ich in der ListView ein Item doppel klickt, wird die Selektion in der TextBox mit dem Wert ausgetauscht und der Eingabe Fokus liegt auch in der TextBox.

Wie kann man das korrekt in MVVM realisieren?

Ich mach das derzeit so:

private void ListViewItem_MouseDoubleClick(object sender, MouseButtonEventArgs e)
{
	Placeholder item = ((ListViewItem)sender).Content as Placeholder;
	if (item != null &&
		item.Pattern.Contains("%"))
	{
		int startPos = String_TextBox.SelectionStart;
		string content = String_TextBox.Text;
		content = content.Remove(startPos, String_TextBox.SelectionLength);
		content = content.Insert(startPos, item.Pattern);
		String_TextBox.Text = content;
		String_TextBox.SelectionStart = startPos;
		String_TextBox.SelectionLength = item.Pattern.Length;
		GiveTextBoxFocus();
	}
}

private void GiveTextBoxFocus()
{
	String_TextBox.Dispatcher.BeginInvoke(new Action(delegate
	{
		String_TextBox.Focusable = true;
		String_TextBox.Focus();
		Keyboard.Focus(String_TextBox);
	}),
	DispatcherPriority.Render);
}

Das Ganze Fenster macht sonst nichts, es geht nur um den Zusammenbau eines Strings mit platzhaltern.

Aufruf ist dann einfach

private void OnDo()
{
	FileNameWindow window = new FileNameWindow();
	if (window.ShowDialog() == true)
	{
		string newFileName = window.FileName;
	}
}

PS. das soll keine Diskusion über MVVM im allgemeinen werden.

Hmm, ok das mit der Planung klingt einleuchtend.
Ich finde es des weiteren aber auch besser wenn man die Methoden innerhalb der Klasse auch einzeln testet, so kann man viel einfacher alle möglichen cases abdecken.

Ich habe zb die private Methode die ermittelt die Qualität des Kafeefilters, dann schreib ich ein Unit zu dieser Methode und kann die mit allen möglichen Parametern voll spamen.

Ein Test für den Gesamtablauf ist sowieso dabei, nur durch dieses detailierte Testen kann ich dann schneller Fehler finden, wenn die Klasse mit der Methode "KocheKaffee" fehlt schlägt, kann ich vorher schon sagen das es daran liegt das die Filterqualität falsch berechnet wird.

Also ich teste im Prinzip alles was in der Klasse da ist.

@SeboStone
Mit Mocks habe ich derzeit (leider) noch nichts gemacht, bin noch sehr bei den Anfängen von CCD, sehe mich noch beim Roten Grad (Überprüfe es hiermit: http://github.com/DavidWCSL/CC-Watcher).

Man könnte sagen, das klingt logisch, aber was machst Du wenn Du nach zwei Wochen weitere Features hinzufügen musst oder sie etwas ändern musst? Wann ist denn dann der Beste Zeitpunkt fürs Testen?

Nach Deiner Logik nach wäre es das Beste so lange mit den Tests zu warten bis die Klasse keinerlei Änderung mehr erfahren soll. Also eigentlich nie.

Mein Zeitpunkt wann ich die Units erstelle ist immer nach Fertigstellung der Klasse, dh wenn keine weiteren Änderungen geplant sind. Auch wenn neue Features kommen werden diese implementiert, dann die Units aufgefrischt. Nebenbei können die bereits vorhandenen Units verifizieren das ich beim erweitern nichts zerstöre.
Laufe bisher recht gut damit.

Zu TDD selber sagte ich ja schon mehrfach das ich mir demnächst endlich mal ein Buch besorgen muss, damit ich da auch sicherer bin, habe bestimmt nur hier und da kleine Denkfehler.

Das refactorings innerhalb der Methoden für die Units ungefährlich sind ist schon klar.

Meine refactorings sind hin und wieder aber auch so das ich zb eine Methode in zwei kleinere aufteile, zb da die Methode mehr gemacht hat als sie sollte (Single Responsibility Principle).
Solche Sachen kann ich schlecht vorher sehen, oft merk ich das schon direkt beim entwickeln, dh ich müsste dann ein paar Units anpassen noch bevor ich am Code weiter mach.

Oder, ich plane eine Klasse und habe dort eine Methode KocheKaffee vorgesehen, dann kann ich nun die Units schreiben, aber ich weiß doch noch gar nicht welche Methoden KocheKaffee alles benötigt, klar kann ich schon eine "HoleKaffeeFilter" Methode mit einplanen, nur dann weiß ich auch noch nicht ob ich dort intern eine "ÜberprüfeQualität" benötige.
Solche Kleinigkeiten sind nicht in der Planung enthalten, aber die möchte ich ja erst noch abdecken.

Oder ich merke beim entwickeln das die Methode "HoleKaffeeFilter" überflüssig ist, da es eine Filterlose Maschine ist, dann Lösch ich die einfach.

Alles Aktionen die Anpassungen in den Units erfordern, da ist es doch praktischer wenn der Code dahin gehend bereits "fertig" ist. Vor allem bei kleineren Umstellungen während der Entwicklung.

Ich mach es wie gesagt so das ich die Units erst schreibe wenn die Klasse fertig ist, und dann versuche ich jede Methode komplett aus zu reizen, dh Blödsinn übergeben etc.

Ich versuche immer das alle Methoden einer klasse mit Units getestet werden (auch die Privaten etc), wenn ich nach TDD entwickel müsste ich beim dritten refactoring schritt ja ständig die Units anpassen-

//Dazu
Deine Rechnung mit den 90min kann ich schon nachvollziehen, und auch verstehen, aber das bezieht sich ja eher auf UnitTests überhaupt als auf die Entwicklung nach TDD.
Bei deinem Beispiel hast ja schon den Fertigen Code, ob du die Units durch TDD erstelltest oder nachträglich ist da doch irrelevant.

Die Properties in dem Args Objekt sind nicht dafür da zu erfahren ob es ein User klick war oder eine Zuweisung.
Es ist so das der sender immer der sender des Events ist, und bei e.OriginalSender (o.ä.) ist das konkrete Control welches dem sender veranlasste das Event zu schicken.

Was gehen könnte wäre das du mit HitTest das Control unter der Maus holst und dann schaust ob das der sender ist, dann ist die Wahrscheinlichkeit das es ein klick war deutlich höher.

Nur ob es den Aufwand wert ist? Ein boolean ist nicht teuer.

Versuch mal dieses

<Style TargetType="{x:Type FrameworkElement}">
    <Setter Property="TextBlock.FontSize" Value="20" />
</Style>

Aber ich glaube dann gilt das nur für die Controls die keinen eigenen Style haben, du müsstest dann bei allen Styles ein BasedOn definieren.

Ich glaub den Key in allen Window setzen ist die wenigste arbeit.

Selbstverständlich.
Nur er schrieb ja "Nie mehr ohne", also müsste er ja eine gute Lösung des Problems haben. Diese würde mich interessieren.

Also müssten doch eure Pattern nicht funktionieren da ihr alles klein schreibt.

Ein Window style hast du ja, im Prinzip reicht es ja wenn du in jedem Window den Style explizit setzt.

"Window" Styles werden nicht automatisch übernommen, das der Designer es zeigt ist eher der Fehler.

@Golo Roden
Mir tut sich gerade eine frage auf.

Du sagst

Das liegt daran, dass Du zuerst den Test schreibst, und dann nur gerade so viel Code, um den Test zu erfüllen

spricht das nicht etwas gegen die dynamic des Codes?
Hin und wieder ist es doch so, das wenn man eine klasse und deren Methoden das erste mal erstellt, sich später herausstellt das die Methoden etwas anders doch praktischer wären.
Wenn man dann Refactored, müsste man auch alle Unit neu beginnen -.-

Ich persönlich mach das immer so das ich die Units erst schreibe wenn die Klasse fertig ist, dann check ich per Units das die Klasse tut was sie soll bevor ich mich neuen aufgaben zu wende.

Und man kann doch bestimmt einbauen das es immer groß geschrieben ist, oder?

Einfach mit einem eigen flag "SelfChange" oder so merken ob es per vom User kommt oder nicht

im prinzip

private bool _selfChange;
private void OnDo()
{
    _selfChange = true;
    myComboBox.SelectedItem = "Text";
    _selfChange = false;
}

ComboBox.SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    if (!_selfChange)
    {
        // eingabe kommt von dem User
    }
}

Ich glaube mich zu erinnern das es in Forms schon ein Build in Feature davon gibt aber in WPF nicht mehr

//Tags vergessen

Was hat den Linq mit den UnitTests zu tun?
Man testet die Methoden, ob intern manuell eine Liste iteriert wird oder es mittels Linq geschieht macht doch gar kein unterschied.

Eventuell ist er einfach noch dabei Linq zu lernen, zu beginn passieren nun mal mehr Fehler.

@CSL
Bei deinem Code muss ich ja in jedem Fenster noch eigenen Code implementieren, da ist mir meine Variante lieber.

Bei jedem Fenster? Ich habe solch ein Fenster bisher nur so selten gebraucht das es gar nicht lohnt da etwas "besseres" zu finden.

Wieso brauchst du diese Möglichkeit so oft?

Ich machs mir immer recht einfach

private SubWindow _subWindow;

private void ShowSubWindow()
{
    if (_subWindow == null)
    {
        _subWindow = new SubWindow();
    }
    _subWindow.Show();
}

private void CloseSubWindow(bool destroy)
{
    if (_subWindow != null)
    {
        _subWindow.Destroy = destroy; // Das Fenster cancelt "Closing" nicht wenn Destroy true (eigene Varable)
        _subWindow.Close();
        if (destroy)
        {
            _subWindow = null;            
        }
    }
}

Das man alles mit Units abdeckt ist die Definition von TDD? Ich dacht bei TDD geht es auch um die Reihenfolge, also erst Tests und dann ausbauen der Methoden?
Was du beschreibst ist doch Standard Unittesting. Mach ich auch so, ohne das ich sage das ich nach TDD entwickel.
Muss mir endlich mal ein Buch darüber holen ^^

Ich glaube der Punkt Refactoring ist an der stelle besonders hervor zu heben.

Gerade wenn man weiß das man ein Modul komplett abgedeckt hat und sie mit einem Knopfdruck verifizieren kann, hilft das dabei das man schnell mal ein paar Sachen fixt oder abändert, man kann dann jederzeit einfach nochmal den Knopf drücken und schauen ob man etwas kaputt gemacht hat.

Auch im Buch von Fowler (http://www.amazon.de/Refactoring-Studentenausgabe-vorhandener-verbessern-Programmers/dp/3827322782/ref=sr_1_9?ie=UTF8&s=books&qid=1280592376&sr=8-9) sieht man das, wenn man Units hat, viel effektiver bestehenden Code verbessern kann.

Bei meinem Tool auf arbeit zb folge ich der regel das ich nach jedem Refactoring Schritt ein weiterhin funktionierendes Modul habe.

Ich entwickel nicht nach dem TDD; Wollte mir mal noch ein Buch darüber besorgen. Aber ich schreibe schon Unit Tests (aber noch nicht so lange).

Hatte erst gestern wieder den klassischen Fall.
Wir hatten ein Bug entdeckt, ich habe ihn mit einem UnitTest reproduzieren können.
Beim Fixen habe ich dann immer wieder alle Units dieses Moduls laufen lassen, und es war erst gefixt wenn alle units wieder gepasst haben.
Bug gefunden -> Reproduziert mit einer Unit -> Gefixt -> Verifiziert mit den Units.

Meine Desktops (arbeit und daheim) sind meist eines dieser bilder hier:

http://pictures.my-libraries.de/Wallpapers/
Immer ungestreckt über beide Monitore, ich mag es nicht wenn die Bilder doppelt sind.
Die Originalen Desktops zeige ich nicht da es nichts zu zeigen gibt, sind immer absolut Leer, den Desktop benutz ich nie.

Anders im Code aufbauen.

Du hast eine Liste von "Folder" Objekten und Bindest das gegen den Tree, im Tree bindest du den angezeigten text wiederum an ein Property welches nur den aktuellen Pfad zurück gibt.
So kannst du auch sehr einfach ein Lazy Loading implementieren, indem zu das IsExpanded des TreeViewItems gegen ein Boolean bindest.

//Pseudo

internal class Folder : INotifyPropertyChanged
{
	public Folder(string path)
	{
		Folders = new List<Folder>();
                //dummy child erstellen wenn childs vorhanden
		Path = path;
	}

	public string Path { get; private set; } // D:\Bla\Fasel

	public string Name
	{
		get { return PathNameExtractor.GetName(Path); } // Fasel
	}

	public List<Folder> Folders { get; set; }

	public bool IsOpened
	{
		get { return _isOpened; }
		set
		{
			_isOpened = true;
                        // wenn nicht geladen war entferne dummy und lade die korrekten subfolders
			// load child folders
		}
	}
	private bool _isOpened;
}

Im Code arbeitest du nur mit dem "Folder" objekt, und der kennt sein "Path" 😉

@Xeres

Und wo hast du deine Eventhandler? Oder versuchst du aus dem Code heraus auf "btnTest" zu zu greifen? Das geht natürlich nicht da diese Objekt erst zur Laufzeit generiert werden.

Die Lösung des Problems ist entweder den EventHandler direkt in der Xaml zu zu weisen, oder ein Command zu binden.

Ein static RoutedCommand mit einem CommandBinding oder ein ICommand mit Binding, wie ist dir überlassen.
Wie ich sehe hast du das bereits.

Wann und wo kommt diese Exception?
Kannst du mal bitte den Xaml Code zeigen? (aufs wesentliche gekürzt)

Nuargs was is das nu.

Finde ich merkwürdig

Was ich gemacht habe

1. In den Settings "Feeds alphabetisch Sortieren" aktiviert
2. Nach dem neu laden der Feeds waren plötzlich alle Artikel alphabetisch sortiert
3. Habe es wieder deaktiviert
4. nun sind die Artikel wieder nicht mehr sortiert, aber die Feeds leider auch nicht mehr

Ist:
Wenn "Feeds alphabetisch Sortieren" ausgewählt ist werden die Feeds sowie die Artikel sortiert

Erwartet:
Wenn "Feeds alphabetisch Sortieren" ausgewählt ist werden die Feeds sortiert, die Artikel aber bleiben unverändert.

Stimmt, jetzt geht es wieder.
Hat beim ersten versucht aber gecrashed (Report ist gesendet) Hatte das Update aus dem Settings Dialog heraus aufgerufen, ein Update aus dem Contextmenü des Tray Icons hat funktioniert.

Das automatische Update funktioniert bei mir nicht mehr:

Während der Updatesuche ist folgender Fehler aufgetreten: Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden

Die Verbindung mit dem Remoteserver kann nicht hergestellt werden.

Die jetzige Version des feedCarrier is 1.1.259.722.

Proxy wird automatisch ermittelt, aber auch manuelle Eintragung bringt nichts.

FYI: SlimDX muss installiert werden, die dll alleine reicht nicht. (Deswegen habe ich es bei mir nicht getestet)

Ok, überredet 😁

Hallo,

Ich weiß nicht ob das wirklich Ajax ist, aber ich glaube schon.

Ich kenne es aus ein anderen Forum das man unter den Beiträgen eine TextBox hat wo man direkt Antworten kann ohne das man auf ein "Antworten" Button klicken muss und ein neues Fenster auf geht.

Ist sowas hier auch geplant? Wäre schon nett.
Dann könnte man den Beitrag dann auch unten neu dran packen ohne das die Komplette Seite neu geladen werden muss 😁

LG
CSL

Hä

Ne du läst den RadioButton schon im Xaml, im object hast du dann nur Boolean property

public bool IsChecked
{
	get { return _isChecked; }
	set
	{
		_isChecked = value;
		OnPropertyChanged("IsChecked"); // stichwort INotifyPropertyChanged
	}
}
private bool _isChecked;

und das Bindest du dann

<DataTemplate>
    <RadioButton IsChecked="{Binding IsChecked}" />
</DataTemplate>

In der Liste (ObservableCollection) wo die objekte dann sind kannst du immer einfach das PropertyChanged fangen, dort prüfst du ob "IsChecked" geändert wurde und hast dann direkt das entsprechende Objekt als sender.

=> Fällt alles unter WPF Basics 😉

Ich kenne solch eine Exception meist nur wenn versucht wird auf ein Property zu zu greifen was nicht existiert.

Bei dem hier:
(TextElement.Background).(SolidColorBrush.Color)
wird im Prinzip das gemacht:

((SolorColorBrush)myControl.Background).Color = value;

d.h. es muss ein SolorColorBrush im Background Liegen.

Ändere mal dein
<TextBlock FontSize="20" FontWeight="Bold" Padding="20 5">
nach
<TextBlock FontSize="20" FontWeight="Bold" Padding="20 5" Background="Transparent">

Was hast du eigentlich vor, bzw was willst du erreichen? Wo Steckt diese TextBox wenn du von irgendwelchen "Filtern" sprichst.

Das geht problemlos über die Margins des Controls.

In den Source auf der Seite sieht man
Storyboard.TargetProperty="(Background).(SolidColorBrush.Color)"

Das mal Probiert?

Blend gibt mir das hier:

<ColorAnimationUsingKeyFrames Storyboard.TargetProperty="(TextElement.Background).(SolidColorBrush.Color)">
    <EasingColorKeyFrame KeyTime="0" Value="Yellow"/>
    <EasingColorKeyFrame KeyTime="0:0:0.1" Value="Red"/>
</ColorAnimationUsingKeyFrames>

//Fix tag

Du brauchst nur ein konkretes Objekt pro Row, das kannst du mit einem Boolean Property ausstatten und den RadioButton dagegen Binden.
Nun fängst du nur noch das PropertyChanged des Objektes und bekommst gleich das entsprechende Objekt mit.

<Advertising>
Meine EnhancedObservableCollection hat ein ItemPropertyChanged event, sobald "CatchPropertyChanged" auf true steht fängt die Liste automatisch das PropertyChanged aller Items und schickt das ItemPropertyChanged event mit dem Objekt.
http://downloads.my-libraries.de/Libraries/Tulipa/Documentation/html/AllMembers_T_Tulipa_EnhancedObservableCollection_1.htm
</Advertising>

VERDAMMT - nun weiß ich noch schneller das es nix neues für mich gibt 😄

Die Geschwindigkeit ist echt beeindruckend 😃
(eigentlich AJAX geplant?)

Also bei mir ging es um dieses Control:
(Unwichtige Teile entfernt)

Ich wollte das die erste und letzte Column immer gleich groß sind, richtet sich also nach dem längsten Element.

<ItemsControl ItemsSource="{Binding ReleaseSummaries}" Grid.IsSharedSizeScope="true">
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <Grid>
                <Grid.ColumnDefinitions>
                    <ColumnDefinition Width="Auto" SharedSizeGroup="First" />
                    <ColumnDefinition />
                    <ColumnDefinition Width="Auto" SharedSizeGroup="Last" />
                </Grid.ColumnDefinitions>
                <TextBlock Text="{Binding Release}" Margin="10,2" />
                <ListBox ItemsSource="{Binding WorkingRanges}" Grid.Column="1" Background="Transparent" BorderThickness="0" />
                <TextBlock Text="{Binding Summary}" Grid.Column="2" Margin="10,2" />
            </Grid>
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

Wenn ich dort IsSharedSizeScope weg lasse, sind die Columns immer auf Auto, also unterschiedlich groß, mit dem IsSharedSizeScope ist alles wie gewünscht.

//Dazu
Sobald das Grid im ItemTemplate ist hatt man ja pro Item ein Grid und somit > 2 😉

Wenn MyXaml aber ein dp sein muss, dann musst du natürlich noch eine Verbindung von der RichTextBox zum Property her stellen.

Genau, das sind aber WPF Basics, ich bin versucht dich auf Punkt 1.1.1 hin zu weisen => [Hinweis] Wie poste ich richtig?

Dann musst du das Xaml Property der RichTextBox gegen das Property des UserControls Binden.

Ich versteh immer noch nicht, das Property gibt doch korrekt dein Xaml Wert zurück, wo ist das Problem?

Ich versteh die frage nicht, wenn das dp korrekt definiert ist (snippet), kannst du auf das Property wie gewohnt zu greifen.

Ich hab gestern Abend das erste mal ein kleines Projekt bei GitHub gepushed, war gar nicht zu einfach eine Verbindung auf zu bauen wenn man keine Ahnung von SSH und Putty etc hat 😄

http://github.com/DavidWCSL/CC-Watcher

Mein Ziel ist dabei nicht meinen Marktwert zu steigern, vielmehr die Sourcen raus zu geben da andere eventuell Interesse haben. Völlig uneigennützig.
Werde die Binaries und Screens demnächst auf meinem Blog veröffentlichen.

Info: Ind er Lösung auf der Website wird Min und Max nicht gebücksichtigt 😉
Wir hatten das erst letztens hier:
WPF: Button statt Fenstertitel
Siehe mein Beitrag.

Ich bin mir da auch nicht sicher, aber ich hatte auch mal solch eine Liste und musste um die Columns im ItemTemplate zu sharen es in der Liste setzen.

Bei mir hatte das sharen nicht geklappt und war dann dort gelandet:
http://stackoverflow.com/questions/1102734/how-can-i-make-a-column-in-a-listbox-in-wpf-the-same-width-for-all-items
Und dort war die Lösung, welche bei mir funktionierte, dies Property in der Liste zu setzen.

Wenns statisch ist dann pack das Hallo doch einfach direkt ins Template

<DataTemplate x:Key="HalloTreeViewItemTemplate">
    <TextBlock Text="Hallo" />
</DataTemplate>

<TreeViewItem HeaderTemplate="{StaticResource HalloTreeViewItemTemplate}">

Hm?
Du hast doch noch das Grid in ItemTemplate wo SharedSizeGroup gesetzt ist -.-
Ohne dem sind doch alle deine Items wieder unterschiedlich lang - oder?

Ich meinte das du den angepassten Code mal Postest, eventuell hast du versehentlich was falsch gemacht

Nein das geht nicht.
Was möchtest du erreichen?

//Dazu
Du kannst in dem DataTemplate auch binden 😉