2

I'm attempting to finalise high DPI support for an Office COM Add-In running .NET Framework 4.6.2. I'm following the principles outlined by Microsoft for handling DPI Scaling in Office. The only approach that can be used for Office add-ins is to set the DPI awareness per-thread, as the typical manifest and startup solutions aren't available.

The form I'm scaling is a Forms window hosting a WPF UserControl in an Element Host. This was proposed as a working solution and I've observed it being used successfully in demo code provided by Add-In Express.

As recommended by Microsoft, I'm opening my form after setting the thread DPI context to Per Monitor. Using this, the demo code provided above by Add-In Express is being used to apply a LayoutTransform to the UserControl, and scale all elements to the correct size.

private void ApplyScale(int dpi)
{
    var source = (HwndSource) PresentationSource.FromVisual(this);
    if (source is null) return;

    var wpfDpi = 96 * source.CompositionTarget.TransformToDevice.M11;
    var scaleFactor = dpi / wpfDpi;

    var scaleTransform = Math.Abs(scaleFactor - 1.0) < 0.001 ? null : new ScaleTransform(scaleFactor, scaleFactor);
    this.SetValue(LayoutTransformProperty, scaleTransform);
}

This is working as expected, and the window is successfully scaling on each monitor with differing DPI, increasing the size of both window and contents to the correct size.

The issue arises when I attempt to interact with the scaled content. On monitors above 100% scaling, a percentage of the right and bottom edges of the window cannot be interacted with correctly. I have Save and Cancel buttons at the bottom right corner of the form, and when mousing over them the hover event will flicker, but they cannot be clicked normally. This is also true of a ListView featured in the form.

I can confirm the thread is definitely set to Per Monitor awareness, and the visual scaling is working perfectly. No elements are overlapping, and the size of the area that can't be clicked increases with scale.

I'm two days into debugging this and have attempted everything I can think of. What could be causing this?

KovBal
  • 2,129
  • 2
  • 17
  • 31
Lann
  • 29
  • 1
  • We're experiencing the same issue with a WPF button. Did you managed to solve this? – KovBal Nov 11 '22 at 09:57
  • Do you place your WPF controls on the ADX pane? If so, did you try to contact them? – Eugene Astafiev Nov 11 '22 at 13:20
  • The WPF controls are in a WPF view within an `ElementHost` in an `ADXOlForm`. The view's LayoutTransform is update whenever the `ADXOlForm`'s `ADXDPIChanged` event is fired. I'm not sure that this what you mean by contacting them. – KovBal Nov 11 '22 at 14:35
  • 1
    We were offered a solution over on the Add-In Express forums https://www.add-in-express.com/forum/read.php?FID=5&TID=16225 but deemed it a bit too much of a rewrite to explore just yet, so I can't confirm if it will resolve it. – Lann Nov 14 '22 at 23:56

1 Answers1

0

TLDR: Construct a WPF UserControl before a Dispatcher is created for the UI thread.

We were experiencing the same issue when a WPF view was placed inside an ElementHost in an ADXOlForm, and the LayoutTransform was set in the event handler of the form's ADXDPIChanged event.

The solution proposed in the linked forum thread ("use OnSendMessage instead of Dispatcher") gave me the idea that the issue might have something to do with the Dispatcher being initialized in a "wrong" way. Since WPF uses Dispatcher internally, its presence should not be the problem itself.

If no reference to the UI thread's Dispatcher was stored, then the issue was not present (just like the post said), but it provides essential functionality, so like you mentioned, it would mean extensive rewrite in our case as well. But our project doesn't need the Dispatcher during startup, so I checked if we initialized it after a WPF view was displayed fixed the issue, and it did. Fortunately, it even works if the WPF control is not displayed.

Only a small modification in the startup event handler was required to fix the flickering:

private void ThisAddin_Startup(object sender, EventArgs e)
{
    // ... initialization ...

    var dummyWpfControl = new DummyWpfControl();

    this.Dispatcher = Dispatcher.CurrentDispatcher;
}

I'm not sure why this modification fixes the flickering. My guess is that the WPF control initializes the Dispatcher "correctly". Maybe it adds some tasks with the right priority, but I was not able to verify this theory.

KovBal
  • 2,129
  • 2
  • 17
  • 31