[Win32] Add test case to check auto-scaling mode calculation

[ptziegler]

This adds test cases to check that the auto-scaling mode is correctly read from the widget data and correctly propagated to child widgets.

[github-actions]

Test Results (win32)

   34 files  ±0     34 suites  ±0   4m 46s ⏱️ -42s
4 644 tests +4  4 571 ✅ +4  73 💤 ±0  0 ❌ ±0 
  174 runs  +4    171 ✅ +4   3 💤 ±0  0 ❌ ±0 

Results for commit e9bfbfb. ± Comparison against base commit 8dcdeab.

♻️ This comment has been updated with latest results.

[ptziegler]

I think this is what really confused me when debugging a related problem. I've double-checked this with how things used to behave prior to 2166ca6 and that's it. It probably still makes sense to keep those tests, just to avoid any further confusion.

[Phillipus]

If there is a Control.setAutoscalingMode(mode)then a corresponding Control.getAutoscalingMode() method would be useful. Was this a design decision? As you found, this would be a handy thing.

[HeikoKlare]

If there is a Control.setAutoscalingMode(mode)then a corresponding Control.getAutoscalingMode() method would be useful. Was this a design decision? As you found, this would be a handy thing.

When the autoscale disablement API was introduced, the existing isAutoScalable() method has been overwritten. Due to several side effects we found in the last few weeks, we reverted that change:

• [win32] Remove overwritten Control#isAutoScalable #3021

We though about providing a replacement method, next to the existing one, but that may obviously lead to confusion as there are two independent methods to retrieve some auto-scale-related state. For that reason, we chose to not provide such a method unless there is an actual use case for it. Do you have such?

[Phillipus]

unless there is an actual use case for it. Do you have such?

At the moment just to see what's going on to implement a workaround for eclipse-gef/gef-classic#977

[ptziegler]

To be honest, I don't see any benefit to adding a public getter method. And the only reason I haven't closed this one is because I think unit-tests for the propagation of the auto-scaling mode are useful.

Regarding eclipse-gef/gef-classic#977, I don't think that a getter is of any use. The interesting part is the nativeZoom field of the GC object. But that, one can already get via getGCData().nativeZoom, at least for the sake of debugging.

[HeikoKlare]

To be honest, I don't see any benefit to adding a public getter method. And the only reason I haven't closed this one is because I think unit-tests for the propagation of the auto-scaling mode are useful.

Thank you for the feedback. If you come along a use case that requries a getter, we can still add it. I also consider the tests added here as useful though.

One possibility to avoid that reflective access is to make unit tests out of the added API-level tests: for Windows we have unit tests embedded in the SWT bundle/fragment itself, which can then access state and functionality that is not public API (such as the autoscalingMode field). @ptziegler do think the tests should stay API-level tests as they currently are (then we can merge this one as is) or should we transform them to unit tests without reflective access (I can do that and update the PR if you want).

[ptziegler]

One possibility to avoid that reflective access is to make unit tests out of the added API-level tests: for Windows we have unit tests embedded in the SWT bundle/fragment itself, which can then access state and functionality that is not public API (such as the autoscalingMode field).

Moving them to the bundle sounds like the cleaner approach. I've updated the PR and now they are part of the ControlWin32Tests.

[ptziegler]

If I understand this test case correctly then the Shell is automatically disposed after the test run, due to the ResetMonitorSpecificScalingExtension?

[HeikoKlare]

Indeed. The extension disposes the display and with it the shell.

[HeikoKlare]

Thank you for the update. Great to have those tests, and even in such a clean way now.