In the Crystal theme, the TitleBarBackground property is set through a style trigger to a static value. This leads to an unexpected result in the dark variation of the theme.
As a workaround you can use the following style:
This is reproducible only in the FluentTheme. Setting the RadCollapsiblePanel.SmallButtonsPerColumn to 3 does not make any difference. The workaround is to set a higher value for the ContentHeight property of RadRibbonView, for example 120px. The fix for this issue will be available with LIB (version 2018.3.1203) published on Monday, 3-rd December, 2018.
Workaround for this bug is setting Style.Triggers for this scenario. <Style BasedOn="{StaticResource RadRibbonSplitButtonStyle}" TargetType="telerik:RadRibbonSplitButton"> <Style.Triggers> <MultiTrigger> <MultiTrigger.Conditions> <Condition Property="IsChecked" Value="True"/> <Condition Property="IsEnabled" Value="True"/> <Condition Property="CurrentSize" Value="Medium"/> </MultiTrigger.Conditions> <MultiTrigger.Setters> <Setter Property="Foreground" Value="{DynamicResource CheckedBrush}"/> </MultiTrigger.Setters> </MultiTrigger> </Style.Triggers> </Style>
The current workaround is to handle the RadTabItems' PreviewMouseLeftButtonDown event like so: public MainWindow() { InitializeComponent(); EventManager.RegisterClassHandler(typeof(RadRibbonTab), PreviewMouseLeftButtonDownEvent, new MouseButtonEventHandler(OnClick), true); } private void OnClick(object sender, MouseButtonEventArgs e) { var tab = sender as RadRibbonTab; var ribbon = tab.ParentOfType<RadRibbonView>(); if (ribbon.IsApplicationMenuOpen) { ribbon.SelectedItem = tab; } }
This is tested and reproducible in the Office2016 and Material themes. Probably it can be reproduced also with other new themes which use glyphs. The CPU goes high because the RadRibbonGroup contains a GroupChrome element which has a TextBlock with the GlyphAdorner.ShowGlyphInDesignTime property set to True. To resolve this: 1.Extract the ControlTemplate of the RadRibbonGroup control. 2.Extract the ControlTemplate of the GroupChrome control. 3.Find the TextBlock element in the GroupChrome ControlTemplate. 4.Remove the telerik:GlyphAdorner.ShowGlyphInDesignTime setting from the TextBlock 5.Set the Template of the GroupChrome in the RadRibbonGroup ControlTemplate to the custom GroupChrome template. 6.Apply the custom RadRibbonGroup template.
The issue is reproducible in Fluent theme as well.
As a workaround, you can set the FocusVisualStyle of the DropDownPopupContent element in the template of the RadRibbonDropDownButton to null or add an implicit style for ContentControl setting the FocusVisualStyle to null.
If you have RadRibbonView control and xaml and design views are open, when click on some ribbon control (e.g. Tab or Button), the design view gets the focus and Smart Tag adorner is open. Moreover, the menu cannot be closed using "Close" button, but only when click outside the ribbon. Available in LIB version: 2017.2.605
Several galleries in collapsed state. Open rightmost so that its popup is outside wpf window. Then resize the window so that gallery goes into large state. The height of the RibbonGallery is incorrect and smaller than expected. Workaround is to set MinHeight to (for example 67) to all RibbonGalleries.
The title bar has a fixed White Background set. The workaround is to set the TitleBackground of RadRibbonView to Black.
Windows10 on two monitors, at least one of them is with higher DPI -125 , 150 %. This leads to unexpected black gap (glitch) between the RibbonWindow TitleBar and Content. Partial workaround is to set manually a margin on the WindowDecorator: private void RadRibbonWindow_Loaded(object sender, RoutedEventArgs e) { Grid windowDecorator = this.ChildrenOfType<Grid>().FirstOrDefault(x => x.Name == "MaximizedWindowDecorator"); windowDecorator.Margin = new Thickness(0, -1, 0, 0); }
In a two monitors scenario the ApplicationMenu appears on the left monitor when the RibbonView with negative left margin is hosted in a RibbonWindow which is maximized on the right monitor. EDIT: We are closing this issue as the described behavior as expected. When logged first, the negative left margin of RibbonView was not taken into account. When popup opens and its parent starts on the left monitor, popup calculates that it cannot fit entirely and changes its direction of opening. This expected by the WPF Framework. When you give negative left margin of the RibbonView, its application button might also goes with 1-2 (or more) pixels on the left monitor. Then popup (the application menu opens in a popup) has no space and changes its opening direction to left. This is expected and the only reasonable solution would be changing the negative left margin to positive or 0.
Fix available in LIB Version 2017.3.1009.