4 Attachment(s)
[VB6] DPI Assistant Drop-In UserControl
**** Jump to post #5 for a quickie method that is not great but can be better than nothing ****
The attached sample projects include the DPI Assistant tool. This tool is designed to help the coder prepare their projects for system DPI awareness. This tool is not designed for dynamic DPI awareness, i.e., per-monitor awareness... That's another project to create.
The tool is designed to be a drop-in, simply add it to an existing project as an uncompiled usercontrol. Do not compile the tool outside of your projects. It has features to detect IDE design and compiled host. When compiled and when in run-time, not compiled, the tool will turn some features off. The tool is strictly designed for the IDE and image scaling during runtime. It can be removed permanently after satisfied you are DPI-aware enough, as long as you are not using any of its image or control scaling options.
What does it do? It has several properties to alert you when DPI-awareness issues exist in your project. It contains several image-related functions to make it easier to scale images due to DPI changes. It can scale nearly all of your controls and allow you to override the scaling. It does not automatically scale images, but will provide the suggested new dimensions relative to current DPI. Scaling an image can be as simple as a single call to one of the tool's scaling functions.
This tool does NOT make your project DPI aware, it assists only. You still should provide multiple sizes of your icons and/or bitmaps/PNGs, etc. The scaling features use GDI+ to perform high quality scaling, but there is only so much quality that can be expected when scaling something 2 -3 times its size; hence, having multiple sizes in your resource file is a good strategy.
Along with the image scaling functions, there is also a function that will allow you to load PNG and TIFF images. However, transparency is still an issue since VB doesn't like to support that outside of icons and GIFs. But faking transparency by having the tool load the PNG over a solid background color works really nice if the image does not need to be shown over a dynamic background. There are options that will create pre-multiplied RGB bitmaps that can be used in menus on Vista and newer, load alphablended icons drawn over solid backgrounds that can be added to an ImageList for display in a TreeView or ListView control. And a few more image options.
But for any of this to help, you must declare your project DPI aware. This requires a simple manifest added to a resource file. The manifest simply tells Windows not to stretch your application when DPI is not 96, that your application can scale itself without much help from Windows. This is explained in more detail in post #2.
Here are some of the things that the tool will assist you with. Following are explained in more detail in posting #3.
- Image scaling
- Identifying non-TrueType fonts and alerting you so you can fix that
- Identifying known problems with VB controls that can occur when DPI changes
- Auto-scaling controls, as needed, and allowing you to prevent it (per control)
- Counter-scaling your controls when VB's DPI is different than the system
The screenshots below have been resized for upload here. In post #2 (maxed out my number of attachments on this posting) is a zip with full images, unscaled, of how atypical DPI, like at 175% DPI (as were these), can hose up your DPI-aware application if you are not prepared for it. The images below are, from top to bottom, an example of app not DPI aware, app DPI aware but failed to address VB-related problems, and a DPI aware app after addressing those problems
Attachment 147639
Attachment 147641
Attachment 147643
The attachments below each have the DPI Assistant tool. Just copy the .ctl & .ctx file to wherever you may want it. A good place could be your VB folder where templates are stored. That way it will show up in the list of usercontrols when you opt to add a "new" usercontrol to your project, i.e., ...VB98\Template\Userctls
I do expect changes to this code as more & more people play with it and report bugs and request enhancements. Recommend compiling each sample project and seeing how they differ in other DPIs. Always test your apps in 175% DPI. If VB breaks, it'll break there.
2 Attachment(s)
Manifest for DPI-Awareness
By declaring your app as DPI-Aware, Windows will not place it in virtualized DPI. That is the stretch-to-fit method for non-aware apps. The DPI Assistant tool is designed for projects that will be system DPI aware only. VB is system DPI-aware, mostly. Windows will help out in two major areas: It will draw the non-client area (title bar, borders, etc) and most importantly, it will scale fonts for us. So always ensure every font for every control is a True-Type, scalable font. Unfortunately, image scaling is what VB doesn't do (with very few exceptions) and that is where the built-in features of the tool can help you.
On modern operating systems, you can now change DPI without rebooting and without logging off and then logging back on. However, apps that are system DPI aware will be placed in virtualized DPI when the latter applies. This is because as far as your app knows, whether it is launched before or after the change, the DPI you changed to is not the true system DPI. Via your manifest, Windows knows your app is not dynamically DPI aware, so it is virtualized. When changing DPI and you are given an option to log off, log off, then log back in -- takes about 15 seconds. On slightly older systems, if forced to reboot, then so be it. My major beef with frequent DPI changes, for testing, is the rearrangement of desktop icons :(
Major Tip #1: It is troublesome to troubleshoot DPI-aware related issues if you must always compile your app to see the results. By adding an external manifest for your VB6.exe file, you can make the IDE DPI-aware also. Do so by taking the same manifest shown below, changing the app name & version within, and placing in the same folder as VB6.exe, naming the manifest: VB6.exe.manifest. Note that on Win7 and above, that alone may not be enough, you may have to change a registry setting & reboot to force it take effect at first. If so, then you should be able to reset that registry setting (set value to 0) and manifest continues to work. You can always re-name/delete the manifest file to prevent it from being applied. The registry setting:
Code:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
Data: PreferExternalManifest (may need to add this if not present)
Value: 1
Major Tip #2: If using DPI-aware IDE and in another DPI for testing... DO NOT save changes. Make notes in NotePad or elsewhere. Return to standard 96 DPI and then make your changes. Otherwise, you can end up with all your controls mis-positioned/scaled. It can happen :rolleyes:
Declaring your app as DPI-aware is as simple as adding a manifest to a resource file, then compiling the application. A simple manifest that you can use is shown below. Also included are necessary entries to allow window themes. There are a few different stragtegies for ensuring Shell32 is loaded. Use whichever you are more comfortable with. The Sub Main included can be used or whip up your own. It's just one way of ensuring common controls are initialized (actually Shell32.dll) properly. When Sub Main is added to your project, don't forget to go and change the project properties to start with Sub Main instead of your main form.
Code:
' Sample Sub Main
Option Explicit
Private Type InitCommonControlsExStruct
lngSize As Long
lngICC As Long
End Type
Private Declare Function InitCommonControls Lib "comctl32" () As Long
Private Declare Function LoadLibrary Lib "kernel32.dll" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
Private Declare Function FreeLibrary Lib "kernel32.dll" (ByVal hLibModule As Long) As Long
Private Declare Function InitCommonControlsEx Lib "comctl32.dll" (iccex As InitCommonControlsExStruct) As Boolean
Private Sub Main()
Dim iccex As InitCommonControlsExStruct, hMod As Long
Const ICC_ALL_CLASSES As Long = &HFDFF& ' combination of all known values
' constant descriptions: http://msdn.microsoft.com/en-us/library/bb775507%28VS.85%29.aspx
With iccex
.lngSize = LenB(iccex)
.lngICC = ICC_ALL_CLASSES ' you really should customize this value from the available constants
End With
On Error Resume Next ' error? Requires IEv3 or above
hMod = LoadLibrary("shell32.dll")
InitCommonControlsEx iccex
If Err Then
InitCommonControls ' try Win9x version
Err.Clear
End If
On Error GoTo 0
'... show your main form next (i.e., Form1.Show)
Form1.Show
If hMod Then FreeLibrary hMod
'** Tip 1: Avoid using VB Frames when applying XP/Vista themes
' In place of VB Frames, use pictureboxes instead.
'** Tip 2: Avoid using Graphical Style property of buttons, checkboxes and option buttons
' Doing so will prevent them from being themed.
End Sub
And here's a Manifest. Adding this to an existing resource file is easy and explained also.
Code:
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity name="prjDPIclass" version="1.0.0.0" type="win32" processorArchitecture="x86"/>
<dependency>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Windows.Common-Controls" version="6.0.0.0" type="win32" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
</application>
</assembly>
With the above manifest, change the blue, bold text to match your project. Save it to a text file, then add it to your resource file this way:
- Create a resource file if you need to
- Add the resource file, if applicable, to your project
- Double click on the resource file from within the IDE
- Click the "Add Custom Resource" icon & navigate & upload that text file
- Double click on the resource you just uploaded
- Change the 'Type' value from "Custom" to "#24" (no quotes)
- Change the 'Id' value to the number 1 (no quotes)
- Click Ok and save your changes -- done
Here are the full screen PNGs of the screenshots in previous posting. Two files, since all 3 PNGs exceeded file size limitation for uploads
Tool Functions and Properties
The three most important parts of the tool are briefly described first. Let's preface all this with a word about scaling. In most DPIs, VB's scale will be the same as the system, but not all DPIs. Whether VB is different or not, I don't think it really matters a lot. What does matter though, is that all of VB's controls are scaled the same and that isn't always the case. As mentioned in previous posts, the tool will help scale images/controls and the system helps scale fonts. The tool looks specifically for font and picture properties on all controls. It has a weakness though... the tool can only find public properties that expose fonts & pictures. For example, the font of ListView items is not exposed as each item can have its own font. The tool will be blind to those fonts. Though the system will scale the font for you, the tool is blind to them and can't tell you if they are True-Type or not. Same for images. If any control has a picture property that belongs to a class inside that control, the tool will be blind to them & can't warn you about scaling. But if you test your app well in other DPIs, you should spot those and can call the tool's functions to re-scale them. I was not willing to handle all possible non-intrinsic controls on a case-by-case basis. The only such non-intrinsic control specifically handled is the SSTab.
Simple rule of thumb: If the property name is not on a property sheet, the tool will not be aware of it.
PreferSystemDpiScale property. This has two purposes and only applies when the system DPI is not the same that is used by VB. This mismatch of DPI occurs in any DPI where the twips per pixel (TPP) results in a fraction. VB truncates TPP to a whole number which results in different scaling. The standard DPI this occurs in is 175% & 200% DPI. Other custom DPIs are prone also. Anyway, the property when set to True will scale images to the system DPI when you do not request a specific image size; else scale to VB's DPI. This applies to notification events also, as the suggested image & control dimensions are scaled based on that property value. The property will also, and this is very important, rescale every control it can to the system DPI instead of VB's DPI if scales are different. Before any control is scaled, an event is sent asking for confirmation. After scaling is attempted or for controls it cannot scale, it will send another event informing you of success or failure. If failure, you must scale the control manually.
Besides using different scales, this property when true, in atypical DPIs results in 100% of your controls being targeted for scaling and positioning. This is because VB already scaled them using its scale and you want to use the system scale, which is different, which affects 100%. When this property is false, only non-intrinsic controls and a few intrinsic ones (special cases) will be targeted.
Tip: Real TPP is calculated as 1440 / DPI, i.e., 1440 / 96 = 15
Activate method. This function can only be called once and should be called in Form_Load before you modify any control properties. When called, Activate will start the scaling and event notifications. If it is called more than once, other calls are simply ignored. That method has an optional parameter to identify all fonts in use that are not True-Type. Usercontrols hosting this tool should call this in ReadProperties, after all properties are read & before any contained control properties are modified.
Events. There are several events that the tool will forward to you.
- Before any control is scaled, a CanScaleControl event is fired. It offers a suggested scale and option to abort scaling the control. The suggested scale can be changed by you without triggering an abort. If a non-intrinsic control is DPI-aware, be sure to abort re-scaling that control.
- After scaling has been attempted, a confirmation ControlScaled event is fired. It has a parameter indicating success or failure. If failure occurs, you should scale the control yourself
- When images require scaling the ScaleImage event is fired. That event offers suggested image sizes, based on the PreferSystemDpiScale property value. The tool does not scale the image automatically. In this event you should pass the image to one of the tool's scaling functions or scale it yourself
- The tool offers a MiscProps property that can trigger ScaleMiscProperty events. That event and property are a list of "other properties" that you want to be reminded of that will require scaling. This is an informational event only
- If you have ImageList controls, then a ScaleImageListImages event will be fired. This is also an informational-only event. You are responsible for scaling any images, but the tool has functions for that.
- If the PreferSystemDpiScale property value is True and an atypical DPI is in use, i.e., 175%, then the ScaleParent event will be fired after all controls have been scaled. That event is informational and offers suggested size for your Form or usercontrol hosting this tool. It will not scale for you, simply scale yourself using the passed dimensions or your own.
There are various warnings that trigger a msgbox when in design view. These warnings appear each time the tool is displayed. They can actually become annoying which is why I track them in the code with a variable name: m_CanNag. However, they can be individually turned off if you don't want to see them any longer. I'd suggest dealing with the warning vs. ignoring it. One warning cannot be turned off: If two or more tools exist in the same parent, a duplicate tool warning is provided.
The tool cannot detect its parent property names while the parent is in design view. Therefore, a ParentImages property is provided by the tool. Use that property to identify any public image properties exposed by the parent. It is typically already set for you, but you can modify it as needed. This is a preferred workaround vs. hardcoding values that may not apply to all parent objects.
The tool's MiscProps property was already described in the ScaleMiscProperty event above.
Run-time methods/properties are briefly described next.
DPI, DPIScaleSystem and DPIScaleVB are DPI related read-only properties. DPI always returns 96 DPI if your app is not DPI-aware. At 175% DPI, DPIScaleSystem returns 1.75 and DPIScaleVB returns 1.875; hence atypical. Hmmm, probably should've named those properties DPIScaleFactorSystem and DPIScaleFactorVB. Oh, well. These scale factors are relative to current DPI and DPI the project was last saved in.
GetImageDimensions will return an image's actual dimensions, regardless of DPI. VB's ScaleX/Y functions are broken in atypical DPI when converting from HiMetric units.
LoadResPicture is a function that takes a byte array & creates a stdPicture from it. You can pass PNG & TIFF to this function. It also has scaling and conversion options. Any PNG/TIFF transparency is always filled with a solid color (optional function parameter) unless converting to 32bpp pre-multiplied RGB. Couple examples:
- load array from file, then: Set Me.Picture = ucDpiAssist1.LoadResPicture(array(), 0, 0)
- from res file: Set Me.Picture = ucDpiAssist1.LoadResPicture(LoadResData(101, "Custom"), 0, 0)
ResizeControl is a substitute for Move. It should be used when manually scaling non-intrinsic controls, i.e., in your Form_Resize event. You can also pass intrinsic controls if desired.
ScaleStdPicture is the workhorse for scaling and converting existing stdPicture controls. It also has scaling and conversion options.
SystemSmallIconSize & SystemLargeIconSize properties return the system's icon sizes, DPI adjusted.
StdPictureToHandle takes a stdPicture and creates a windows icon/cursor or bitmap handle. You are responsible for destroying the returned image handle
WrapImageHandeInStdPicture function takes a bitmap or icon/cursor windows handle and wraps it in a stdPicture. Ensure you own that handle else get a copy before calling this function.
WindowsVersion property. Returns a value from GetOSVersion API. Only returns the major version number. So, don't use this to pinpoint the actual version, i.e., Vista thru Win8.1 each are value of 6. The intent of this property was to know whether we are in at least Vista, which is where DPI awareness begins with manifests, 32bpp bitmaps on menus, using PNG-encoded icons, and other newer 'stuff'. Win10 will be returned as a value of 10 if manifest says your app is Win10 compatible. The manifest in the previous post, says your app is compatible with all, including Win10.
About GIFs. They are poorly supported in this tool and on purpose. Avoid GIFs unless you are using them for animation. They scale poorly and did not want the tool to become an animation tool. So, this tool will not scale GIFs for you, use Image control with Stretch=True. It wasn't worth the extra code to try to determine stdPIcture GIF transparency because VB doesn't give you that when app is compiled. The tool will load GIFs and optionally convert them to 24bpp & 32bpp bitmaps, but not much else is offered for that specific image format. But if you must, VB's GIF in stdPicture format when compiled is only a bitmap. Internally, VB knows the transparent color. Here's what I've done in the past, if I recall correctly. Using stdPicture.Render, draw the image into a 32bpp DC, after first setting every byte in that DC to 255. When VB renders the GIF, it doesn't touch the alpha channel (normally) for the transparent pixels, but does reset to zero the others. After rendering, you can walk through each pixel and those with alpha of zero is a GIF color table entry. With that information, one can use GDI+ to create a GIF, export it to stream, then load it to a stdPicture from that stream. Not fun & far too much work for what this tool was designed for. And still, quality resizing is not addressed. Try scaling a paletted image, keeping it paletted and expect good results. Without putting in the extra effort to create an adaptive palette, results will likely be poor. Remember, GIF format is a max of 256 colors, 255 if transparency exists.
Warning: Do not extract image related functions without examining the various GDI and GDI+ API declarations I used. I took the liberty and modified quite a few -- many are NOT your standard declarations and using the code with standard declarations should fail or worse: crash. Obfuscation was not a goal, which is why I'm offering this warning and also heavily commented some of those functions
1 Attachment(s)
Re: [VB6] DPI Assistant Drop-In UserControl
The following is from my DPI Tutorial. This option is not the best option but can be better than nothing. It is available only on Win10 v1703 or better. It is an enhanced virtualized DPI option which means VB thinks it's always running in 96 DPI.
With the Win10 Creators Update, the optional gdiScaling option can be used as a better option than nothing. That option when included in a manifest offers better rendering of control borders, fonts and metafiles than if no manifest scaling options were used. However, the gdiScaling option does override any other manifest scaling options that may exist. This new option is only available in Win10 v1703 and higher. This option also looks 'better' during dynamic DPI changes, i.e., moving to other monitors using a different DPI or when user changes their DPI without logging off.
Ensure you use TrueType fonts for best results. Always test your app afterwards.
How this works is briefly described. When the current DPI is not 100% (96 DPI), the system will have the app draw everything at the next highest DPI that is a multiple of 96, i.e., 200%, 300%, etc. Then the result is scaled down to the current DPI. Scaling something twice its size and scaling down produces better results, on average, than scaling up to a non-100% multiple. Non-font and non-metafile graphics will not be crisp, but should be better than standard virtualization. VB will be virtualized when this option is used, it will report itself in 100% DPI. This option applies whether multiple monitor scenarios exist or not.
The manifest entry will look a bit like this:
Code:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<gdiScaling xmlns="http://schemas.microsoft.com/SMI/2017/WindowsSettings">true</gdiScaling>
</windowsSettings>
</application>
Here are 3 screenshots you can view for differences in quality and results. The screenshots include an app where 1) DPI scaling is performed within code, manifested as DPI-aware, 2) No manual scaling, manifested with gdiScaling option, and 3) No scaling options at all. The screenshots were taken from a desktop set at 150% DPI. The screenshots are zipped; otherwise; the rescaling by this site of the uploaded images would not provide for a true comparison between them.
Edited: Including that option in your manifest negates any need for the tool offered in this thread.
Re: [VB6] DPI Assistant Drop-In UserControl
Okay, LaVolpe, a bit of advice and a question, if you wouldn't mind.
Here's my current manifest:
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
... a BUNCH of stuff for SxS stuff ...
</assembly>
How would you go about slipping in the GDI Scaling into this manifest file?
And secondly, is having this GDI Scaling stuff in the manifest going to hurt anything on Win8, Win7 or maybe even WinXP systems?
Thank You,
Elroy
EDIT1: Looking at this Microsoft site, it would seem that the following would be the way to do it:
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
... a BUNCH of stuff for SxS stuff ...
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2017/WindowsSettings">
<gdiScaling>true</gdiScaling>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
but I would appreciate your opinion. :)
Re: [VB6] DPI Assistant Drop-In UserControl
Elroy, I'm not proficient with assembly manifests (SxS stuff), more comfortable with application manifests. However, all you need to do is include the XML section in my previous post. It would be a direct child element of the <assembly> element. But if you already have a <windowsSettings> element in your manifest, then only slip in the <dpiScaling> element.
And your second question: No. That element is only applicable to Win10 v1703. I've even tested it in Win10 not v1703 and it isn't honored. Manifest entries only applicable to the current O/S are recognized; others are ignored. But correct syntax is still required, regardless
Re: [VB6] DPI Assistant Drop-In UserControl
Thank you.
I don't already have an <windowsSettings> element in my manifest, so this would be something new. I'm hoping that this will immediately show up on the Compatibility tab of properties, but I'll do some testing to figure that out. If it doesn't, I'll need to develop some easy test to see if GDI Scaling is getting turned on. I'm not exactly sure what that'd be, but I'll play around with it.
Again, Thanks,
Elroy
Re: [VB6] DPI Assistant Drop-In UserControl
If no joy, you can always PM me the manifest (preferred) or posting it here if it's too big for a PM. But I'd prefer this thread not to become a manifest validation tool ;)
Edited: Regarding your edited comment and the manifest snippet you provided, that works only if "asmv3" was declared/defined in one of the ancestor elements. The snippet I offered is generic and works in all cases.
