Laden...
L
Benutzerbeschreibung

Forenbeiträge von Lector Ingesamt 862 Beiträge

24.02.2010 - 13:26 Uhr

Du musst dir dein eigenes Progress-Bar-Template schreiben.
Dieser Glanz-Effekt tritt übrigens nur bei Vista und höher auf.

23.02.2010 - 15:41 Uhr

Ich hab um die 30% Auslastung. Das ist schon ziemlich viel.

Vielleicht könntest du die Animationen optimieren indem du einfache Animationen statt KeyFrame-Animatinen verwendest.

Du könntest Freeze() von den Animationen aufrufen.

Den animierten Bubble-Layer in der Mitte kannst du evtl. in ein Control zusammenfassen und dieses dann als VisualBrush anzeigen. Das VisualBrush kannst du dann über eine TranslateTransform verschieben. Ich glaube du kannst sogar angeben dass das gekachelt werden soll. Somit brauchst du die Translation nicht mehr zurückzusetzen.

Wenn du die Geometrie eines Objektes als Data="..." direkt hinschreibst wird das Geometrie-Objekt auch gleich mit eingefroren. Das geht auch schneller als <RectangleGeometry .../>

Es gibt eine attached-Property AnimationTimeline.DesiredFramerate. Dieses Property steht per default auf 60. Wenn du es auf 30 herabsetzt brauchts evtl. weniger CPU.

Vielleicht konnte ich etwas helfen.

22.02.2010 - 11:43 Uhr

Das Grid ist ja ein Panel wie jedes andere auch.
Du könntest also ein ItemsControl hernehmen, die Collection per ItemsSource zuweisen und ein Grid als ItemsPanel benutzen.
Das Problem wir allerdings sein dass das Grid die Gui-Elemente nicht selbstständig positionieren kann wie ein StackPanel sondern Positionsangaben benötigt.
Evtl. kannst du im ItemsControl einen ItemContainerStyle angeben in welchen du den DataContext analysierst und die attached-Properties des ItemContainers entsprechend so setzt dass das Grid weis wie es die Items zu positionieren hat.

Mir ist jedoch schleierhaft wesshalb du ein Grid an eine Collection binden willst. Das Grid mag zwar ein sehr mächtiges Layout-Panel sein aber für das dynamische anzeigen von beliebig vielen Items ist es jedoch ungeeignet.
Evtl. bietet sich ja auch ein selbst geschiebenes Panel an. Oder wolltest du ein UniformGrid verwenden?

22.02.2010 - 09:38 Uhr

Im sender der EventArgs steht der Button drin welcher das Event ausgelöst hat.

19.02.2010 - 14:12 Uhr

Hallo,

Danke für die schnelle Antwort.
Ich habe jetzt alle nicht-generischen Interface-methoden von IList so wie Stefan O. beschrieben hat explizit implementiert. Sie sind jetzt von aussen nicht mehr direkt aufrufbar.

18.02.2010 - 19:32 Uhr

Hallo,

Ich entwickle eine eigene Collection. Dazu implementiere ich IList und IList<T>.
In beiden Interfaces gibt es die fast gleichen Methoden. Unterschiede gibt es jedoch teilweise in den Methodenparametern.

Bsp:


//In IList<T>
public int IndexOf(T item)
{...}

//In IList
public int IndexOf(object item)
{...}

Was mich hier stört ist dass es eine öffentlich sichtbare Methode gibt in der ein untypisierter Parameter übergeben werden kann. Ich habe mir mit dem .NET Reflector mal die Klasse List<T> angesehen. Diese implementiert so wie ich BEIDE Interfaces. Jedoch gibt es hier nur EINE IndexOf-Methode. Bei dem Methoden-Symbol sehe ich jedoch 2 lila Bommel als wären die Methoden zusammengefasst. Gibt es eine Möglichkeit wie ich auch soetwas bewirken kann?

15.02.2010 - 14:07 Uhr

Teile die TrianglesIndices.Count durch 3 und du hast die Anzahl der Polygone.
Da die 'Polygone' ja immer Dreiecke sind und die TrianglesIndezes immer nur die Verbindungen beschreiben kannst du so die Anzahl ermitteln

10.02.2010 - 18:19 Uhr

Vielleicht hilft dir das Stichwort UIAutomation weiter.

10.02.2010 - 09:26 Uhr

In WPF gehts mit IsHitTestVisible = false.
Dadurch werden alle MouseEvents durchgereicht.
Ich denke in Silverlight geht das genauso.

09.02.2010 - 11:02 Uhr

Nur den 'Nachteil' dass eben so oft in die Datei geschrieben wird. Aber das war doch genau das was du wolltest.

08.02.2010 - 17:54 Uhr

Zuerst solltest du einmal verstehen was das BringIntoView überhaupt macht:

Wenn du BringIntoView von einem FrameworkElement aufrufst wird das RequestBringIntoView-Event gefeuert. Der nächste übergeordnete ScrollViewer bekommt das mit und versucht zum entsprechenden Element zu scrollen. Sollte der ScrollViewer innerhalb eines ItemsControl sein und ein VirtualizingPanel genutzt werden welches IScrollInfo implementiert wird leitet der ScrollViewer den Methodenaufruf einfach an das Panel weiter.

Wenn du dir ein eigenes Panel schreibst welches du als ItemsPanel für die ListBox verwendest kannst du diese Methode sicher so implementieren dass das entsprechende Element mittig ausgerichtet ist. Unterschätze allerdings nicht den Aufwand wenn es darum geht ein VirtualizingPanel zu implementieren.

Alternativ könntest du mal mit dem Rect-Parameter dieser Methode rumspielen. Vielleicht hilft dir das weiter.

Ich hoffe ich konnte helfen.

08.02.2010 - 17:22 Uhr

Hallo,

Ich habe eine ListBox in der ich verschiedene Objekte darstelle. In den DataTemplates befinden sich verschiedene Controls: (TextBlock, Buttons, Slider)
Um Drag'n Drop zu ermöglichen benutze ich das MouseMove-Event der ListBox. Wenn ich jetzt ein ListBoxItem an einem TextBlock anfasse kann ich es verschieben. Wenn ich einen Button anfasse und verschiebe funktioniert dies nicht, da der Button einen MouseCapture macht und das MouseMove-Event verschluckt (e.Handled=true;). Dieses Verhalten ist auch so gewünscht.

Nun das Problem: Ein Slider oder eine ScrollBar leiten das MouseMove-Event (u.U.) weiter. Es ist mir allerdings schleierhaft warum. Eine Slider besteht bei mir lediglich aus einem Track. Der Track besteht aus 2 RepeatButtons und einem Thumb. Die RepeatButtons verschlucken das MouseMove. Der Thumb leitet es jedoch weiter wenn ihn langsam ziehe. Wenn ich schnell ziehe bekomme ich meistens kein MouseMove. Der Thumb hat trotz allem den MouseCapture.
Was mich besonders irritiert: Füge ich einen einfachen Track (ohne Slider/ScrollBar) in mein DataTemplate ein funktioniert alles wieder. Der Thumb verschweigt mir das MouseMove (wie gewünscht).

Gelöst habe ich das Problem momentan durch ein Attached-Behavior mit dem ich das MouseMove manuell unterbinden kann.

Was mich jedoch wirklich interressiert ist warum dieses Verhalten so auftritt. Ich habe Slider und ScrollBar bereits mit den .NET-Reflector untersucht und habe nirgens ein OnMouseMove() oder ähnliches entdeckt.
Vielleicht hat jemand von euch ja bereits Erfahrungen mit diesen Problem gemacht und weis mehr darüber. Wenn es eine sauberere Problemlösung als ein Attached-Behavior geben würde wäre ich daran auch interressiert.

05.02.2010 - 10:51 Uhr

<RadioButton.ContentTemplate>
<DataTemplate>
<TextBlock Text="{Binding Name}"/>
</...>

Mit diesen Template wird z.B. das Property Name vom Daten-Objekt angezeigt.
Wie dein DatenObjekt aussieht wirst du glaube ich selbst am besten wissen.

05.02.2010 - 09:04 Uhr

Ich kenne mach zwar nicht mit DataRows aus aber versuch doch mal den RadioButtons ein ContentTemplate zu verpassen. Wenn kein ContentTemplate vorhanden ist zeigt der ContentPresenter innerhalb der RadioButtons das entsprechende Objekt immer per ToString()-Methode an. Bei Enums mag das ganz praktisch sein. Wenn du ein Objekt mit standard-ToString()-Methode hast ist es natürlich ungünstig.

04.02.2010 - 14:24 Uhr

Die Lösung mit der Formel lässt sich nicht rein in XAML lösen.
Wenn der Code-Behind nicht gefällt schreib doch eine eigene Animation mit der du ein TranslateTransform-Objekt animierst. Der Animation gibst du dann noch den Mittelpunkt mit und interpolierst die Werte mit der einfachen Formel.

Du kannst dich auch mal näher mit PathAnimations beschäftigen. Vielleicht löst das dein Problem auch ganz einfach.

04.02.2010 - 09:32 Uhr

Hallo,

ggf. kann man auch eine RotateTransform mit geschickt gewähltem Center nutzen.

Vorrausgesetzt es macht dir nichts aus dass sich der Button auch um sein eigenes Zentrum dreht. Aus dem X wird dann halt manchmal auch ein +.

03.02.2010 - 13:48 Uhr

Ich kenne mich zwar mit dem CustomSort nicht aus aber vielleicht solltest du dafür sorgen dass die ItemsSource erst nach dem CustomSort gesetzt wird.
Wenn du die ItemsSource in XAML setzt musst du dafür sorgen dass deine SortKlasse auch in XAML gesetzt wird (vor ItemsSource). Das geht natürlich nur wenn diese Klasse einen parameterlosen Konstruktor hat.

03.02.2010 - 11:52 Uhr

Kein Problem.

Es gibt übrigens auch soetwas wie 'Attached Routed Events'.
Das was du gemacht hast ist ein 'Attached Dependency Property'.
Bei einem Attached-Event kannst du z.B. in XAML dann einen EventTrigger verwenden wie du es ursprünglich wolltest. Aber das funktioniert mit dem Property, wie du es gelöst hast, natürlich auch.

03.02.2010 - 08:43 Uhr

Wenn du im DragOver-Event e.Handeled auf true setzt sollte das übergeordnete Element kein DragOver mehr bekommen.

IsMouseDirectlyOver lässt sich soweit ich weis nicht mit einen EventTrigger verwenden. Du kannst aber einen normalen Trigger nehmen.
Wenn du unbedingt einen EventTrigger brauchst kannst du evtl. ein Attached-Event basteln und dieses bei einer Änderung des entsprechenden Properties feuern.

02.02.2010 - 13:51 Uhr

Da braucht man nichts nachbilden wenn man 'echte' RadioButtons verwendet.
Ich vermute du dachtest dass ich die ListBoxItems so style dass sie so ähnlich wie RadioButtons aussehen. Dem ist nicht so:

So in etwa mache ich das immer: (Der Code ist nur symbolisch und syntaktisch nicht korrekt)


<Style TargetType="ListBoxItem">
  <Setter Property="Template">
<Setter.Value>
<ControlTemplate>
<RadioButton IsChecked="{Binding RelativeSource=Self Path=IsSelected Mode=TwoWay}" Content={TemplateBinding Content}/>
</...>...

Das funktioniert übrigens auch mit ToggleButtons u.Ä.
Vorteil ist dass du (egal wie sie aussieht) nur eine ListBox behandeln musst. Ausserdem kannst du die Control-Arten schnell austauschen. Ersetze z.B. RadioButton durch ToggleButton

02.02.2010 - 09:20 Uhr

Ich benutze da immer eine ListBox und style die ListBoxItems so dass sie wie RadioButtons aussehen. Dann kannst du ganz normal deine Werte (männlich, weiblich) in die ListBox schreiben und SelectedValue/SelectedIndex abfragen.
Zusätzlich bekommst du durch diese Methode den automatischen Deselect geschenkt denn die ListBoxItems implementieren dieses Verhalten bereits.

29.01.2010 - 12:58 Uhr

Also ich habe mal folgendes ausprobiert:

KeyboardNavigation.IsTabStop="False" und
KeyboardNavigation.TabNavigation="None"

Die Tab-Taste konnte ich so aushebeln. Ich kann jedoch immer noch mit den Pfeiltasten navigieren.

EDIT:
Wenn ich per PreviewKeyDown die Pfeiltasten abfange funktioniert dies zwar allerdings bekommen dann die Control in den TabItems auch kein PreviewKeyDown.

26.01.2010 - 14:31 Uhr

Ich würde dir empfehlen das über TwoWayBinding zu realisieren.

Mache entweder eine TextBox ausserhalb der Liste welche an die entsprechende Eigenschaft des selektieren TreeViewElements gebunden ist:

z.B:


<TextBox Text="{Binding ElementName=treeView,Path=SelectedItem.Title,Mode=TwoWay,UpdateSourceTrigger=PropertyChanged}"/>

ODER

Baue dein Template so um dass du dort eine TextBox hast mit dem du die Einträge editieren kannst. Evtl. die TextBox nur einblenden wenn das Element selektiert ist.

Aus dem Code den du schreibst kann ich leider nicht erkennen wo der Fehler liegt. Wenn du meinen Ansatz verfolgst hat sich das aber eh erledigt. Falls nicht poste mehr Code. Wo kommt überhaupt tmpPrintUnit her? Wo wird das belegt? Welche Collection? usw.

26.01.2010 - 13:53 Uhr

Versuch doch mal als Stroke eine LinearGradientBrush zu verwenden.

26.01.2010 - 11:32 Uhr

Was verstehst du denn genau unter eine 'schwarz-weissen Linie'???
Wenn sich Schwarz und weis abwechseln ist das doch eine 'schwarz-weissen Linie'.
Wie genau soll deine Linie aussehen?

25.01.2010 - 16:55 Uhr

Das ist aber nur eine Spezialform von AttachedBehaviors. Bei mir gibt es viele andere Spezialfälle die ich damit ohne Ableitung lösen kann.

Bsp:
Hyperlink soll seine NavigationUri im Browser öffnen
Window soll das selektieren des System-Menüs unterbinden wenn der WindowBorder unsichtbar ist
ItemsControl soll Drag'nDrop unterstützen
ListBox soll den SelectedIndex aufheben wenn ein bestimmter Command kommt

Das sind z.B. alles Behaviors die sich NICHT generalisieren lassen. (Über den Begriff 'Behavior' lässt sich jetzt streiten) Wenn du ein RoutedEvent oft auf einen Command umbiegen möchtest ergibt es natürlich Sinn wenn du diese Behaviors zusammenfasst und mit einer einzelnen Klasse abdeckst.

25.01.2010 - 15:22 Uhr

VisualTreeHelper.GetChildren(root) gibt alle Kindelemente zurück. Die kannst du mit einen foreach durchschleifen. Beachte aber dass die KindElemente auch wieder Kinder haben...
Du müsstest das ganze dann rekursiv bauen.

Allerdings solltest du prüfen ob es keinen besseren Weg für dein Problem gibt.

25.01.2010 - 14:36 Uhr

Hallo,

Wenn ich ein TabControl habe kann ich mit der Tab-Taste oder den Pfeiltasten zwischen den selektierten Tab hin- und herspringen. Wie kann ich das unterbinden???

25.01.2010 - 13:11 Uhr

Doppelten Code habe ich auch selten. Aber im Fall von behaviors entsteht kein doppelter Code. Es wird ja nur ein Attached-Property mit changed-Handler erzeugt. Meine ganzen Behaviors machen ja komplett verschiedene Sachen.

25.01.2010 - 11:48 Uhr

Ja den Ansatz verstehe ich.

Ich habe mir für diesen Zweck ein VS-Snippet gemacht mit dem ich mir den ganzen Code generieren lassen kann.

Wenn du ein DependencyProperty machst tippst du auch nur 'propdp' ein und drückst Tab.
Für ein Behavior tippe ich nur 'behavior' ein, drücke Tab und fülle die on***Changed() aus. Der Aufwand ist genauso gering.

Bisher hatte ich auch nur relativ wenige, aber auch relativ spezielle Behaviors. Ich werde deine Lib mal etwas durchforsten und evtl. interressante Ansätze übernehmen.

25.01.2010 - 11:13 Uhr

Ich hab mir dein KeyBinding mal angesehen. Was mir gefällt ist der Ansatz mit dem attached-Properties. Was mir nicht gefällt ist dass du alles selbst programmierst.

Ich habe mir überlegt man könnte doch über die AttachedProperties ein eigenes Target-Property machen und dieses dann im Changed-Handler zuweisen:


/// <summary>
  /// Stellt zusätzliche Verhaltensweisen für InputBindings zur Verfügung
  /// </summary>
  public static class InputBindingBehavior
  {
    /// <summary>
    /// Ruft den Wert des CommandTarget-Properties ab
    /// </summary>
    /// <param name="obj">Bezugsobjekt</param>
    /// <returns>Wert des CommandTarget-Properties</returns>
    public static IInputElement GetCommandTarget(InputBinding obj)
    {
      return (IInputElement)obj.GetValue(CommandTargetProperty);
    }
    /// <summary>
    /// Setzt den Wert des CommandTarget-Properties
    /// </summary>
    /// <param name="obj">Bezugsobjekt</param>
    /// <param name="value">Neuer Wert</param>
    public static void SetCommandTarget(InputBinding obj, IInputElement value)
    {
      obj.SetValue(CommandTargetProperty, value);
    }
    /// <summary>
    /// Das InputTarget welches als CommandTarget benutzt werden soll
    /// </summary>
    public static readonly DependencyProperty CommandTargetProperty =
        DependencyProperty.RegisterAttached("CommandTarget", typeof(IInputElement), typeof(InputBindingBehavior),
        new UIPropertyMetadata(null, onCommandTargetChanged));
    private static void onCommandTargetChanged(DependencyObject sender, DependencyPropertyChangedEventArgs e)
    {
      InputBinding inputBinding = (InputBinding)sender;
      inputBinding.CommandTarget = e.NewValue as IInputElement;
    }
  }

Nur dummerweise funktioniert KEINERLEI Binding auf dem KeyBinding. Es scheint wohl daran zu liegen dass KeyBinding nicht wie die Controls im VisualTree ist o.Ä.
Warscheinlich ist das auch der Grund weshalb Microsoft die CommandTarget-Eigenschaft nicht als DependencyProperty implementiert hat obwohl InputBinding von DependencyObject ableitet...

25.01.2010 - 09:41 Uhr

Hallo,

Ich habe in meinen UserControl ein KeyBinding. Das CommandTarget des KeyBindings soll auf eine ListBox innerhalb des UserControls gesetzt werden. Und das wenn möglich in XAML.


<UserControl.InputBindings>
    <KeyBinding Gesture="Right" Command="{x:Static Controls:ListBoxBehavior.SelectNextCommand}" />
    <KeyBinding Gesture="Left" Command="{x:Static Controls:ListBoxBehavior.SelectPreviousCommand}" />
</UserControl.InputBindings>

<ListBox Name="list"/>

Das Problem ist dass die CommandTarget-Eigenschaft kein DependencyProperty ist. Ich kann also NICHT sagen CommandTarget="{Binding ElementName=list}".
Momentan weise ich das CommandTarget im Konstruktor nach InitializeComponent() zu. Weis jemand eine bessere Lösung?

22.01.2010 - 12:52 Uhr

Wenn ToString() "System.Object" zurückgibt kannst du davon ausgehen dass es sich um Instanzen vom Typ object und nicht um ints oder enums handelt.
Wenn du die Objekte nur ausgeben möchtest reicht es aus die ToString()-Methode aufzurufen. Dazu brauchst du keine Casts oder Reflection. In einer konkreten Klasse kannst du dann die ToString()-Methode überschreiben und eine eigene Logik implementieren. Die Klassen int und Enum übernehmen das allerdings schon für dich.

Prüfe doch ob in deinem Array auch wirklich int und enum-Werte stehen so wie du es erwartest. Wenn "System.Object" bei ToString rauskommt bezweifle ich dass es sich um einen speziellen Typ handlet. Warscheinlich liegt das Problem woanders.

21.01.2010 - 15:23 Uhr

Sieh dir mal über den .NET-Reflector an wie die Viewbox arbeitet. Vielleicht kannst du so rausfinden wie du an die Transformation gelangst. Ich vermute dass die ViewBox über Layout- oder Rendertransform arbeitet. Du müsstest nur herausfinden welches Element transformiert wird. Von diesen Element aus kannst du dann die Transformation auslesen.

19.01.2010 - 17:11 Uhr

in einem byte-Array belegt ein byte nur ein Byte. 😃

Dann würde es doch schon reichen als LookUp ein byte-Array zu benutzen. Als Index kannst du dann den zu spiegelnden byte-Wert nehmen. An dieser Stelle muss dann natürlich der gespiegelte Wert stehen. Da der Zugriff auf Arrays per Index bekanntlich schnell geht wird das auch nicht viel Laufzeit kosten. Allerdings musst du die Lookup am Anfang natürlich auch einmal erstellen. Das dürfte bei 256-Einträgen jedoch nicht allzu dramatisch sein.

19.01.2010 - 14:56 Uhr

Mir ist gerade ein besserer Weg eingefallen:


private void mirror(ref byte input)
{
    for (int i = 0; i < 4; i++)
    {
        input ^= (input & (1 << i)) << (7-i);
        input ^= (input & (1 << (7-i))) >> i;
        input ^= (input & (1 << i)) << (7-i);
    }
}

Hier wird immer das letzte Bit mit dem ersten Bit per XOR vertauscht.
Das gleiche dann mit dem vorletzten Bit und dem 2. Bit.
Beim 4. Durchlauf sollte alles gespiegelt sein.
Evtl. musst du noch auf byte casten.

19.01.2010 - 14:41 Uhr

Also ich hätte da folgende Idee:


private byte mirror(byte input)
{
byte output=0;
output |= input & 1 << 7;
output |= input & 2 << 6;
output |= input & 4 << 5;
...
return output;
}

das lässt sich natürlich auch in eine Schleife packen:


private byte mirror(byte input)
{
byte output=0;
for(int i=1;i<=8;i++)
{
output |= input & i << (8-1);
}

return output;
}

Vorraussetzung meine Idee oben funktioniert. Ich habe das nicht getestet. Wenn das funktioniert kannst du alle Bytes die aus deinen Stream kommen auf diese Weise spiegeln.

18.01.2010 - 17:39 Uhr

Du könntest im ItemContainerStyle einen Style für die ComboBoxItems machen. Darin könntest du dann über einen Setter die Visibility setzen.

18.01.2010 - 16:26 Uhr

Hallo,

Danke für den Tipp. Ich werd mir dieses Framework mal anschauen.
Ich benutze ein eigenes MVVM-Framework in dem sowas wie ein 'MainViewModel' nicht vorgesehen ist. ViewModels sind bei mir ausschließlich Kapselungen von Fachklassen.

18.01.2010 - 13:24 Uhr

Die Anzeige wird von der GPU gemacht. Die Berechnung des aktuellen Wertes von der CPU.
Hintergrund ist dass die Animation sich nur auf ein DependencyProperty bezieht. Diese ist unabhängig von der GUI und kann sich auf alles mögliche beziehen. Für jeden Datentyp gibt es eine eigene Animationsklasse. Du kannst für andere Typen auch eigene Animationsklassen erstellen. Das funktioniert alles über die CPU.
Das Rendering der GUI wird von der GPU gemacht. Auch wenn das Rendering abhängig von bestimmten Eigenschaften eines Visuals ist. (z.B. die Width-Eigenschaft eines Buttons). Ob die Width-Eigenschaft des Buttons nun animiert ist oder nicht ist in diesem Szenario nicht mal bekannt.

18.01.2010 - 13:01 Uhr

Hallo,

Ich habe eine MVVM-Anwendung. Das Hauptfenster besteht aus einem TabControl. In den einzelnen Tabs sind UserControls.
Nun habe ich tief in diesen UserControl Buttons mit denen ich gerne einen anderen Tab auswäheln würde. Ausserdem soll das Formular in diesen Tab mit entsprechenden Werten gefüllt werden.

Wie mache ich das am saubersten???

Über XAML ist das leider nicht möglich da ich darüber auf kein übergeordnetes Element zugreifen kann. Momentan löse ich es dadurch dass ich im CodeBehind per VisualTreeHelper mir das Hauptfenster hole und dort eine Methode aufrufe. Das Hauptfenster wiederum selektiert den richtigen Tab und setzt seinen DataContext.
Diese Lösung gefällt mir jedoch nicht.

Hat jemand von euch schon mal ähnliche Szenarien gehabt, oder weis vielleicht irgendjemand einen besseren Lösungsansatz???

14.01.2010 - 16:20 Uhr

Problem für meinen Fall gelöst.
Auch wen es nicht ganz perfekt ist da diese Lösung nur mit custom ToggleButton-Style funktioniert.

14.01.2010 - 15:59 Uhr

Sämtliche Brushes sind bereits als Resource definiert. Was ich jedoch nicht auslagern kann ist das MouseOver, Pressed, Disabled-Verhalten.

Ich habe aber gerade festgestellt dass RadioButton von ToggleButton abgeleitet ist. Da müsste sich der Style ja trotzdem zuweisen lassen. Folgender Style funktioniert:


<Style TargetType="{x:Type ListBoxItem}" x:Key="toggleButtonItem">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="{x:Type ListBoxItem}">
                    <RadioButton IsChecked="{Binding RelativeSource={RelativeSource TemplatedParent},Path=IsSelected,Mode=TwoWay}"
                                 Style="{DynamicResource {x:Type ToggleButton}}">
                        <ContentPresenter/>
                    </RadioButton>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>

Ich weis jedoch nicht was passiert wenn kein eigener Style für ToggleButton gesetzt ist.

14.01.2010 - 14:34 Uhr

Die Lösung mit dem RadioButton klingt gut. Aussehen kann ich auch verändern. Jetzt muss ich es nur noch hinbekommen dass ich diesem RadioButton da Default-Aussehen des ToggleButtons gebe.
Normalerweise habe ich in einem globalen ResourceDictionary Styles für verschiedene Typen definiert so dass sie automatisch zugewiesen werden. Aber kann ich einem RadioButton das Default-Template des ToggleButtons geben???
Wenn ich dem Radio-Button einfach in einem Template einen ToggleButton zuweise habe ich das gleiche Problem wie vorher: Man kann die Items wieder abwählen.

14.01.2010 - 10:48 Uhr

Es soll nicht möglich sein die Selekterung durch klicken aufzuheben.
Also das gleiche verhalten die bei dem Standard-ListBoxItems. Die kann man mit einem Klick auch anwählen bleiben dann aber selektiert. Man kann die Selektierung durch klicken eines anderen Items umschalten. Wenn man das selektierte Item klickt soll dieses jedoch selektiert bleiben.

14.01.2010 - 10:41 Uhr

Hallo,

Ich habe eine ListBox aus ToggleButtons. Das Problem dabei ist dass man die ToggleButtons wieder abwählen kann und somit die Selektierung der ListBox aufhebt.
Gibt es eine Möglichkeit das zu unterbinden?


<Style TargetType="{x:Type ListBoxItem}" x:Key="toggleButtonItem">
            <Setter Property="Template">
                <Setter.Value>
                    <ControlTemplate TargetType="{x:Type ListBoxItem}">
                        <ToggleButton IsChecked="{Binding RelativeSource={RelativeSource TemplatedParent},Path=IsSelected,Mode=TwoWay}">
                            <ContentPresenter/>
                        </ToggleButton>
                    </ControlTemplate>
                </Setter.Value>
            </Setter>
        </Style>

13.01.2010 - 18:01 Uhr

Keyboard.IsKeyDown(Key.LeftShift);

Ziehe aber auch die Möglichkeit in Betracht dass die Tastatur mittlerweile kaputt ist und einen Wackelkontakt hat.