Closed Mark-IDB closed 1 year ago
Hey @Mark-IDB - can you see if this might be related to #3008? That seems to be cause by an app-compat setting that sets Office and WebView2 DPI mode to system aware which causes some problems. Additionally, please check the Office documentation on DPI support to see if there's something there that might help: https://learn.microsoft.com/en-us/office/client-developer/ddpi/handle-high-dpi-and-dpi-scaling-in-your-office-solution
Otherwise we can open a bug to track this issue.
Hello @champnic.
The DPI handling in the VSTO seems normal. We have other winform windows which can be opened after the scale change. If the Webview2 Window is created on a non-main monitor the scaling is is handled without a problem. Only on the main-monitor the problem occurs. Webview2 isn't locked completly, i still can close the window through the taskbar. But interacting with the webview2 control is impossible.
Thanks for the info - I've added this bug to our backlog to take a look. Sorry you're hitting this!
Hey @Mark-IDB - We think this might be a related to a bug in windows that disallows connecting HWNDs with differing DPIs in SystemAware mode. In this case what's happening is that the host (Excel) and WebView2 are both launched in SystemAware (Enhanced/Per-process) with, say, 100% DPI. When the WebView2 is closed and the scale changes to 150%, the DPI of Excel stays at 100% because it's SystemAware instead of Per-Monitor Aware. Then when the second WebView2 is launched it gets the updated DPI of 150% and then fails parenting to the Excel HWND because Excel is 100% and WebView2 is 150%.
The current workaround is to disable the per-process DPI of Excel (which is also inherited by the child WebView2 processes). If you want to try this out, this can be done with the following regkey:
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files\\Microsoft Office\\root\\Office16\\EXCEL.EXE"="~ PERPROCESSSYSTEMDPIFORCEOFF"
If the path to Excel.exe is different in your machine you'll have to update to be the correct path.
We are working on a better fix here that we're tracking as part of #985. Thanks!
Description In a VSTO project the webview locks the window after a display scaling change. Most of the times the window can be closed but the webview content is not shown and sometimes even the mouse-cursor leaves a trail across the window. This happens when a laptop user disconnects the external monitor(scaling 100%) and switches to his laptop monitor (scaling 125%) The window with the webview must be opened before and it must be the main(!) monitor. This behaviour does not occur on a standalone executable and is reproducable in Outlook/Word/Excel. Repro is in an c# Excel VSTO.
Version SDK: 1.0.1518.46 Runtime: Evergreen (current 109.0.1518.61) Framework: VSTO/WinForms OS: Win10, Win11
Repro Steps
The microsoft site wil be opened normally (check if the window is opened on your main monitor!)
Close the window (do not keep it open!)
Change in the display settings the scale (up or down)
Open the window again
The content will now not be visible and the window locks (not allways) (screenshotting this is also not possible)
If you change the Left property (in frmWebview_Load to -1500 (if you have a monitor to the left of your main) so the window is opened on another monitor there will be no problem if you change the scale on that monitor. So the problem only occurs on the main monitor.
The webview window should be normally visible after changing the scale (through the interface or by disconnecting an external monitor)
Screenshots
Additional context ExcelAddInWebView.zip
AB#43216643