-
Notifications
You must be signed in to change notification settings - Fork 775
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scaling problems #35
Comments
You are right but for now, you can handle update logic yourself and that way you can provide your own dialog. See Handling Updates Manually for more information. |
I spent part of last night trying to find a solution to this problem and found a relatively simple fix - all hardcoded font sizes should be changed from pixels to points in the .resx files. The scaling works properly afterwards. I did it in this commit: gmichaud@e90d7a4 There are a few other issues; one is with the icons used. The scale mode could be changed to zoom to ensure scaling but a higher resolution image has to be used otherwise it will look pixelated. The other issue I found is related to the web browser control - it doesn’t scale automatically. |
The solution does not appear to work for me. SetFont gets called after Windows Forms applies its scaling logic, and since fonts in the forms are already defined in pixels instead of points, they get scaled down: https://imgur.com/a/1jwZm |
Adding the following to Manifest file also make forms inside the library DPI-aware. <application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
</application> |
Did you see any impact of adding this manifest? This is initially what I tried doing (to completely turn off scaling) but it had no effect -- seems like it is controlled at process level and Excel is already doing it for us.
… On Nov 11, 2017, at 04:36, Ravi Patel ***@***.***> wrote:
Adding the following to Manifest file also make forms inside the library DPI-aware.
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
</application>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AI_zII03iaFjm-jVbFw8X4ZcYOxLJ8Yrks5s1WqKgaJpZM4PA7x3>.
|
Where did you put the manifest? At .exe level or inside the library itself? I’m using AutoUpdater as part of an Excel add-in, and Excel itself is already configured for high DPI - this is what was causing the scaling issues in the first place for me. |
@gmichaud At .exe level. In the AutoUpdaterTest project. |
@gmichaud Can you try the latest commit. I added new option SetProcessDPIAwareness. Can you try it for both possibilities (true and false)? To make sure how scaling behaves for Excel add-in. For WPF this works automatically and if you are using Winforms, manifest way is the best thing to do. |
Sorry for the delay. I haven't tried to play with SetProcessDPIAwareness yet but I've had reports of issues causing the buttons at the bottom of the Update form to be hidden: https://imgur.com/a/XJpaS - I was able to reproduce this by setting my local resolution to 1024x768, 100% font size. There appears to be some interaction with Visual Studio and what's the local resolution when the form is edited. I was able to see a similar behaviour in one instance just by opening the form in a lower resolution/font size. I found some articles on StackOverflow but I don't fully understand the problem or what's the right solution: AutoScaleMode=Font appears to be what's causing the automatic resize of the form. After setting a MinimumSize I did get the result I want, but i'm not sure it is the right approach. |
On hi dpi displays it exists problems with scaling Autoupdater windows. They are very small because use old Winforms technology. It is better to change winforms to WPF windows.
The text was updated successfully, but these errors were encountered: