Analyse-it on Fri, 22 Jun 2018 10:46:16
We're changing our application to support HDPI on a per monitor basis, as the latest versions of Microsoft Excel 2016 support.
We can scale our own dialog boxes, and get notifications when the DPI of our windows change, but the ActiveX control we use when calling ICTPFactory.CreateCTP is always created with 96 dpi and only SystemAware DPI awareness. If I use GetDpiForWindow & GetWindowDpiAwarenessContext on the parent windows, I can see the parent window of our window (CMMOcxHost) is 96dpi/SystemAware, but the CMMOcxHostChildWindowMixedMode window and it's parents are all 144dpi/MonitorAware.
The following image shows the windows from Spy++ (see below). The windows below the red line are all created as SystemAware (no doubt by changing the thread DPI awareness), but the windows above are all monitor aware. I want the CMMOcxHost to be MonitorAware so we can then drawn our window in high resolution.
Is there a registry setting that tells Office that our taskpane ActiveX control is HDPI aware? The DLL hosting our ActiveX control has a manifest indicating support for Windows 10 and <windowsSettings><dpiAware>true</dpiAware></windowsSettings> so I assume the Office taskpane is not using that to determine DPI awareness?
Can a member from the Excel/Office developer team advise please?
Terry Xu - MSFT on Tue, 26 Jun 2018 08:00:41
Thank you for posting in the MSDN Forum.
I'm trying to involve some senior engineers into this issue and it will take some time. Your patience will be greatly appreciated.
Sorry for any inconvenience and have a nice day!
Analyse-it on Tue, 26 Jun 2018 08:52:40
Thanks Terry. I think it's only the senior developers that will know the answer as it's not documented yet since it's such a new feature of Office 2016/365. I look forward to hearing their response.
Analyse-it on Mon, 02 Jul 2018 09:56:23
Just chasing this up... any answer yet?
Analyse-it on Thu, 12 Jul 2018 11:32:27
Can I get a reply to this please? It's important to the users of our product and unfortunately there seems to be no other way to contact the Office development team. If Office/Excel does not support high DPI task panes at present that's fine, but a response would be welcome. I raised a support issue through our MSDN subscription but did not get us an answer either.
Fei Xue on Mon, 23 Jul 2018 08:30:24
Sorry for the late responding.
>I raised a support issue through our MSDN subscription but did not get us an answer either.
Did you mean submit a incident like described in this link? If yes, I suggest that you keep following it to get a workaround or solution. And if not you can submit a incident because of its complexity your question falls into the paid support category which requires a more in-depth level of support. If the support engineer determines that the issue is the result of a bug the service request will be a no-charge case and you won't be charged. Please visit the below link to see the various paid support options that are available to better meet your needs.
Thanks for your understanding.
Regards & Fei
Analyse-it on Mon, 23 Jul 2018 10:50:58
Thanks for your reply Fei.
We did submit a paid support incident, it was incident number 118062218441908 but we didn't get a suitable reply. Unfortunately it is a very technical request and although the replies were as helpful as possible, it didn't get escalated to the Office developers who are surely the only people who can answer such a request.
I say that because I can see that for add-ins, Microsoft Excel is calling SetThreadDpiAwarenessContext to force add-in CreateWindowEx calls to SystemDPIAwareness rather than MonitorDPIAwareness and I can't find anyway to indicate that Excel should not do so for our add-in. Adding a manifest to our add-in DLL indicating monitor DPI awreness doesn't help. So there must be either currently no way to change this behaviour (likely as it's new), or there is a manifest or registry configuration that will ensure Excel does not change SetThreadDpiAwarenessContext for our add-in.
It just seems like this query (and our paid support incident) is not getting to the people who can answer this very specific / technical enquiry.
Fei Xue on Tue, 24 Jul 2018 05:10:27
Thanks for the detail info for this issue.
Based on the ticket number, I noticed that the case already to be dispatched the correct team. I am also trying to confirm the progress of current issue. If there is any update, I will be back to post here.
Regards & Fei
Analyse-it on Fri, 10 Aug 2018 12:57:56
Analyse-it on Mon, 17 Sep 2018 18:08:19
This support request, including a private one direct to Microsoft (which did not get a proper response), have been outstanding for over 3 months now. We have customers requesting a high resolution user interface for our Excel add-in. Can a Microsoft engineer please provide a solution to this issue ASAP.
Analyse-it on Mon, 10 Dec 2018 15:25:53
Nearly six months now, and still no response. What's going on? Such a simple question to the development team at Microsoft. We just need a simple setting in the registry under the CLSID for the task pane that indicates the task pane is DPI aware and doesn't need scaling (it will present a high resolution version). This really shows how much Microsoft values it's developers, even those who have worked on MS platform and Office solutions for over 25 years.
TheExcelAutomator on Fri, 22 Feb 2019 04:46:54
Has there been any progress on this thread guys?
My company is in a similar predicament and we're really struggling to understand how Excel 2016 handles DPI awareness with the different APIs.
In our case the GetProcessDpiAwareness API is returning System DPI Aware but in some regards Excel is demonstrating per-monitor DPI awareness-like behavior.
Keen to understand from Microsoft if there's some clarifying documentation on how DPI awareness works in Excel 2016 and how it should be managed by COM add-ins...
Analyse-it on Wed, 27 Feb 2019 09:55:50
We've had a lot of queries from customers asking why our user interface is blurry. It's a really tough situation as there is absolutely nothing we can do until Microsoft provides support. I raised a paid support incident but it went no where -- really that should have been refunded. The Office team it reached didn't even understand the problem, or really what I was talking about, and left me with only a promise to "try" raise it with the actual Office developers. But that never happened. Really disappointing support from Microsoft for their developers, especially those like ourselves that have been working with Excel since 1991.
What I found when digging into this problem is that Excel uses per-monitor DPI, but any call into an add-in resets the DPI awareness to system. You can try to change it to per-monitor DPI, but then when you call CreateWindow(Ex) the window will come back with system DPI configuration. If you create the window with the desktop as parent window then you can set per-monitor DPI awareness, but as soon as you parent that window to an Excel taskpane it will revert to system DPI. The taskpane seems to contain a wrapper window which becomes the parent of any content window, and it's from there down the parent-child chain that system DPI settings are inherited and override any attempts to be per monitor DPI. All we need is a simple configuration setting in the registry to indicate that our add-ins taskpanes are per-monitor DPI aware. I know Add-in Express don't have this issue, but then they don't use a standard Excel task pane. I believe they use old OLE interfaces to reserve space at the edges of the application's MDI interface, then place their own per-monitor DPI window there -- not docked in a taskpane where the system DPI settings would be inherited. So, no solution to this as far as I can see without Microsoft explicitly supporting an option in the add-in registry settings (or reading the COM add-in DLL manifest -- which BTW doesn't make any difference either).
Vytautas A on Wed, 27 Feb 2019 11:26:32
I'm not sure or this is linked somehow. Is this problem happening only Office 2016/2019 ?
Can you try to change Office settings: File -> Options -> General -> scroll TOP(i always need to scroll) -> You will find "When using multiple displays:" -> "Optimize for compatibility" make checked. Try again?
Analyse-it on Wed, 27 Feb 2019 11:32:06
Thanks for your input. We are aware of this option but it does not solve the problem/question. It does help provide support for older add-ins with a system DPI user interface, but it does not allow add-ins to provide a per-monitor high DPI interface -- which is the whole point of this thread.