Cannot move application window since 2012.2.571 build

Hi Austin,

We have updated things to help with some black area rendering in the newer RibbonWindow implementation and we have a preview build of these changes for the upcoming maintenance release we could give you to see if it fixes that.

It may also fix the other issue.  If you write our support address and reference this post, we'll give you the link to it.

Hey guys,

We have upgraded to version 2012.2.572 recently in order to get a solution to one of our outstanding issues. Afterwards we noticed that we are having the same symptoms as the title of this bug report.

I also noticed that the official sample application demonstrating a Ribbon Window with Docking functionality does not suffer from this problem.

Now I am wondering what the official status of this bug is?

Hi Andras,

Part of the updates to RibbonWindow include using a more Windows native hit testing.  Since RibbonWindow can render WPF UI elements in the title bar area (like the QAT and contextual tab groups), it also means that the UIElements containing the Ribbon within your code also extend up there (although they usually have null or Transparent backgrounds).  I mean things like a DockPanel or Grid that might be the child element of your Window and contains Ribbon.

We do our best to skip over Panels and things with null backgrounds but there could be cases where our logic finds an element you've defined in your XAML and we stop at it when hit testing the title bar area.  The way to fix this is to examine all the elements in your XAML that contain Ribbon.  Start at Ribbon and walk up the chain.  See if you have any Panels or other controls with Backgrounds set.  If you find something, try and clear its background.

You also can set this attached property on any elements that you think could be causing the hit testing issue (again it should be an ancestor of Ribbon up to Window):

themes:WindowChrome.ElementKind="NonClientArea"

That tells the element to be skipped over by our hit testing code.

If none of those things help, please repro it in as simple of a new sample project as you can and we'll debug.  But one of those things should help you solve the problem.

Thanks,

We have had modified the styles of the Ribbon in our application long ago. During the upgrade to version 2012.2.572 we didn't touch those styles and therefore themes:WindowChrome.ElementKind attached property was not used at all. We compared the new Ribbon styles to our customised ones focusing on this attached property and introduced them wherever it was needed. 

This fixed the problem for us.

Thanks again for the quick reply.

Added that attribute:

themes:WindowChrome.ElementKind="NonClientArea"

to the two grids and adorner decorators that were encapsulating our ribbon and it did the trick.  I know this response was a long time coming, but I just got a chance to re-evaluate this issue.  Thanks again for the responses.

I have recently upgraded our ribbon-based WPF application from build v10.2.0532 to build 13.2.590.0 and am observing the same behavior: I cannot move the application window anymore. I futher notice a couple of data binding issues in that area:

System.Windows.Data Error: 4 : Cannot find source for binding with reference 'ElementName=PART_Popup'. BindingExpression:Path=HasDropShadow; DataItem=null; target element is 'PopupButton' (Name=''); target property is 'NoTarget' (type 'Object')

System.Windows.Data Error: 4 : Cannot find source for binding with reference 'ElementName=PART_Popup'. BindingExpression:Path=HasDropShadow; DataItem=null; target element is 'QuickAccessToolBarOverflowButton' (Name='OverflowButton'); target property is 'NoTarget' (type 'Object')

I have been doing a side-by-side comparison with the code in ProductSamples\RibbonSamples\Demo\DocumentEditor but so far have not spotted any non-trivial difference (e.g., different name string or icon paths). I have inserted the "NonClientArea" attribute as suggested above but still no improvement.

Hi Philipp,

There must be some element you are missing that attribute on that is blocking the default title bar element from being hit tested.  If you want to put together a new simple sample project that shows this happening and send that to our support address, we can debug it and tell you what's causing it and what to do to fix it (it's likely an easy fix).  Please rename the .zip file extension and reference this post.  Thanks!