A client of mine has an application where they are attempting to customize the look of the application, chrome and all. Normally with <Window> you can simply set AllowsTransparecy="True" and WindowStyle="None" and knock yourself out (it's understood that you then have to completely take care of things like resizing, maximize, close, etc. on your own).
Anyway, it appears you cannot set this flag if you use XamRibbonWindow.
Creating a blank WPF app and swapping out the MainWindow.xaml with
<igRibbon:XamRibbonWindow x:Class="WindowTest.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:igRibbon="http://infragistics.com/Ribbon" Title="MainWindow" Height="350" Width="525" ResizeMode="CanResizeWithGrip" WindowStyle="None" AllowsTransparency="True"> <igRibbon:RibbonWindowContentHost> </igRibbon:RibbonWindowContentHost> </igRibbon:XamRibbonWindow>as well as changing the .cs class to inherit XamRibbonWindow, this crashes with the follow stack trace on Win8 at System.Windows.Media.Composition.DUCE.Channel.SyncFlush() at System.Windows.Media.MediaContext.CompleteRender() at System.Windows.Interop.HwndTarget.OnResize() at System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage msg, IntPtr wparam, IntPtr lparam) at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)I'm pushing for not overriding the chrome since the amount of effort involved isn't really worth the ROI, but this is an odd behavior I've been able to reproduce on several different machines.On Win7, the app won't run at all. You doubleclick and nothing happens.
Is there something I am missing or is this a real issue?
If they want the window to have that look whether glass is on or not then you really need to use a regular Window and provide the chrome (yourself or maybe using something like the shell integration library). If they are ok with letting the OS provide the chrome (i.e. the background of the caption area and the OS caption buttons) when desktop composition (i.e. aero glass) is enabled but want the look you are describing when desktop composition is enabled then you might be able to provide custom styles/templates for the WindowContentHost & XamRibbon. When the xamRibbon is automatically collapsed (i.e. AutoHideEnabled is true and the window's width/height is below the AutoHideHorizontal|VerticalThreshold) the WindowContentHost provides the caption area otherwise the xamRibbon provides it since it needs to integrate the positioning of the QAT, etc so if you're not using the autohide functionality then you can just deal with the xamRibbon. If you want to go this route then you can look at the default xaml we provide as part of the install and create your own modified xamRibbon template. The template contains an element that defines the buttons so you can change the look of the buttons and the color of the title bar. Again this part is really only going to work when desktop composition is not enabled - at least currently; you could submit a suggestion for adding a property to the xamRibbon(Window) so it can opt out of supporting/using the glass.
Andrew, it is a squirrelly thing to be sure, and easily reproducible so the client is more than willing to go with 'out of the box' functionality.
The biggest thing is they want the title bar to be a specific color and override the control buttons on the right with their own. This... mostly works. The issue is the chrome isn't the same color and, given the user's window color settings, can be odd looking.
However, that's up to the user to decide if they want freaky, aqua colored windows, so...
Thanks for the response.
I've seen that error come up in other applications not using xamRibbonWindow and it is typically a video driver issue. That being said there's really no reason to use xamRibbonWindow if you're not going to let it control the chrome and it wasn't designed/meant to be used in that way. The xamRibbonWindow was designed to provide the Office 2007/2010 style window UI - i.e. use the OS glass when desktop composition is enabled and try to suppress the OS non-client rendering when it does not use desktop composition. If you don't want that then you should just use a Window and set its WindowStyle/AllowsTransparency/etc and host a xamRibbon within the window (e.g. occupying a row in a Grid panel where the Height is Auto).