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?
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).
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.