This seems to be a bug in Office products in the way they handle the processing of the WM_DPICHANGED message. The application is supposed to enumerate all of its child windows and rescale them in response to the message but it's somehow failing to process add-in panes properly.
What you can do to work around the bug is disable DPI scaling. You say you tried invoking SetProcessDpiAwareness, but that function is documented to fail once DPI awareness has been set for an app, and the app you're using clearly has it set because it works for the parent window. What you are supposed to do then is invoke SetThreadDpiAwarenessContext, like in this C# wrapper. Unfortunately I don't have a Win10 multimon setup to test this myself, but that's supposed to work as the application is running. Try this add-in, it has a button to set thread DPI awareness context, and see if that works for you.
The application hook approach
Since SetThreadDpiAwarenessContext may not be available on your system, one way to deal with the problem is to make the main window ignore the WM_DPICHANGED message. This can be done either by installing an application hook to change the message or by subclassing the window. An application hook is a slightly easier approach with fewer pitfalls. Basically the idea is to intercept the main application's GetMessage and change WM_DPICHANGED to WM_NULL, which will make the application discard the message. The drawback is that this approach only works for posted messages, but WM_DPICHANGED should be one of those.
So to install an application hook, your add-in code would look something like:
public partial class ThisAddIn
{
public enum HookType : int
{
WH_JOURNALRECORD = 0,
WH_JOURNALPLAYBACK = 1,
WH_KEYBOARD = 2,
WH_GETMESSAGE = 3,
WH_CALLWNDPROC = 4,
WH_CBT = 5,
WH_SYSMSGFILTER = 6,
WH_MOUSE = 7,
WH_HARDWARE = 8,
WH_DEBUG = 9,
WH_SHELL = 10,
WH_FOREGROUNDIDLE = 11,
WH_CALLWNDPROCRET = 12,
WH_KEYBOARD_LL = 13,
WH_MOUSE_LL = 14
}
delegate IntPtr HookProc(int code, IntPtr wParam, IntPtr lParam);
[DllImport("user32.dll", SetLastError = true)]
static extern IntPtr SetWindowsHookEx(HookType hookType, HookProc lpfn, IntPtr hMod, uint dwThreadId);
[DllImport("user32.dll")]
static extern IntPtr CallNextHookEx(IntPtr hhk, int nCode, IntPtr wParam, IntPtr lParam);
[StructLayout(LayoutKind.Sequential)]
public struct POINT
{
public int X;
public int Y;
}
public struct MSG
{
public IntPtr hwnd;
public uint message;
public IntPtr wParam;
public IntPtr lParam;
public uint time;
public POINT pt;
}
HookProc cbGetMessage = null;
private UserControl1 myUserControl1;
private Microsoft.Office.Tools.CustomTaskPane myCustomTaskPane;
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
this.cbGetMessage = new HookProc(this.MyGetMessageCb);
SetWindowsHookEx(HookType.WH_GETMESSAGE, this.cbGetMessage, IntPtr.Zero, (uint)AppDomain.GetCurrentThreadId());
myUserControl1 = new UserControl1();
myCustomTaskPane = this.CustomTaskPanes.Add(myUserControl1, "My Task Pane");
myCustomTaskPane.Visible = true;
}
private IntPtr MyGetMessageCb(int code, IntPtr wParam, IntPtr lParam)
{
unsafe
{
MSG* msg = (MSG*)lParam;
if (msg->message == 0x02E0)
msg->message = 0;
}
return CallNextHookEx(IntPtr.Zero, code, wParam, lParam);
}
private void ThisAddIn_Shutdown(object sender, System.EventArgs e)
{
}
#region VSTO generated code
private void InternalStartup()
{
this.Startup += new System.EventHandler(ThisAddIn_Startup);
this.Shutdown += new System.EventHandler(ThisAddIn_Shutdown);
}
#endregion
}
Please note that this is largely untested code, and if it works in blocking the WM_DPICHANGED message you will probably have to make sure to clean up by removing the hook before application exit.
The subclassing approach
If the message you want to block is not posted to the window, but sent instead, the application hook method is not going to work and the main window will have to be subclassed instead. This time we will place our code within the user control because the main windows needs to be fully initialized before invoking SetWindowLong.
So to subclass the Power Point window, our user control (which is within the addin) would look something like (note that I am using OnPaint for this but you can use whatever as long as it's guaranteed that the window is initialized at the time of invoking SetWindowLong):
public partial class UserControl1 : UserControl
{
const int GWLP_WNDPROC = -4;
[DllImport("user32", SetLastError = true)]
extern static IntPtr CallWindowProc(IntPtr lpPrevWndFunc, IntPtr hWnd, uint uMsg, IntPtr wParam, IntPtr lParam);
[DllImport("user32", SetLastError = true)]
extern static IntPtr SetWindowLongPtr(IntPtr hWnd, int nIndex, IntPtr lpNewLong);
[DllImport("user32", SetLastError = true)]
extern static IntPtr SetWindowLong(IntPtr hWnd, int nIndex, IntPtr lpNewLong);
delegate IntPtr WindowProc(IntPtr hwnd, uint uMsg, IntPtr wParam, IntPtr lParam);
private IntPtr origProc = IntPtr.Zero;
private WindowProc wpDelegate = null;
public UserControl1()
{
InitializeComponent();
this.Paint += UserControl1_Paint;
}
void UserControl1_Paint(object sender, PaintEventArgs e)
{
if (origProc == IntPtr.Zero)
{
//Subclassing
this.wpDelegate = new WindowProc(MyWndProc);
Process process = Process.GetCurrentProcess();
IntPtr wpDelegatePtr = Marshal.GetFunctionPointerForDelegate(wpDelegate);
if (IntPtr.Size == 8)
{
origProc = SetWindowLongPtr(process.MainWindowHandle, GWLP_WNDPROC, wpDelegatePtr);
}
else
{
origProc = SetWindowLong(process.MainWindowHandle, GWLP_WNDPROC, wpDelegatePtr);
}
}
}
//Subclassing
private IntPtr MyWndProc(IntPtr hwnd, uint uMsg, IntPtr wParam, IntPtr lParam)
{
if (uMsg == 0x02E0) //WM_DPICHANGED
return IntPtr.Zero;
IntPtr retVal = CallWindowProc(origProc, hwnd, uMsg, wParam, lParam);
return retVal;
}
}
