Crosspost: http://www.c-plusplus.de/forum/p2094534

Aufgedröselt:

private void los()
{
	while (mylist.Count > 0)
	{
		String aktuell;
		aktuell = mylist.ElementAt(0);
		if (aktuell == "DG_runter")
		{
			dg_runter();
			if (mylist.Count > 0)
			{
				mylist.RemoveAt(0);
			};
		};
		if (aktuell == "2OG_runter")
		{
			og2_runter();
			if (mylist.Count > 0)
			{
				mylist.RemoveAt(0);
			};
		};
		if (aktuell == "2OG_hoch")
		{
			og2_hoch();
			if (mylist.Count > 0)
			{
				mylist.RemoveAt(0);
			};
		};
		if (aktuell == "1OG_runter")
		{
			og1_runter();
			if (mylist.Count > 0)
			{
				mylist.RemoveAt(0);
			};
		};
		if (aktuell == "1OG_hoch")
		{
			og1_hoch();
			if (mylist.Count > 0)
			{
				mylist.RemoveAt(0);
			};
		};
		if (aktuell == "EG_hoch")
		{
			eg_hoch();
			if (mylist.Count > 0)
			{
				mylist.RemoveAt(0);
			};
		};
	}
}

Ein echter Kandidat für den Coding Style Horror Award.

1. Viel zu viel doppelter Code
2. Unnötige ";"
3. Alles Deutsch
   [4. C# Naming Convention nicht einhalten]
   [5. Unnötige Klammern]
   [6. Unnötige Count abfragen]

(4, 5 und 6 würden durch Punkt 1 aufgeräumt, daher geklammert)

BTW, Sagt dein Visual Studio tatsächlich "Stummelstücke"?

@David W: Du hast vollkommen Recht mit deinen Punkten Schell, Fehlerfrei und Verlustfrei. Leider war meine Idee und in meinem Kopf die schnellste möglichkeit eine Zeile in eine Datei zu schreiben.
Leider hast du kein Beispiel genannt wie man es besser machen könnte.

// Nach Formatierung der Message, ruf diese Methode zum Schreiben auf.
private void Write(string logFile, string message)
{
    using (var writer = new StreamWriter(logFile, true, Encoding.UTF-8)
        writer.WriteLine(message);
}

Zusammen mit dem Kommentar von inflames2k

Wenn du es schlau anstellst hast du für jeden Tag ein neues Log

hast du auch kein Performance Problem.

Der Vorteil: Es ist einfach. Es ist leicht lesbar. Es kann nur zu Datenverlust kommen wenn die Datei nicht geschrieben werden kann oder es genau in der nanosekunde abbricht. Aber auch dann fehlt immer nur eine Zeile.

Falls du doch bedenken hast kannst du die Datei auch mit Autoflush offen halten:

private StreamWriter _logWriter;

private void OpenLog(string logFile)
{
    _logWriter = new StreamWriter(logFile, true, Encoding.UTF8);
    _logWriter.AutoFlush = true;
}

// Nach Formatierung der Message, ruf diese Methode zum Schreiben auf.
private void Write(string message)
{
    _logWriter.WriteLine(message);
}

Logging in eine XML Datei halte generell ich für keine gute Idee.
Denn sobald der Prozess durch ein Fehler stirbt kann es sehr schnell passieren das die XML ungültig wird, dann muss man erstmal die XML wieder reparieren. Es kann sogar sein das Datenverlust eintritt da noch nicht alles in die XML geschrieben wurde.

Das ist nicht die Idee eines Loggings.
Logging muss Schnell, Fehlerfrei und Verlustfrei sein.

Da aber jetzt schon bei Gmail die Werbung auf die eMail-Inhalte abgeglichen wird GMail hat Werbung??? Noch nie welche gesehen ...

Es gibt massig Tutorials wie man ein Gmail Konto hinzufügt .. aber bei mir werden die Mails nie geladen.

Ich kenne weder Office 365 noch habe ich solche Tutorials gesehen, aber mal ganz Blöd gefragt: Hast du in deinen GoogleMail Settings auch IMAP (oder POP) aktiviert? Standardmäßig ist es nämlich aus.

Du kannst im getter Methoden ausführen lassen.
Unabhängig davon ist dein Code da nicht sehr schön an zu sehen -.- Man sieht auf einen Blick viele Fehler.

Man kann sich auch mit dem wsdl Tool von VS aus der wsdl Datei C# Klassen erzeugen lassen, dann braucht man nur noch diese verwenden 😃

Bietet sogar die Möglichkeit des PropertyChanged.

Der Aufruf:

wsdl.exe [URL]http://192.168.12.34/myAPI/myAPI.wsdl[/URL] /parameters:wsdl.xml

Die wsdl.xml wie ich sie immer verwende:

<wsdlParameters xmlns="http://microsoft.com/webReference/">
  <webReferenceOptions>
    <codeGenerationOptions>properties enableDataBinding</codeGenerationOptions>
  </webReferenceOptions>
</wsdlParameters>

Die Klassen kann man dann Instantiieren und benutzen, und der tatsächliche Aufruf des WebService ist dann weg gekapselt in diesen Klassen 😃

Du kannst ein Control mit IsHitTestVisible für die Maus unsichtbar machen, dann klickst du durch.
Das Propertie kannst du einfach Binden und dann immer zwischen Klickbar und Nicht-Klickbar umschalten 😄

Was auch geht wäre ein Custom Attached Behavior, das häng an einem Beliebigen FrameworkElement und fängt dessen LeftMouseButtonDown, sobald das kommt klettert es den Visual Tree hoch und selektiert den ListViewItem Container 😃

Würde es nicht gehen eine neue Leere Seite ohne Formatierung zu öffnen mit nur dem Quelltext? Ne einfache txt, da kann man dann alles Markieren und sich kopieren (CTRL+A) ohne das man mit dem drumherum durcheinander gerät.

Aber andere Frage dazu, ist es gewünscht das man sich Fertige Lösungen zusammen kopiert? Der Lerneffekt ist doch größer wenn man es selber eingibt 😁

Mach das lieber über den Triggers, so lange du kein SL Programmierst bist du auf diese krüppeligen VisualStates nicht angewiesen.

• In Visual States kann man nur vorhandenes editieren statt komplett neu zu schreiben [Hintergründe mit unterschiedlichen Verläufen ist sehr fummelig],
• Man ist auf Storyboards begrenzt,
• Visual States sind deutlich länger
• Triggers sind einfacher zu handhaben

Hier das was du suchst, ohne das du das MouseLeft o.ä. noch implementieren musst.

<ControlTemplate TargetType="{x:Type RadioButton}">
    <Border>
        <ContentPresenter />
    </Border>
    <ControlTemplate.Triggers>
        <Trigger Property="IsMouseOver" Value="True">
            <Setter Property="Background" Value="Red" />
        </Trigger>
        <Trigger Property="IsChecked" Value="True">
            <Setter Property="Background" Value="Yellow" />
        </Trigger>
    </ControlTemplate.Triggers>
</ControlTemplate>

das kann man per Gruppenrichtlinie abschalten, dann hat man per Default wieder den alten Desktop.

Was schon sehr Sinnvoll ist auf Nontouch Desktop PCs.
Wenn ich an das Video denke, wo er diese Tiles mit der Maus benutzte, wirkte das doch sehr fummelig ^^.

Find ich ein komischen Trend alles immer größer zu machen. Wenn man mit der Maus arbeitet braucht man doch gar nicht so ein riesen Button (Linux ist da aber auch nicht besser, in Ubuntu muss man auch erstmal alles kleiner machen [Mint geht]).

Pack einfach alle Buttons übereinander auf die gesamte fläche, und Clippe alle Buttons separat auf ihren Sichtbarkeitsbereich herunter.

Wäre mein Vorschlag.

Cropping or Clipping in WPF

Du kannst innerhalb des Template das TabPanel verschieben. Ein template Beispiel siehst du hier DW.WPFToolkit

Was du aber vor hast ist das Splitten des ItemsHost. Das geht nicht. Du kannst maximal ein Custom Control machen welches eine ItemsSource2 oder so bereit stellt und das dann im Template zusätzlich positionieren.

Wenn man den Windows Qualitätsverlauf sieht:

95 Schlecht
98 Gut
ME Schlecht
XP Gut
Vista Schlecht
7 Gut
8 Schlecht
9 Gut

Wozu dann über 8 Diskutieren wo die meisten vermutlich auf 7 bleiben und von dort direkt auf 9 Springen ^^

Ich finde man sollte jetzt erstmal in ruhe auf die ersten Betas warten, mit MSDN Subscription usw bekommt man es früh genug dass man dann sein vorurteil bilden kann.

Ich fand heraus das jede Formatierung durch mit unbekannte Zeichen getrennt werden. Ich visualisiere es xaml like mal mit < und > Zeichen.

d.h.

1. 000111000111000
2. <000111000111000>
3. <000><111><000111000>
4. <000><111><000><111><000>

Bei den anderen Controls die eingefügt werden ist es ja wie angegeben immer 5
das zeige ich mal als "i"

5. <000><111><0><i><00><111><000>

Wenn man nach jeder Formatierung 2 hinzu fügt als "MoveIndicator" (><) und für jedes "Inline Element" 5 (><x><) dann ist man auf der richtigen Seite.
Die Art der Formatierung macht kein unterschied.

Doch nicht so einfach wie ich dachte.
Sobald ich eine Formatierung hinzufüge verschiebt sich die Position immer willkürlich.

Ich habe dies hier:

foreach (var formatting in formattings)
{
	var range = new TextRange(flowDocument.ContentStart, flowDocument.ContentEnd);

	var begin = range.Start.GetPositionAtOffset(GetPosition(formatting.Begin, elements), LogicalDirection.Forward);

	var end = begin.GetPositionAtOffset(formatting.End - formatting.Begin);

	var formatRange = new TextRange(begin, end);

	if (formatting.IsBold)
		formatRange.ApplyPropertyValue(TextBlock.FontWeightProperty, FontWeights.Bold);
	else
		formatRange.ApplyPropertyValue(TextBlock.FontWeightProperty, FontWeights.Normal);
}

Wenn ich diesen Text habe:

000111000111000
und ich will
000 nicht formatiert
111 Fett formatiert

Ist der verlauf so:
000111000111000
000111000111000
000111000111000
000111000111000

Wenn ich die Bolds aber immer nur einmal setzen lasse, dann passt es.
000111000111000
000111000111000

mein Ziel ist aber
000111000111000

Scheinbar ist es immer wenn eine Formatierung hinzugefügt wurde die nicht die erste ist, dann muss ich überall +2 machen. Ich weiß aber nun nicht ob das immer passt - auch mit den anderen formaten wie Italic, andere Schriftgröße usw...

Scheinbar muss ich für jedes Element was vor der Position war 5 dazu addieren.

	var range = new TextRange(flowDocument.ContentStart, flowDocument.ContentEnd);
	foreach (var formatting in formattings)
	{
		var begin = range.Start.GetPositionAtOffset(GetPosition(formatting.Begin, elements));
		var end = range.Start.GetPositionAtOffset(GetPosition(formatting.End, elements));

		var formatRange = new TextRange(begin, end);

		formatRange.ApplyPropertyValue(TextElement.FontWeightProperty, FontWeights.Bold);
	}
}

private int GetPosition(int position, List<InlineElement> elements)
{
	int count = elements.Where(e => e.Pos <= position).Count() * 5;
	return position + count;
}

Ich find das irgendwie Banane....

Hi,

Ich habe zZt das Problem das ich in einer RichTextBox UI Elemente an einer vorgegebenen Stelle einfügen muss. Das funktionierte soweit.
Ich Zeige erstmal wie.

(Ich habe es zum Testen mal billig nach gebaut)

Gegeben sind diese Objekte:

public class InlineElement
{
	public int Pos { get; set; }
	public string Text { get; set; }
}

public class Formatting
{
	public int Begin { get; set; }
	public int End { get; set; }
	public bool IsBold { get; set; }
}

Test Daten:

private Run CreateTextContent(string text, int from, int to)
{
	return new Run(text.Substring(from, to - from));
}

private string GetText()
{
	return "00123456000000000000";
}

private List<InlineElement> GetElements()
{
	var elements = new List<InlineElement>();
	elements.Add(new InlineElement
	{
		Pos = 5,
		Text = "variable"
	});
	return elements;
}

private List<Formatting> GetFormattings()
{
	var formattings = new List<Formatting>();
	formattings.Add(new Formatting
	{
		Begin = 2,
		End = 8,
		IsBold = true
	});
	return formattings;
}

Aufrag war als erstes nur diese "InlineElemente" als Buttons in ein Text zu packen:

private void Window_Loaded(object sender, RoutedEventArgs e)
{
	var text = GetText();
	var elements = GetElements();

	var paragraph = new Paragraph();

	int pos = 0;
	for (int i = 0; i < elements.Count; ++i)
	{
		var element = elements[i];

		var run = CreateTextContent(text, pos, element.Pos);
		paragraph.Inlines.Add(run);
		paragraph.Inlines.Add(new Button
		{
			Content = element.Text
		});
		pos = element.Pos;
	}

	if (pos < text.Length)
	{
		var run = CreateTextContent(text, pos, text.Length);
		paragraph.Inlines.Add(run);
	}

	flowDocument.Blocks.Add(paragraph);
}

Wie man an dem ersten Bild erkennt war das soweit kein Problem. (1)
Ich habe es so gelöst indem ich den Text einfach gesplittet in Run Objekte gepackt habe.

Nun soll der Text auch noch formatiert dargestellt werden, wo und wie ist auch über die Struktur vorgeben.
Ich war beim Recherchieren auf TextRange und TextPointer gestoßen, aber da gibts nun ein Problem. Und war durch das Splitten ist die Selektion am ende verschoben (2)
(Die Testdaten sagen das die Zahlen 1-6 Bold sein sollen, wenn ich den Text nicht Splitte passt es genau)

private void Window_Loaded(object sender, RoutedEventArgs e)
{
	var text = GetText();
	var elements = GetElements();
	var formattings = GetFormattings();

	var paragraph = new Paragraph();

	int pos = 0;
	for (int i = 0; i < elements.Count; ++i)
	{
		var element = elements[i];

		var run = CreateTextContent(text, pos, element.Pos);
		paragraph.Inlines.Add(run);
		//paragraph.Inlines.Add(new Button
		//{
		//    Content = element.Text
		//});
		pos = element.Pos;
	}

	if (pos < text.Length)
	{
		var run = CreateTextContent(text, pos, text.Length);
		paragraph.Inlines.Add(run);
	}

	flowDocument.Blocks.Add(paragraph);

	var range = new TextRange(flowDocument.ContentStart, flowDocument.ContentEnd);
	foreach (var formatting in formattings)
	{
		var begin = range.Start.GetPositionAtOffset(formatting.Begin);
		var end = range.Start.GetPositionAtOffset(formatting.End);

		var formatRange = new TextRange(begin, end);

		formatRange.ApplyPropertyValue(TextElement.FontWeightProperty, FontWeights.Bold);
	}
}

Wenn ich nun das Element einfügen lass ist die Selektion noch mehr verschoben. (3)

Jemand ne Idee wie ich das Problem korrekt Löse?
Die Anzahl der Elemente, der Text und die Anzahl sowie art der Formatierung ist mir im Vorfeld unbekannt.

"SetSource" hab ich zwar selber noch nie gesehen, aber kann es sein das du auch bei dieser BitmapImage klasse das BeginInit und EndInit aufrufen musst?

//Dazu
Scheinbar nicht, gerade das hier gefunden: BitmapImage.SetSource -> Catastrophic Error

Erstens das, und zweitens: Versuchs doch mal.
Es ist zwar korrekt das man den Code lesen kann, aber lass ihn doch mal abspeichern und Versuch es baubar zu bekommen. Behebungen in den Quelltexten. Erstellen eines Projektes und Solutions. Zusammensuchen von allen verwendeten 3rdParty libraries. Das ist alles nicht so einfach wie es sich anhört.

Die einzigste gefahr ist das wissen innerhalb einer Methode, also das man das abschauen kann. Mit guten OOP sind die Methoden aber sehr kurz sodass man ohne IDE unterstützung schwerer zurecht findet. Obfuscatoren gibts ja auch noch.

Habe ich schon versucht, findet den typ auch nicht.

Nur der VS Designer nicht. Es baut aber korrekt und findet es auch zur Laufzeit. Habe es eben mal Probiert.

WTF??

Was haben die View Controls im C# Code verloren? und zudem in einem "Model" der dann von nem ViewModel gefüllt wird?

Du hast MVVM komplett falsch umgesetzt.

6 Setzen.

Hast du meine Antworten gelesen? Eine Row und Column ist nie unsichtbar, sie ist immer da, nur wenn du keine größe vorgibst und nichts in dem Bereich hast, dann ist die größe eben 0 und du siehst nichts.

Ich klink mich aus, wird mir grad zu blöd hier die WPF Basics vor zu kauen...

Ich rate mal ins Blaue: Du willst die Maßeinheit mit vergößern sodass dies sich nicht ändert?

Wo ist in dein Xaml denn dein Transform Objekt?

Wenn du es nur Optisch vergößern willst ohne das sich das Objekt selber vergrößert musst du mit der RenderTransform arbeiten, nicht mit dem LayoutTransform.

Du kannst zwei Template definieren, einmal ein Template für den geschlossen zustand wo es normal angezeigt wird.
Und dann ein Template für den geöffneten zustand, da packst du dir noch ein Dummy Control rein welches eine voegegebene Breite nimmt (Festgelegt mittels eines IValueConverters).

Zwischen die beiden Template wählst du dann mitteles eines DataTemplateSelectors.
Ein Beispiel dieses Selectors findest du in den Beitrag von mir hier: ComboBox - nicht alles aus DropDown übernehmen (ungefähr in der Mitte).

//Dazu
Falls du weiterhin ein echten Baum haben willst ist solch ein Control wie ich dir schon Zeigte das richtige für dich, da sind die Items in einem Baum angezeigt aber das ausgewählte Item nicht mehr, da kannste das Template auch selber bestimmen.

Suchst du sowas => TreeComboBox?

Code ist hier: TreeComboBox on GitHub

Sieht interessant aus, nur, braucht man das? Die ViewModel sollte die View ja nicht kennen - darum organisiert man die ViewModels meistens in andere Namespaces (und somit Ordner) getrennt von der View...

Ich z.b. machs immer so:

\
\Views\AnyView.xaml
\ViewModels\AnyViewModel.cs
\Model1.cs
\Model2.cs
\

//Dazu
Das Bild zeigt eine Inkonsiszenz - es sollte MainView und nicht MainWindow heißen, die anderen xamls halten das ein.

-> MainView
-> MainViewModel

MainWindowViewModel ist etwas merkwürdig ^^

Neeee.
Du hast die Spalte auf Width="Auto", dh das Grid fragt an der stelle alle childs in dieser Spalte wie breit sie gerne wären.
Und jedes Grid fragt dann seine Childs - so klettert er runter und baut die oberfläche auf.

Was nun passieren kann - wenn es kein Inhalt gibt, dann ist alles 0 da es kein Platz möchte.

Z.B.:

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="Auto" />
        <ColumnDefinition />
    <Grid.ColumnDefinitions>

    <StackPanel x:Name="stackPanel">
        <Grid x:Name="grid" />
    <StackPanel>

</Grid>

"stackPanel" sowie "grid" ist nun ActualWidth = 0.0. Da sie nichts an zu zeigen haben, brauchen sie auch kein Platz.

Hast du dagegen so etwas:

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="Auto" />
        <ColumnDefinition />
    <Grid.ColumnDefinitions>

    <StackPanel x:Name="stackPanel">
        <Grid x:Name="grid">
            <TextBlock Text="Demo" />
        </Grid>
    <StackPanel>

</Grid>

Dann ist nun "stackPanel" und "grid" ActualWidth = Breite die "Demo" erfodert um sich an zu zeigen.

Wenn du die Grid Spalte seine breite berechnen lässt, sieht es wieder anders aus:

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="150" />
        <ColumnDefinition />
    <Grid.ColumnDefinitions>

    <StackPanel x:Name="stackPanel">
        <Grid x:Name="grid" />
    <StackPanel>

</Grid>

Nun ist "stackPanel" und "grid" ActualWidth = 150. Da das Grid die Breite vor gibt, dann Stretchen sich die Element.

Und bei

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width=".5*" />
        <ColumnDefinition Width=".5*" />
    <Grid.ColumnDefinitions>

    <StackPanel x:Name="stackPanel">
        <Grid x:Name="grid" />
    <StackPanel>

</Grid>

ist "stackPanel" und "grid" ActualWidth = <aktuelle Grid breite> / 2.

Darum fragte ich wie dein Xaml aussieht, wenn dein ActualWidth = 0.0 ist, dann hat er vermutlich nichts an zu zeigen und die Spalte die auf "Auto" steht verkleinert alles auf 0.0.

Wenn du ein Control mit dem ScaleTransform vergrößerst werden auch alle seine Childs direkt mit vergrößert und bleiben auf im korrekten verhältnis.

Wie sieht denn dein Xaml aus?

Arrange solltest du nicht selber aufrufen, das ist aufgabe des Parent Controls.

Wenn ActualWidth 0.0 ist, dann ist das Control auch tatsächlich 0.0 Breit.

Im XAML-COde habe ich das Panel mit Height = "Auto" gestellt

1. Height != Width 😉
2. "Auto" bedeutet das die Spalte oder Reihe so Breit oder Hoch ist wie die Controls darin sein möchten.

Wenn dein cnv_Panel keine Child Controls beinhaltet die eine größe haben, dann ist das Control selber natürlich auch 0 breit oder hoch.

Die Größe wird erstn nach dem Measurement bekannt.
Das Layout durchläuft in WPF mehrere Stadien

• Measurement (Größe berechnen)
• Arrange (Positionieren)
• Render (Darstellen)

Je nachdem wo du steckst ist eventuell noch nicht alles fertig.

Unabhängig davon solltest du "ActualWidth" nehmen statt "Width" - die "Width" ist nur gesetzt wenn du es explizit an gibst.

Also ein grafisches Objekt das vor dem Zoom 30 Pixel lang war, soll nach dem Zoom ebenfalls 30 Pixel lang sein. Hä.
Durch den Zoom werden die Pixel doch mehr. Wenn die Pixel nicht mehr werden hast du auch kein Zoom.

PS. In WPF sind es auflösungsabhängige Einheiten, keine Pixel.

Hast du richtig verstanden.
Ich dachte du bist in der Applikation.

Mach es doch so das du deinen telerik style ein Key gibst und den in dein Control einfach zuweist. Ein globales Style brauchst du da gar nicht.

Wäre aber auch böse. Eine dll darf nicht globale Styles definieren die die Styles in der verwendenden Applikation umschreibt.

Generic.xaml

<ResourceDictionary>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="/My.Controls.WPF;Component/Resources/CommonStyles.xaml" />
            <ResourceDictionary Source="/My.Controls.WPF;Component/Resources/DataGrid.xaml" />
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</ResourceDictionary>

CommonStyles.xaml

<ResourceDictionary>
    <Style x:Key="MyTelerikDataGridStyle" />
</ResourceDictionary>

DataGrid.xaml

<ResourceDictionary>
    <!-- .... -->
    <ControlTemplate TargetType="{x:Type controls:DataGrid}">
        <Grid>
            <!-- .... -->
            <telerik:RadGridView Style="{StaticResource MyTelerikDataGridStyle}" />
        </Grid>
        <!-- .... -->
</ResourceDictionary>

Wenn du das MyTelerikDataGridStyle nur im controls:DataGrid verwendest kannst du es auch aus der Common in die DataGrid.xaml verschieben.

Die Generic.xaml ist ein Bestandteil des "Theming" - wenn das Control selber nicht sagt das es davon lesen will, dann wird es das auch nicht.
Was du suchst sind globale Styles.

Erstell dir ein eigenes ResourceDictionary irgendwo - pack da dein globales Style rein und includiert dieses ResourceDictionary in den MergedDictionaries der Applikation.
Das ist der richtige Weg.

Stells auf Collapsed nicht auf Hidden.
Hidden läßt nur den Rendervorgang weg, Measurement und Arrange wird aber weiter ausgeführt, dh deine Controls reservieren trotzdem den Platz, auch wenn sie nicht da sind.
Erst bei Collapsed wird Measure, Arrange und Render übersprungen.

http://msdn.microsoft.com/de-de/library/system.windows.visibility%28v=VS.100%29.aspx

Triggers werden immer von oben nach unten abgearbeitet.
Es kann also passieren das der erste trigger von einen zweiten der danach kommt überschrieben wird. Das muss man einfach bedenken.

Und auch meine aktuelle Lösung scheint nicht ganz koscher zu sein. Die Animation zwischen dem Pressed-Zustand und den MouseOver-Zustand (Maustaste loslassen) sieht etwas ruckelig aus. Allerdings geb ich mich im Moment damit zufrieden.

Das BeginStoryBoard hat ein HandOffBehavior property. Schau mal ob etwas passiert wenn du das veränderst.

Bzgl RemoveStoryboard und StopStoryboard, ich glaube der unterschied ist das jedes StoryBoard sich neu verbinden muss wenn du es mit Remove entfernt hast, mit Stop unterbricht es nur seine Animation.
Wird evtl ein Performancevorteil ergeben wenn man sehr viel animiert - ist auch sauberer.

Mach doch beim verlassen des Pressed nicht direkt ein Reset sondern ein Storyboard vom Pressed zum MouseOver - Im Augenblick wo man den Button los läßt ist man meistens ja noch über den Button.

Mir scheint als passiert intern folgendes

• Animation MouseOver baut eine Verbindung zum Property auf

• Animation startet

• Animation Presse baut auch eine Verbindung zum Property auf und nimmt so das vom MouseOver weg

• Animation startet

• Animation endet

• MouseOver animation endet auch

• MouseOver startet, hier baut er aber keine neue Verbindung auf da er glaubt er hätte sie schon

Ich habe rum gespielt aber auch keine Lösung gefunden.
Das einzigste was mir einfallen würde wäre ein getrikse.
Du hast die Ellipse doppelt, einer ist sichtbar der andere nicht, und je nach trigger wird der eine oder der andere Sichtbar geschalten. So hat dann jede Animation sein Control.

Oder du benutzt das PreviewMouseLeftButtonDown Event

Wenn der Hintergrund x:Null ist hilft auch das Preview nicht

http://msdn.microsoft.com/de-de/library/system.windows.uielement.previewmouseleftbuttondown.aspx ->

Although this routed event seems to follow a tunneling route through an element tree, it actually is a direct routed event that is raised and reraised along the element tree by each UIElement.

D.h. man Klickt durch das Canvas durch auf den Parent, aber beim Canvas kommt nie etwas an

Setz den Hintergrund des Canvas mal auf "Transparent". Wenn der Hintergrund null ist geht der Klick zum Parent hoch und das Canvas merkt nichts davon.

@David W
Hab das auch schon während des Debuggens angepasst, das verschiebt sich dann zT trotzdem wieder. Da muss dann ein Bug sein.

@winSharp93
Doofe Frage, aber: Wie? 😄
Wenn ich von meinen Fenstern eins auf dne zweiten Monitor ziehe, habe ich eben nur das einzelne Fenster auf dem zweiten und keine Tab-Gruppe. Und es lässt sich da dann auch kein zweites in das einzelne Fenster "reinziehen", so dass es zu mehreren Tabs wird. Wie hast du das denn angestellt?

In dem Neuen Fenster hast du wenn du mit Weiteren Dokumenten drüber gehst auch dieses "Docking Kreuz" in der Mitte, da drauf Ziehen.

Sei ma nicht so Faul...
Zwar merkwürdig aber als Entwickler muss man manchmal schon etwas Tippen 🤔

//Dazu
Die richtig faulen Entwickler binden eher die ganze Tabelle an ein DataGrid und lassen alle Spalten automatisch erstellen, statt es einzeln Drag & Drop zu machen. 😉
Wenn du nur Mausschubser sein willst such dir neue Arbeit :evil:

Die Fenstereinstellungen wärend des Debuggens ist nicht die Selbe wie beim Tippen.
D.h. beim Debuggen ändert er das Layout zu dem "Debugging Layout" - und beim beenden wieder zurück.

Starte doch das Debugging und passe das Layout dort auch genauso an.

Schreib den neuen Header Namen doch einfach rein -.-

Ich hab schon versucht mit RelativeSource wieder eine Ebene höher zu springen - also auf den View selbst. Aber dann kommt logischerweise, daß mein View diese Property auch nicht hat - die ist ja im ViewModel. Richtig, darum bindest du dann in den DataContext des View objektes rein...

{Binding DataContext.Bla, RelativeSource...

Nö, wegen dem OverrideMetadata
Da sagst du im prinzip "Schmeiß das alte Style von X weg und such es neu".

Dann sucht das .Net beim Applikationsstart nach den eingestellten Style im Themes Ordner "Aero.NormalColor.xaml" z.b. und wenn es das nicht findet nimmt er es aus der Generic.xaml als fallback.

So kannst du deinem Control native looks geben je nach Windows Theme (Classic, Luna, Aero).