Hi Team,
I am facing XamRibbonWindow title bar overlap issue when I am launching my WPF application via Win Form.
I am using "Office2k7Black" theme in the ribbon. Sample project attached with the ticket.
I need fix of this problem in WPF code with Office2k7Black theme.
This issue is reproducible in with Office2k7Black theme. This functionality is working with "Office2010" theme.
Environment : Windows 10
Technology: Winforms & WPF
Hello Anoop,
I am assisting you with XamRibbonWindow overlap the window and not able to click on min, max and close button issue through your private case ‘CAS-196672-G6G5V2’ as you provided your sample code in that.
Please let me know if I may be of further assistance or if this case may be closed.
Hi Divya - As I said previously that I am not able to click on windows 'Min, Max & Close' button just because of your Infragistics Office2k7Black theme. I need all these button clickable in the sample project with the same theme.
Please fix this issue in WPF sample project only not in Win forms.
Hi Divya,
I tried to implement your suggestion in my sample code but it’s still not working.
Can you please implement those changes in the sample project (attached with ticket# CAS-196672-G6G5V2) and send back to me?
Anoop,
I just want to clarify what was causing the issue and what will happen with the fix. The Office 2007 themes were designed to display like Office 2007. Office 2007 will let the OS render the title bar buttons when glass/desktop composition is active. When glass/desktop composition is not active (such as when the theme is changed to classic or one of the high constrast themes) they suppress the os provided non-client area and render custom non-client area. They do this because when the OS is rendering the old style non-client area it does not really allow rendering anything else in that area as the OS will re-render that outside the WM_NCPAINT in response to many different changes/messages. So our Office 2007 themes (and the xamRibbonWindow) work the same way. If we detect that the OS is using glass/desktop composition then we let it render the non-client area and try to let our elements overlap that area. When we detect that the OS is not using glass/desktop composition then we suppress the non-client area and have elements in the templates that act as the non-client area buttons.
The problem that was happening in your sample was that it was explicitly suppressing the themed non-client rendering for the application. It did this by setting the Application.VisualStyleState to ClientAreaEnabled thereby disabling it for the non-client area for the entire application. So the non-client area for all top level windows within that application will essentially be rendered as though the OS theme were disabled - you can see this if you show any WF Form or WPF Window - the title bar and other non-client area will look different than if you do not set the VisualStyleState. The fix we had to make was to ensure that we detect that scenario and treat it such as we would if the OS theme were disabled and so the OS non-client rendering will be suppressed and the non-client area buttons, etc in the template will be used. So with the fix the xamRibbonWindow when run within that WF sample will not look like it does when you run the WPF sample just as any other window (WF Form or WPF Window) does not because the WF sample is explicitly suppressing the OS theme rendering for the non-client area. Instead it will look as it (and Office 2007) would look if you suppressed themes at the OS level.
Note the reason the Office 2010 themes don't have this issue is that Office and the xamRibbon(Window) always suppress the non-client area rendering of the OS and renders the non-client area itself so whether glass/desktop composition is enabled for the app or not doesn't matter.
If you need to continue using 16.1 then I would suggest you change the setting of the VisualStyleState to include the non-client area (e.g. use ClientAndNonClientAreasEnabled which I believe is the default).
The comments that Divya provided are related to how the developer fixed development issue 254850 in our code. This is a change in our assemblies and to get the fix you will need to upgrade the assemblies.
Per our product lifeclycle we provide service releases for one year from the release of any volume which means that only 2017 Volume 2 and 2018 Volume 1 are currently maintained and receiving service releases. As such it will be necessary for you to upgrade you application to one of these volumes to get the fix.
Please note that even if we did still provide service releases for 2016 Volume 1, upgrading to a new service release requires that you test your entire application just like if you upgrade to a new volume release. The recommendation is that you upgrade to 2018 Volume 1 as that will be maintained and supported the longest.
I am using Infragistics V16.1 for WPF. Please provide the Infragistics patch on this version.
Hello Anoop ,
Thank you for the update.
As you are having initial issues implementing the work around into your internal code, I have requested to provide you the private/bi-weekly builds in order to fix the issue ASAP. I’ll keep you updating with our progress.
Also as the case has created as a trial customer I would like to know which version of control you are using (V18.1 or V17.2) to provide you the builds ?
I would also recommend you to register your product key with the account in order to not showing you as a trial customer.