Progress bar bug or just me being silly?

[Scoox]

I'm having trouble with the following code, which instructs AutoHotkey to display a Progress window with dimensions 100 x 300 pixels. The problem is that the resulting Progress window dimensions are 200 x 600, i.e. doubled. I have my display scaling set to 200% so I thought that might be the reason, but if I set the scaling value to 100% or 300% the Progress window dimensions are still 200 x 600.

The problem happens when running this script on Windows 10 x64. When I run the above script on Windows 7 Ultimate 64-bit it displays the correct size (100 x 300).

Thanks in advance!

Code: Select all

#Persistent
#NoEnv
#SingleInstance Force

H := 100
W := 300
Progress, b h100 w300 cb00FF00 ct00FF00 cwBlack fm20 fs20, 70 `%, Hello world
Progress, 70
Return

~Esc::ExitApp

Progress wrong size.png (54.89 KiB) Viewed 1455 times

[noname]

Can you try the code ( it has the M option ) this works in win10, it seems it alters the behavior of the window detected under the cursor and not the dimensions of the window itself.

Code: Select all

#Persistent
#NoEnv
#SingleInstance Force


Progress, B M h100 w300 x100  cb00FF00 ct00FF00 cwBlack fm20 fs20, 70 `%, Hello world,myprogress
Progress, 70
settimer,dim,-500
Return

dim:
WinActivate, myprogress
Progress, 70
WinGetActiveStats, t,w,h,x,y
msgbox %w%  %h%  %t%
return


~Esc::ExitApp

[lexikos]

I have my display scaling set to 200% so I thought that might be the reason

That is the reason. Did you sign out or restart after changing the display scaling? Probably not.

Progress and Gui are scaled by the system DPI setting (A_ScreenDPI). There is only one system DPI setting, and it cannot change while you are logged in. If you have multiple monitors, I think the system DPI usually reflects the display scaling of the primary monitor. Progress will scale by this value regardless of which monitor it is on. Gui scales by default, but has a -DPIScale option.

As a workaround, you can /= (A_ScreenDPI/96) the coordinates before passing them to Progress.

[Scoox]

Sorry I took so long to get back, moving home and work have kept me really busy.

Noname, I've just tested your code with the M option, but he size reported on the message box is still 600 x 200.

Lexikos, the machine I'm testing this on is a Surface Pro 4 with no external displays attached. I've done a bit more digging and noticed the following:

1) The dimensions returned by WinGetActiveStats are always double the dimensions passed to Progress, regardless of the display scaling setting, so basically it seems this is not related to display scaling as we thought.

2) Certain commands return actual pixel count, for instance, SysGet and WinGetPos return dimensions as actual pixels regardless of display scaling or resolution.

3) Progress exhibits this problem while SplashImage does not, you can see this by running the following scripts:

Code: Select all

#NoEnv
#SingleInstance Force

Progress, B h100 w300 x100 cb00FF00 ct00FF00 cwBlack fm12 fs12,, Progress: 100 x 300, MyProgress
SetTimer, Dim, -500
Return

Dim:
	WinActivate, MyProgress
	WinGetActiveStats, t, w, h, x, y
	MsgBox %w%  %h%  %t%
Return

~Esc::ExitApp

Code: Select all

#NoEnv
#SingleInstance Force

SplashImage,, B h100 w300 x100  cb00FF00 ct00FF00 cwBlack fm12 fs12,, Splash: 100 x 300, MySplash
SetTimer, Dim, -500
Return

Dim:
	WinActivate, MySplash
	WinGetActiveStats, t, w, h, x, y
	MsgBox %w%  %h%  %t%
Return

~Esc::ExitApp

4) The default setting GUI, +DPIScale doesn't scale bitmaps. I have a couple of GUIs with 16x16 pixel bitmaps that don't get scaled up. However, if I manually enforce the desired dimensions:

Code: Select all

Gui, Add, Picture, h16 w16, MyIcon.ico

the icons do get scaled up BUT for some reason they display "squashed", with the height being less than the width, even though in the above code both h and w were set equal.

These are basically all the issues I've encountered since I switched to W10 on a high-resolution display. I do appreciate your help

[lexikos]

1,2,3) This is all consistent with your system DPI setting being 200%. Did you check A_ScreenDPI?

[Scoox]

1,2,3) This is all consistent with your system DPI setting being 200%. Did you check A_ScreenDPI?

Thanks Lexikos! I tested at different DPI settings though, all producing the same results. I would have expected things to work at 100% DPI setting, but I still get double size. Furthermore, SplashImage works correctly whereas Progress doesn't, this is the bit that makes me think I'm not doing anything wrong.

On my system A_ScreenDPI = 192, which is twice the 96 you mentioned. But why would this affect Progress and not SplashImage?

[lexikos]

The simplest explanation is that you did not sign out or restart the computer after changing the setting, as I suggested before (and did not apparently get an answer).

As I explained, the system DPI setting is not the same as the display scaling settings. I do not know if it is possible to directly change the system DPI setting, but either way it is very unlikely that you did so. You would have changed the display scaling setting.

To properly support the Windows 8+ display scaling method, we would have to automatically resize the GUI when it crosses monitors or the user changes settings. That is too likely to go wrong, and introduces subtle complexities like having to record whether DPIScale was enabled when each control was created (to know which ones to resize).

On the other hand, I suppose that using the current display scaling setting of the primary monitor might be slightly better than using the system DPI setting (i.e. reloading the script would allow it to respect the new setting). There's a chance it would be an unwanted change for some users if we're wrong about how the system DPI setting is determined.

But why would this affect Progress and not SplashImage?

If you want to know why SplashImage is not scaled, you would have to ask fincs.

Add DPI scaling to InputBox and Progress (*not* SplashImage)

This is why I said "Progress and Gui are scaled", not "Progress, SplashImage and Gui are scaled".

[Scoox]

Thanks a bunch Lexikos. Apologies, I read through and then went on to try the test Noname's scripts, and completely forgot about the signing out bit. I'll try and see if it makes a difference.