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.