Different menu fontsize running program in W10 vs W7

Hi !

I've tested one of my programs in Windows 10 !

Because of an obvious different font and fontsize in the menu, running the program in W10 compared with running in W7, the menu bar size become to wide and wrapped, putting all the controls downwards, with the lowest out of sight !

What's the reason for an other menu font & fontsize in w10 ?

Is it possible to set the menu font & fontsize to a certain name and level so it will be the same regardless of system ?

Thanks in advance

/Kalle in sweden

What you are describing is normal behavior. Even on Win7, if you make your form less wide, eventually the menus will wrap causing the same visual effect you are describing. To answer your question about font/sizes of the menu, the easy answer is that it is what it is. Those settings are system wide. Though they can be changed via code, it is never a good idea since changes effect every application on the system.

Edited: I think I better understand now.

1. You must first know what size you want. Here's what I suggest to get that size
- In design view, size your form exactly as you want it initially displayed
- Set the form's ScaleMode to Twips
- Add this in the Form_Load: Debug.Print Me.ScaleWidth, Me.ScaleHeight
- Run your form & close it. In the immediate window are the 2 values we want
- Place those values into the sample code below

2. Now remove or rem out that Debug.Print line in Form_Load and add this

Code:

---

    Dim cx As Long, cy As Long
    Const ClientWidth As Long = w ' << replace with desired ScaleWidth value
    Const ClientHeight As Long = h ' << replace with desired ScaleHeight value
 
    cx = ClientWidth - Me.ScaleWidth
    If cx > 0 Then Me.Width = Me.Width + cx
    cy = ClientHeight - Me.ScaleHeight
    If cy > 0 Then Me.Height = Me.Height + cy

---

How now? The above code requires your form's ScaleMode to be twips. If you want a different scale mode, set it thru code before exiting Form_Load, i.e., Me.ScaleMode = vbPixels for example.

Side note: This workaround is kinda iffy in my opinion. You are basing your desired width,height of the client area with your current menu font style/sizes which for any metric should be considered random. The solution may not be perfect, but should at least guarantee your client area is as large as it needs to be.

Another option, assuming your menu is a 1-liner and the window isn't extremely wide, is to slowly increase your form's width until the ScaleHeight increases. That would indicate the menu snapped up 1 line. However, you still have to be aware somehow whether the menu wrapped in the first place. Any other option I can think of requires measuring the menu items individually & calculating the wrap point, then calculate how wide the form must be to prevent the wrap. That would turn my simple workaround into a somewhat large routine.

The following will do it, but there are a couple of caveats. Yes, it's going to do it for the entire system, but it does reset when you close the form.

However, if you use the IDE's stop button, it'll never have a chance to reset the system to what it was.

Also, if you click off of this form (i.e., remove the focus from it) to another application, it won't reset. The only (reasonable) way to accomplish this would be to sub-class the form, which would allow you to monitor when it lost the focus. The only other (unreasonable) way would be to place a timer on the firm which monitored its focus through an API call.

But, if you're willing to deal with the IDE issues, it could be done. However, even with this, it may be restricted to later versions of Windows.

Also, there's some code that's somewhat involved but completely rebuilds the form's menu from scratch (without affecting other forms) which can be found in post #5 on this thread.

Regards,
Elroy

EDIT: To test, just throw that code into a new VB6 form that has a menu on it. You'll have to build a bit of a test menu yourself.

Code:

---

Option Explicit
'
'
' Set your desired font name and size here.
Const OurMenuFontName = "Courier New"
Const OurMenuFontSize = 8
'
'
'
'
Private Type LOGFONT
    lfHeight As Long
    lfWidth As Long
    lfEscapement As Long
    lfOrientation As Long
    lfWeight As Long
    lfItalic As Byte
    lfUnderline As Byte
    lfStrikeOut As Byte
    lfCharSet As Byte
    lfOutPrecision As Byte
    lfClipPrecision As Byte
    lfQuality As Byte
    lfPitchAndFamily As Byte
    lfFaceName(1 To 32) As Byte
End Type
'
Private Type NONCLIENTMETRICS
    cbSize As Long
    iBorderWidth As Long
    iScrollWidth As Long
    iScrollHeight As Long
    iCaptionWidth As Long
    iCaptionHeight As Long
    lfCaptionFont As LOGFONT
    iSMCaptionWidth As Long
    iSMCaptionHeight As Long
    lfSMCaptionFont As LOGFONT
    iMenuWidth As Long
    iMenuHeight As Long
    lfMenuFont As LOGFONT
    lfStatusFont As LOGFONT
    lfMessageFont As LOGFONT
End Type
 
Const SPI_GETNONCLIENTMETRICS = 41
Const SPI_SETNONCLIENTMETRICS = 42
Const SPIF_UPDATEINIFILE = 1
Const SPIF_SENDWININICHANGE = 2
'
Const LOGPIXELSY = 90
'
Private Declare Function SystemParametersInfo Lib "user32.dll" Alias "SystemParametersInfoA" (ByVal uAction As Long, ByVal uParam As Long, lpvParam As NONCLIENTMETRICS, ByVal fuWinIni As Long) As Long
Private Declare Function MulDiv Lib "kernel32.dll" (ByVal nNumber As Long, ByVal nNumerator As Long, ByVal nDenominator As Long) As Long
Private Declare Function GetDeviceCaps Lib "gdi32.dll" (ByVal hdc As Long, ByVal nIndex As Long) As Long
'
Dim OrigNCM As NONCLIENTMETRICS
'

Private Sub Form_Load()
    Dim NCM As NONCLIENTMETRICS
    Dim i As Integer
    '
    NCM.cbSize = Len(NCM)
    Call SystemParametersInfo(SPI_GETNONCLIENTMETRICS, 0, NCM, 0) ' Get the system NONCLIENTMETRICS.
    OrigNCM = NCM ' Store the value of system NONCLIENTMETRICS to reset.
    '
    For i = 1 To Len(OurMenuFontName) ' Move an ANSI version of our fontname into the system parameters.
        NCM.lfMenuFont.lfFaceName(i) = Asc(Mid$(OurMenuFontName, i, 1))
    Next i
    NCM.lfMenuFont.lfFaceName(i) = 0 ' Add null at the end of font name.
    NCM.lfMenuFont.lfHeight = -MulDiv(OurMenuFontSize, GetDeviceCaps(Me.hdc, LOGPIXELSY), 72)
    '
    Call SystemParametersInfo(SPI_SETNONCLIENTMETRICS, 0, NCM, SPIF_SENDWININICHANGE)
End Sub
 
Private Sub Form_Unload(Cancel As Integer)
    Call SystemParametersInfo(SPI_SETNONCLIENTMETRICS, 0, OrigNCM, SPIF_SENDWININICHANGE)
End Sub

---

Also, if it were me and I was actually going to use this, I'd develop it into a class module that could be associated with each form that used it.

Also, here's a screenshot of my test:
Attachment 133509

Personally, I'd not recommend changing the system settings. If someone with horrible eyesight had their font size increased quite a bit, you just rendered their system pretty much unreadable.

@LaVolpe, I don't disagree at all. His question just got me thinking about whether it'd be "possible" or not. But not necessarily "recommended".

Quote:

---

Originally Posted by LaVolpe

Personally, I'd not recommend changing the system settings. If someone with horrible eyesight had their font size increased quite a bit, you just rendered their system pretty much unreadable.

---

I agree 100%.

Quote:

---

Originally Posted by Elroy

@LaVolpe, I don't disagree at all. His question just got me thinking about whether it'd be "possible" or not. But not necessarily "recommended".

---

Yeah, kinda like a visitor rearranging your furniture whenever they come over. Though it's possible, not recommended.

Anyway, when it comes to system settings, I think everyone can agree: Don't change them without the user's permission. Doing otherwise can surely increase the chances your app will be uninstalled. And, yes, I'll stop calling you 'Shirley' ;)

Hello again and thanks for the reply !

I thought I already had assured to get my application form in proportion to the screen resolution !

My method is that at different screen resolution (actually WorkAreaWidth) from the original one, automatically starts a subroutine for a formcorrection, which also change the included controls to the relative position and size according to the form's width and height.
Also the font size of the controls, of course, also are adjusted as well as form's own font size where it's occur.
Therefore, I'm able to compare the program running on the W10 with the corresponding run on W7 and see that all the form and control proportions are - roughly - correct.
All but the text on the menu, where the letters appear to look - just similar to - Courier New, I mean that each word takes much more space in the W10 than they do in W7 - and the menu as a whole will therefore take up more space in the x direction. The total amount of text in the menu is thus far beyond the last control in the form running W10.

A different approach:
I have 6 menus in a row.
In the W7 the fifth menu reach to the end of the nearest control beyound.
In the W10 the third menu reach to roughly the same point...
There is crux of the problem...

/Kalle

Karl, it isn't a problem in my mind. I think you have to reconsider how you may be doing things. The form's ScaleHeight & ScaleWidth properties tell you exactly how big the client area is; that is the area your controls are positioned on. You can adjust these by changing the dimensions of the form. If you are using the form's Height & Width properties instead, that would be a problem.

You cannot expect the menu font and size to be the same for every operating system. In fact, I don't think they've been the same from O/S to another since at least Win95 (not positive about that). Added to the complexity is that themes can use different fonts and users, obviously, can change their system settings. Themes and operating systems use different metrics for the thin/thick borders of the window. In other words, you cannot easily use the outside dimensions of the form to calculate the inside dimensions. VB gives you the inside dimensions via the ScaleWidth & ScaleHeight properties. APIs give it to you via the GetClientRect function.

I would assume (and that isn't always a smart thing to do) that the width of your form is as you expect. The height can change because of the font style/size. You can always adjust the height of your form during form_load. I gave a few ideas and here is yet another. Since you know what the bottom most control is and you know how much space you want between it and the bottom edge, you can calculate where you expect the bottom edge to be. Now you can test that calculation against the ScaleHeight property. If they are not the same values, adjust form height as needed. I mentioned above about assuming form width... This same logic can be applied with the right-most control and the ScaleWidth property value.

In any other situation, if a window appears and the window height doesn't look correct, the user simply increases the height of the window or stretches the width of the window to snap the menu back to less rows.

Quote:

---

... which also change the included controls to the relative position and size according to the form's width and height.

---

Form's width & height should not be used in positioning controls on the form. Form's ScaleWidth & ScaleHeight should be used.

I have not read all the posts (thoroughly), but here is something to consider.
MS have allowed in most versions of windows for the user to change the DPI setting away from normal (make the text bigger).
They(MS) should be shot for offering this.
You could explore using your program on both a W10 and a W7 PC which has the setting at normal, where it belongs (The way God intended).

Rob
PS I will get flamed by some who use that setting to make things easier to read.
To those flamers, "I say solve that problem properly" -
- Get a bigger monitor
or
- Use a decent screen magnifier that with one keystroke can double the size of everything, and another key stroke to switch back

Quote:

---

Originally Posted by Bobbles

PS I will get flamed by some who use that setting to make things easier to read.
To those flamers, "I say solve that problem properly" -
- Get a bigger monitor
or
- Use a decent screen magnifier that with one keystroke can double the size of everything, and another key stroke to switch back

---

The problem is that using high DPI settings is the proper solution. The fact that it causes us a lot of grief as programmers is another matter altogether.

A bigger monitor is seldom a solution either and can make the problem worse. The culprit is the sale of monitors with gratuituously high resolution in order to keep prices and profit margins high. Lately the bigger the monitor the worse the pixel density problem becomes for consumers.


Something I haven't seen confirmed yet is whether the topic of discussion is (a.) a high DPI issue or (b.) an issue of somebody trying to fix unreadble text the wrong way by changing the system font face and sizes through "theme" settings. If the OP is seeing different fonts faces and sizes between a Win7 machine and a Win10 machine then more likely it is (b.) since both OSs use Segoe UI 9 as the standard menu font unless the user has fiddled around creating an old style theme profile.


In any case the only real "fix" a programmer can make is to allow user resizing of all of your Forms that have menus and avoid trying to rescale the controls and fonts within them. Move to flow-based layout instead of magnification-based layout techniques.

Quote:

---

Originally Posted by dilettante

The problem is that using high DPI settings is the proper solution.

---

I am old so my memory does not work.
- I think we have disagreed on this in the past (I recall suggesting someone should set it to 9x magnification, and see how well you can program to fix that)
-We disagree on it now
- And if you ask me on my death bed, I will still disagree with you.

Can I simply avoid my primary problem, just skip any menu and replace it with clickable labels on a frame, looking like a menu at the upper part of the form, and then choose any font and any font size I want, that always will remains as once set, no matter the OS....

Valuable information about Scaleheight and ScaleWidth !
I have to take a close and better look at those units !

/Kalle

You could, but what if someone resizes your form smaller, wouldn't they lose the ability to click on those labels? Menus at least wrap to avoid that problem.

Can't stress this enough... If you are re-positioning and/or re-sizing controls based on the dimensions of the form, then you want to use the form's ScaleWidth & ScaleHeight properties in your calculation. Those tell you exactly how much visible space is available, regardless of any wrapped menus, themed borders, etc, etc.

FYI, windows are divided into 2 main parts:

Client Area: This is where the controls exist and its dimensions are ScaleWidth & ScaleHeight

Non-Client Area: This is everything else, menus, caption , borders, min/max buttons, etc. Dimensions are Width & Height

Karl,

I actually vote for your solution in your post #11. My daughter criticizes me a bit, saying my programs look old-fashioned, but my clients are always generous with accolades.

In my primary application, 139 primary forms, I don't use the menu systems at all. Rather, I put buttons across the top to do the functions I need to do. If a form starts getting too involved, I break it into two or more forms, each with their own functions. I do have some VERY involved forms with 100s of controls, but even those don't make use of the menu system. Rather, I'll use a tab control.

I also tend to not use any font smaller than 10pt, and often use 12pt, sometimes bigger. Many of my users are in their 50s or even older, and appreciate the slightly larger font sizes, especially on the small monitors with high resolution.

Also, most of my forms are fixed sizes. However, some are variable size, but I seldom attempt to scale things like buttons and labels when the form is resized. Resizing is typically done just to see more information in listboxes, listview items, text boxes, and the like.

As I write this though, I realize that I have no idea what your application is doing. There are certainly certain application that will need to consider rather involved resizing issues. Also, an application like Word or Excel, which has 100s (or even 1000s) of tasks you may perform while looking at the same set of data (i.e., the document or the spreadsheet) that something akin to menus is absolutely imperative. However, even Microsoft has moved away from true menus via the use of their ribbons.

Best of Luck,
Elroy

Quote:

---

Originally Posted by Karl-Erik

I have 6 menus in a row.
In the W7 the fifth menu reach to the end of the nearest control beyound.
In the W10 the third menu reach to roughly the same point...
There is crux of the problem...

---

If the menu bar is forced to wrap after just three menu items, that's almost certainly a problem with your menu captions. How long is each one?

Straight from the MSDN design guides:

Quote:

---

Choose single word names for menu categories. Using multiple words makes the separation between categories confusing.

---

You should be able to fit six menus on-screen at any DPI with no trouble, provided you follow the design guidelines.

Quote:

---

Originally Posted by Bobbles

I have not read all the posts (thoroughly), but here is something to consider.
MS have allowed in most versions of windows for the user to change the DPI setting away from normal (make the text bigger).
They(MS) should be shot for offering this.
You could explore using your program on both a W10 and a W7 PC which has the setting at normal, where it belongs (The way God intended).

Rob
PS I will get flamed by some who use that setting to make things easier to read.
To those flamers, "I say solve that problem properly" -
- Get a bigger monitor
or
- Use a decent screen magnifier that with one keystroke can double the size of everything, and another key stroke to switch back

---

...I agree with dilettante - this makes no sense.

High-DPI monitors are a wonderful thing. I imagine you have a high-DPI screen on your phone, and like everyone else, I imagine you prefer it (vs a 72-DPI abomination). Microsoft has bungled their high-DPI implementation more than once over the years (ESPECIALLY in the XP era, when they let people customize each individual display element individually...ugh). But their present solution is the same implementation that Apple and Linux use.

DPI scaling is the only viable solution, and as much as I complain about Microsoft's various implementation details, it's pretty darn amazing that our 15+ year-old VB6 can be made to work with high-DPI screens at all.

Why all of this talk about changing the system font when the user seems to simply want to change the font size of his form's menu's?
Just set the MenuStrip.Font property to whatever font & size you want it to be, no need to change system settings as that will seriously mess with other people's programs when you only need to change the appearance of just your app.

Quote:

---

Originally Posted by JuggaloBrotha

Just set the MenuStrip.Font property to whatever font & size you want it to be, no need to change system settings...

---

Wrong forum. This is VB6

Edited: Though that does bring up another possibility for the OP. Maybe consider the toolbar or coolbar in the earlier versions of the Windows Common Controls? Though, I don't know if they use the menu font or have options to select own font/size.

To Tanner_H !

I think you've misunderstand me about the menues !
What I said was that I compare which one of the menu items reach a certain control end underneath, not which one was the last one before the wrap.
The wrapped menu row ends with the fifth of them, putting the sixth one to the next row - and putting all the controls in the form just the same amount of pixels downwards, as it happens in W10, but not in W7, where the menu font is more narrow...

I happened to see a discussion of using pixels instead of twips in the design of forms. In this way, you always make sure that the dimensions is the same regardless of the resolution of the computer screen.
I have always believed that twips is the best to use, but now realize that I may have been wrong all the time.

Anyway you have to make correction with different amount of pixels in width and height to keep the image of the form not to be too small with higher resolution or not too big with a lower resolution.
How do ScaleWidth and ScaleHeight fit in with this statement ?

Well, it's late night in Sweden and I may not be totally clear minded...

Pixels and twips are just unit of measures. The primary difference is that twips per pixel scale automatically with DPI and pixels do not; must be scaled manually.

Quote:

---

How do ScaleWidth and ScaleHeight fit in with this statement ?

---

Comparing apple to oranges. ScaleWidth,ScaleHeight are inside dimensions of the form. Even if you could change their dimensions, it wouldn't effect the size of the form. Form Width,Height (outside dimensions) do effect inside dimensions. Any changes to the non-client area can affect the inside dimensions as shown by a wrapping menu.

You can always resize your form based on some scaling values, like resolution possibly. Resizing the form, resizes the inside dimensions too. If your form MUST have a minimum inside dimension, I showed one way to achieving that in my first reply to you.

Sounds like you are attempting to keep your form's client and non-client area a specific size for any computer it is run on. That would be extremely difficult to do and, in my opinion, a waste of time. Doing so, you are working against themes, user's system visual settings, DPI, and more.

What is your actual goal here? Are you simply trying to reposition controls based on form resizing? If so, that was covered in previous posts. Gotta ask the question, why is it so important to try to keep your form's menu bar a specific width?

Quote:

---

Originally Posted by lavolpe

what is your actual goal here? Are you simply trying to reposition controls based on form resizing? If so, that was covered in previous posts. Gotta ask the question, why is it so important to try to keep your form's menu bar a specific width?

---

Well - my goal is to secure the form not looking absolute impossible !

Once upon my time, I developed a program, not considering anything about size, as long as it looked OK on my own screen. It covered a major part of the screen, all right, but I thought it was a good thing to do, because everything had a clarity especially for those who had difficulty with vision.

But because I had a relatively high resolution of my computer screen, and some of those who used my program was found to have significantly lower, was the form on their computer screen so great that they were forced to pan between the various controls, which by all means could have had a smarter relative.

On the other hand, an application with relatively small form looked ridiculously small on a computer screen with much higher resolution

Since then I have tried to ensure that my application form must adapt itself to the screen resolution that prevail where appropriate, if it goes outside a certain range of my own screen resolution.
Possibly, I try to push this notion of absurdity, but anyway think I want to spend some effort on my applications to be readily available in most aspects.

I hope that this has clarified my designs, though others may consider them a bit finicky!

As I've tried to describe a number of times in this thread, makes the extended width of the menu items that all the menu bar wraps and forms a new row, which in turn pushes down all the form's controls so that the bottom ones are pushed out of sight.
Of course, A user can certainly widen the form so that the menu once again takes its original shape. But again, why should someone have to adjust your form? This only creates irritation, which is not advisable in terms of good will !

Certainly I can expand the form's original height to compensate for any possible line break on the menu bar, but why should this be needed when it is clear that the menu is too long when its constituent characters are wider and take up more space.
And all that in Windows 10, but not in Windows 7. That is the crux

Have I made myself clear enough ?

Quote:

---

Originally Posted by Karl-Erik

Well - my goal is to secure the form not looking absolute impossible !

---

And I guess "not looking absolutely impossible" would mean (to you), that the Menu-Stripe
does *not* end up in a "two rows menu" (doesn't do a "line-break" on the Menu-Bar).

To accomplish that with the Windows-Default-MenuBar:
- you have only the choice to make your Form wider, period.

Only with a different Menu-Bar (your own, ownerdrawn one - or by using an existing
"MenuStripe-Control") your range of possible choices/solutions will expand.

Sounds to me, that the least efforts would be caused on your end, by simply making the Form
slightly wider and be done with it (maybe develop a solution, which measures the horizontal
space, a given default menu-bar will take up ... and then adjust the Form to exactly this size).

Olaf

If you are writing games software you can carry on fighting Windows with your own themes/ UI behaviour all you like; it will be a challenge...

I you are writing business software look at the Windows UI and other professionally designed business software and see how that copes with different screen resolutions/ DPI settings.
You will see that in most cases it does not even try to cope; it just uses the standard Windows UI font (e.g. Segoe UI 9 in Win 7) and sizes controls containing text appropriately. So e.g. the Windows UI, the whole suite of MS Office apps, other apps and even this web page have the same general appearance and scale when used.
So you run all these apps on a 24 inch 1920*1200 and all is fine and readable at the normal 96 DPI. Then you run them using a 15 inch 1920*1200 at 96 DPI and they are ALL displayed too small to read, although exactly scaled of course. So what to do; there are two main options;
1. Go round all the apps and tweak them to display text in larger sizes - e.g. change the default magnification in IE to display this web page larger than the default of 100% or
2. Change the screen's DPI setting so that everything on it is enlarged exactly in scale.
Choice 2 is a no brainer for me, just change the DPI and Windows will do all the lifting for you.

There is little to be gained in designing your app to be readable/usable at 96 DPI if the Windows UI, MS Office and other apps are all coming up in tiny text!

Use the standard Windows font, vbTwips where possible and just let the Windows DPI setting cope with scaling. If you have large Forms consider the smallest desktop resolution you are prepared to support, these days it is not unreasonable to demand that the user has a minimum desktop size of 1024 * 768.

Quote:

---

Originally Posted by Karl

Have I made myself clear enough ?

---

Yes, Karl, I believe you made yourself clear.

Quote:

---

Originally Posted by Karl

... but why should this be needed when it is clear that the menu is too long when its constituent characters are wider and take up more space.
And all that in Windows 10, but not in Windows 7. That is the crux

---

Applications adjust to the operating system and user settings. The user settings do not adjust to the application.

I do not know your code, but if you are positioning/sizing controls based on the form's outside dimensions instead of the inside dimensions, that is the crux. If you want a minimum inside dimensions size, that has been shown how to achieve that.

Maybe this MSDN article can be of use. About 3/4 the way down the page, look for this section: Handling Minimum Effective Resolution

Karl, Magic Ink has given you some great advice in his post. Correctly handling DPI settings is an important part of writing a competent program, and even though it's a hassle, it will become more and more widespread as users upgrade to modern monitors.

A few clarifications, while we're here...

Quote:

---

Originally Posted by Magic Ink

Use the standard Windows font, vbTwips where possible and just let the Windows DPI setting cope with scaling

---

I've seen the advice to use vbTwips repeated in many places, but this is unnecessary. VB will scale your default control sizes and positions regardless of what measurement they use. Pixels, twips, inches, cm - doesn't matter.

If you are moving your controls at run-time using hard-coded values, then you can also use whatever measurement system you want, as long as you account for DPI. This usually involves multiplying all sizes and positions by the ratio between your expected DPI (likely 96) and the current DPI (144, 192, whatever). This is necessary even for twips, because as has been discussed in other threads, twips do not resolve correctly at 200% DPI and above.

So in a nutshell: you don't need to use twips to achieve DPI independence.

Quote:

---

Originally Posted by Karl-Erik

I've tested one of my programs in Windows 10 !

Because of an obvious different font and fontsize in the menu, running the program in W10 compared with running in W7, the menu bar size become to wide and wrapped, putting all the controls downwards, with the lowest out of sight !

What's the reason for an other menu font & fontsize in w10 ?

---

Windows 7 and Windows 10 use the same font sizes for all primary UI elements.

Both OSes allow you to change the DPI from display settings. (The option may be called something like "make text and other items larger or smaller.) You can change this setting manually on any version of Windows, not just Windows 10, if you want to test your application.

The only difference with Windows 10 is that it automatically sets the monitor into high-DPI mode if your monitor meets certain criteria. You can always revert this setting, obviously, if you find "tiny text and icons" preferable. (You probably won't be able to talk your customers into this, however.)

So to clarify, layout problems like this need to be solved for high-DPI modes on ALL versions of Windows. Not just Windows 10.

Quote:

---

Originally Posted by Tanner

I've seen the advice to use vbTwips repeated in many places, but this is unnecessary. VB will scale your default control sizes and positions regardless of what measurement they use. Pixels, twips, inches, cm - doesn't matter.

---

There are exceptions, here is at least one: Line control coordinates are not stored as twips if scalemode of its container is not twips. I started a 'DPI Tutorial' to help identify some issues and allow others to add workarounds. See link in my signature below.

Quote:

---

Originally Posted by Tanner

So in a nutshell: you don't need to use twips to achieve DPI independence.

---

That is true, but using Twips does make things easier specifically regarding positioning/sizing controls, because you don't need extra code for scaling, say pixels, to DPI. Matter of personal preference IMO.

Quote:

---

Originally Posted by LaVolpe

That is true, but using Twips does make things easier specifically regarding positioning/sizing controls, because you don't need extra code for scaling, say pixels, to DPI. Matter of personal preference IMO.

---

Sure, but as we've seen, at 200% DPI, you need manual code for correct position + sizing even if you are using twips. So for modern displays (where 200% DPI is not just possible, but increasingly common), you're going to be writing manual sizing code one way or another.

I just don't want to set people up for failure by telling them that "twips solve all your DPI problems", and then having them test on 200% DPI and realizing that they've still got size+positioning problems.

Quote:

---

Originally Posted by Tanner

Sure, but as we've seen, at 200% DPI, you need manual code for correct position + sizing even if you are using twips.

---

Not sure I'd agree here.

At 200% DPI, VB runs as if it is in 214% DPI. But it scales everything based on that 214%, not 200%, i.e., 1500 twips (100 pixels) from 100% to 200% DPI is not scaled to 200 pixels, but 214 pixels and the twips remain at 1500. So if you want your controls to scale & position in the same scale VB is using, you don't need to do anything special with twips. Just FYI.

Edited: This is an issue for VB usercontrols when then host is run at 200% DPI.

Quote:

---

Originally Posted by LaVolpe

Not sure I'd agree here.

At 200% DPI, VB runs as if it is in 214% DPI. But it scales everything based on that 214%, not 200%, i.e., 1500 twips (100 pixels) from 100% to 200% DPI is not scaled to 200 pixels, but 214 pixels and the twips remain at 1500. So if you want your controls to scale & position in the same scale VB is using, you don't need to do anything special with twips. Just FYI.

---

All true, but now we've assembled quite the list of caveats. ;) That list gets even longer if the user has special size constraints (as the OP seems to), if they interact with WAPI in any way, if they have images with pixel measurements they need to fit somewhere, etc.

As an example, if the OP follows Microsoft's advice about Minimum Resolution Support (a link that's broken in your post above, FYI), and designs a layout that tightly fits against 1024x768 while using twips, VB's incorrect 214% "internal" calculation is going to come back to bite them at run-time. In this case, twips has made their life harder, not easier, so it's perpetually a system of trade-offs.

There are many articles and tips and FAQs on using pixel measurements to work around these problems, resources that aren't specific to VB. I feel that's a helpful thing for beginners to realize, whereas with twips, they're going to be on their own (or reliant on this forum, I suppose).

I imagine we're after the same goal, but I just want coders to be aware that high-DPI support always involves work on their part. There is a LOT to consider, and there isn't a "quick fix", especially if (as in the OP's case) they have very particular requirements for their control layout.

As long as coders go in with both eyes open, and we help prepare them to deal with these subtleties, no problem. But I just don't want to frustrate anyone by suggesting that high-DPI support is as simple as using twips everywhere.

@Tanner. Granted caveats apply and I added one in my original statement regarding DPI: "... but using Twips does make things easier specifically regarding positioning/sizing controls"

Agreed: Making an app DPI aware is not as simple as using a specific ScaleMode, flipping some VB switch, or anything else. VB is mostly DPI aware, but far from perfect.

P.S. Thanx for letting me know about the broken URL. Fixed

Since I have only tested Windows 10 on a single computer, namely my older laptop with a screen resolution of 1024x768, is that one the only reference I have so far.

The update was made recently, I was curiouse to see what my application looked like in the first place Then, when I began to install other applications on it, and introduced web pages, I could not fail to notice that almost everything that appears on the computer screen now has a bizarre extension horizontally . Thus, faces seems broader, all text seems to have a wider fonts and look clumsy, etc.

I can not draw any other conclusion than this lies behind my menu-wreck in the program, because the menu text font of course is dependent on the operating system !

Before the update to Windows 10 on this computer, I used Windows 7, where there were no problems whatsoever with either the menu text of the programs, or extensive web pages ...

It may simply be so bad that this PC from Packard Bell is not suitable for Windows 10 ? It does'nt look better !
The sight of the grotesque web pages almost discouraged me from updating my other computers the same way...

And all this trouble and all this talk for perhaps a whole different error

But I also learned a lot!

What do you think ?

/Kalle

Quote:

---

Originally Posted by Karl-Erik

Since I have only tested Windows 10 on a single computer, namely my older laptop with a screen resolution of 1024x768, is that one the only reference I have so far.

The update was made recently, I was curiouse to see what my application looked like in the first place Then, when I began to install other applications on it, and introduced web pages, I could not fail to notice that almost everything that appears on the computer screen now has a bizarre extension horizontally . Thus, faces seems broader, all text seems to have a wider fonts and look clumsy, etc.

---

This sounds like a video driver problem or incorrect display settings. You may have to experiment with whatever options you have in the Display Settings applet.

Quote:

---

Originally Posted by Magic Ink

2. Change the screen's DPI setting so that everything on it is enlarged exactly in scale.
Choice 2 is a no brainer for me, just change the DPI and Windows will do all the lifting for you.

---

What you have said there, is incorrect.
Everything is not enlarged.
Only the text is enlarged.

>What you have said there, is incorrect...Only the text is enlarged.
I can only counter that with;
What you have said there, is incorrect.
Albeit text is not always enlarged exactly in scale because of Font size 'steppiness'.

Not only text is enlarged ! It also include pictures and ikons /apps !

What happend here is that installation of W10 also installed Microsoft Basic Display Adapter, which is not suitable för my computer. At least not with W10 !

I've tried to find a new drive at ADM, and Packard Bell, but so far not successfully ! Possible my laptop is too old...

Don't know what will happens if I uninstall W10 to get my W7 back, if the original drive also will return..

Hi again, Karl. It sounds like dilettante was exactly right in diagnosing your problem!

There are many online discussions about display adapter issues and Windows 10. You can roll back to Windows 7, of course, but maybe there is a way to solve the problem if you want to keep Windows 10. Here are some ideas:

https://social.technet.microsoft.com...in10itprosetup

https://social.technet.microsoft.com...in10itprosetup

https://social.technet.microsoft.com...eview2014Setup

If you know the actual name or model of your display driver, or if you can discover it using software like CPU-Z, you might have luck tracking down a driver compatible with Windows 10. Good luck.

This is one reason why laptops are more "disposable" than desktops. Few laptops have a separate replaceable video adapter or upgrade slot and few of those that do have newer supported adapters available beyond a year or two down the road.

With a desktop machine you can often slot in a newer adapter having driver support for later versions of Windows, and prolong the life of your investment.

But it is always possible that your laptop's video chipset does have newer drivers even if they must be acquired from a source other than your laptop's manufacturer.

I'll thank you all for now !
Going to celebrate Christmas with my sister and mother and then be back for new struggle with my laptop !

So - until then - I wish you all a Merry Christmas !

/Kalle