Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

GUIs displaying differently on other machines


  • Please log in to reply
33 replies to this topic
Thalon
  • Members
  • 641 posts
  • Last active: Jan 02 2017 12:17 PM
  • Joined: 12 Jul 2005
"Otherwise I would not have found it"
--> So you did find it? ;)

I am not good in translation, but you find it here:
+ Open the properties of you desktop
+ Switch to tab Properties or Adjustment or anything like this ^^
Should be right beside of "Appearance", you can adjust screen-resolution and color-quality there.
+ Open the button "Extended" (or whatever it is in english :?: ).
+ In the newly opened dialog you can adjust the dpi for your system...

I think this is not the only case, but the one with the most visible effect.
As I had this problem the first time the user had set 96 dpi, but I had to increase widness of my textcontrol by 1px (Not a real problem in my eyes).

@Chris
Thx for having a look!

Thalon

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

I just changed color and bold at 1 control

I think Bold is the problem, specifically that the text is changed to Bold after the control is created. This causes the auto-sizing to be too small because the control was created to fit non-bold text.

To solve this, change the font to bold when the control is created rather than later:
Gui, 5: Add, Text, bold xs+125 ys+0 w40 vGameserverOnlineAnzeige, Online

I think the above explains everything (I tested 120 DPI on my system and didn't see any other problems with relative positioning). But if you find any other unexplained behavior, please let me know.

Thalon
  • Members
  • 641 posts
  • Last active: Jan 02 2017 12:17 PM
  • Joined: 12 Jul 2005
No it doesn't explain anything ;)

Because the width is set absolut, it doesn't have any effect if bold is set on creating or not.

And maybe you could have a clearer look at this screenshot:
http://www.bilderton...=1138010900.JPG

Also Network Mode is missing a "e", because of Font-size.

You should also see that the overlapping Groupboxes do not overlap any more exactly. The problem can be better seen on another tab (not included in source above), where a text contains of three text-controls.
When using 120dpi they are overlapping and the text can't be read any more!

I think the only way would be to find out which DPI are used and resize and replace all my controls :(

In this case
Gui, 5: Add, Text, bold xs+125 ys+0 w40 vGameserverOnlineAnzeige, Online
I would have to increase the relative position xs and the width by a factor (96/100 * 120 = ~ 1.25).

This would result in a complete work-over of my whole GUI (I think about 200 lines yet).
It would be great if this could be done by AHK anytime in the future, but I'd like to release tomorrow ^^
Will be lot of work ;)

If you want to include this support into next-version I will note it as known-issue, so would be nice to get a answer soon about your plans :)

Thx,
Thalon

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

Because the width is set absolut, it doesn't have any effect if bold is set on creating or not.

I did test that GUI on my system with both DPI settings. Apparently I missed something.

Before I move on to the next quote, let me say that I believe this issue shouldn't be "fixed" in the program, for two reasons:

1) All units in AHK are currently measured in pixels. It is my understanding that pixel size does not change when font DPI changes. If true, it would be an incorrect policy to increase pixel size when font DPI increases.

2) I believe that changing the program to make DPI affect GUI coordinates would break existing scripts, both those that rely on the old behavior in their support for both 96 and 120 DPI, and those that use relative positioning with non-font controls such as Progress and Picture.

Also Network Mode is missing a "e", because of Font-size.
I think the only way would be to find out which DPI are used and resize and replace all my controls :(

As you know, this is because you used xs+80 to position the control to the right of it, and 80 is too small for 120 DPI. Since AHK doesn't support any type of units other than pixels, you should change the script to calculate the offset rather than using 80. This can be done by retriving the width of a control in the left column and comparing it with the width that was expected under 96dpi. If the calculated width is greater than expected, increase the value of 80 by that same percentage (or by 25%). As you suggested, you could also retrieve the system's DPI setting from somewhere and make your positioning relative to that (probably more reliable).

It would be great if this could be done by AHK anytime in the future, but I'd like to release tomorrow ^^

I believe the correct way to solve this is have the program recognize units other than pixels (like HTML and CSS do). Such a syntax might look something like x+80em. Although I'll add this to the to-do list, other things are a higher priority at the moment.

Thanks for demonstrating the importance of this.

evl
  • Members
  • 1237 posts
  • Last active: Oct 20 2010 11:41 AM
  • Joined: 24 Aug 2005
Wouldn't it be simpler to check for the DPI at the beginning of the script (not sure if this is possible?) and then modify the default font size accordingly?

Thalon
  • Members
  • 641 posts
  • Last active: Jan 02 2017 12:17 PM
  • Joined: 12 Jul 2005
Does anyone know how to retreive the DPI of a system? I didn't find something up to know...

So let's start work :lol:
Thalon

Thalon
  • Members
  • 641 posts
  • Last active: Jan 02 2017 12:17 PM
  • Joined: 12 Jul 2005
@Evl
I will scale my controls depending on exact DPI-setting (User might have to enter it once if I find no way to determine it automatically). This is more flexible than finding a good font-setting for some cases...

So here is my new question:
Is there any way to "calculate" position in one line?

For example:
Gui, Add, Text, x20*DPI_Multiplicator, Some test
Otherwise I would have up to 5 lines to get position and size for one control :(

Thalon

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Here's one way:

hdc := DllCall("GetDC", UInt, 0)
dpi := DllCall("GetDeviceCaps", UInt, hdc, Int, 90) ; 90 is LOGPIXELSY.
DllCall("ReleaseDC", UInt, 0, UInt, hdc)
MsgBox DPI = %dpi%

Thalon
  • Members
  • 641 posts
  • Last active: Jan 02 2017 12:17 PM
  • Joined: 12 Jul 2005
Thanks!
Helps me a lot!

Thalon

Thalon
  • Members
  • 641 posts
  • Last active: Jan 02 2017 12:17 PM
  • Joined: 12 Jul 2005
Is there maybe a shorter way to scale controls with a factor?
;Init
DPI_F := DPI/96

;Place control
X := 10 * DPI_F
Y := 20 * DPI_F
Width := 60 * DPI_F
Height := 25 * DPI_F
Gui, Add, Edit, x%X% y%Y% w%Width% h%Height%, Test
Using ControlMove is not a good solution, because I have to obey more if I ever want to change my GUI (because I can't use the variable-names of controls).

So you know any shorter way to get to the target?

Thalon

Zippo
  • Members
  • 56 posts
  • Last active: Jan 24 2009 05:18 AM
  • Joined: 21 Apr 2006
Sorry to bump an older topic, but I'm having the same problem without having much luck with any of the solutions posted.

If this has been re-hashed and answered, I couldn't find it. If so, could you please point me to the topic?

I'm having problems between a XP-SP2 machine and a WinME machine. A GUI that displays fine on the XP machine at any DPI setting will only display correctly on the ME machine if it is set up with small fonts (96 DPI).

The GUI was created on the XP machine at 120 DPI. Even changing the DPI to 96 has no effect on the GUI (still displays correctly) on the XP machine. The font size is set to Extra Large under the Appearance tab in the Display Properties box. Changing this has no effect either.

Did a little checking, and for some reason the Dll call posted above always returns 96 DPI on the XP machine, even with it set at 120 DPI. It works properly on the ME machine.

I run all accounts but 1 under Limited User on XP, and this was tested under one of the Limited accounts. Haven't tried it under the Admin account yet, but if anyone thinks it would make a difference I'd be happy to try.

I found a registry key on the ME computer that I can get the current display settings, but haven't had much luck yet with XP.

If anyone could give me a tip to working this out, it would be much appreciated.

Thanks

Zippo
  • Members
  • 56 posts
  • Last active: Jan 24 2009 05:18 AM
  • Joined: 21 Apr 2006
Lack of responses makes me wonder if I didn't include enough info or if I wasn't clear enough about the problem. I'll try one more time :?

The problem is that forms, controls and text that show fine inside a GUI on my Windows XP computer do not show correctly on my Windows ME computer, even at the same Font and DPI settings. I have tried running both at the same resolution, but the problem is still there.

There is a Dll call posted by Chris above that is supposed to return the current DPI settings of the system. This:

hdc := DllCall("GetDC", UInt, 0) 
dpi := DllCall("GetDeviceCaps", UInt, hdc, Int, 90) ; 90 is LOGPIXELSY. 
DllCall("ReleaseDC", UInt, 0, UInt, hdc) 

This works fine on the Windows ME machine, as can be seen in the sreenshot below (the dpi.ahk is an AHK script running the Dll call above):

Posted Image

However, when this same script is ran on the XP machine, it ALWAYS returns DPI = 96 (this is after several system reboots):

Posted Image

This has me scratching my head on how I can be certain about the DPI settings the GUI is currently running under. Any user I pass this script to might not be using the default DPI settings (or one of the OS that I have tested it on), and with no reliable way to find this, it is possible that the GUI will not display correctly for them.

Surely there must be some way to work around this?

Thanks Again :)

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Although I haven't tested it, maybe you can derive the DPI by checking width or height of a button/text/etc. immediately after you add it. If it's bigger than expected, that probably means 120 DPI is in effect. For example:

Gui, Font, s12
Gui, Add, Text, vMyText, Some text of known length
GuiControlGet, MyText, Pos
MsgBox Height = %MyTextH%

There is probably some better way of discovering DPI that works on all OS's, but I don't know it yet. I thought the DllCall method would work since it's used internally by the code, and seems to work okay there.

Zippo
  • Members
  • 56 posts
  • Last active: Jan 24 2009 05:18 AM
  • Joined: 21 Apr 2006
Thanks for the reply Chris :)

...it's used internally by the code, and seems to work okay there.


Here are the results at 96, 120, and 192 DPI (sorry for cluttering up the thread with images):

Posted Image

Posted Image

Posted Image

Seems changing the DPI is only changing certain controls sizes, but not the size of the text (as you can see from the size of the caption boxes in the screenshots). And since AHK is reading a false DPI setting through the Dll call, things get messed up. Well, not messed up, just not WYSIWYG.

So I guess I need to figure out a way to read both control and text sizes and alter things in relation as needed. That should keep this newbie busy for the next couple of weeks :D

I was hoping for an easier way, but thanks again for getting me started on a solution :)

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
Some links I found (googling for LOGPIXELSY), that may, or may not be of interest for your problem:
<!-- m -->http://www.codecomme... ... 75564.html<!-- m -->
<!-- m -->http://webster.cs.uc... ... /Ch07.html<!-- m -->
<!-- m -->http://www.lebans.com/image_faq.htm<!-- m -->

Maybe they found that LOGPIXELSY is nearly useless and they changed the functionnality in WinXP...
<!-- m -->http://msdn.microsof... ... s_88s3.asp<!-- m -->
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")