Ignoring Encoding

When working with Strings that come from (or are sent) outside your app, you always need to consider the encoding of the text. These days, UTF8 is the most common encoding for text and probably the one you should use most of the time. But if you’re getting text from a database or a web service or just another file that you don’t control, then you’ll want to use the DefineEncoding method to set the correct encoding of the incoming text or use ConvertEncoding to cover the encoding to something you’d rather be using, such as UTF8.

Kem Tekinay is doing a session on called Decoding Text Encodings at XDC 2019 that you won’t want to miss.

Avoiding Exception Handling

Some classes raise exceptions when something unexpected happens. If your code ignores these exceptions then this causes your app to display an error message to the user which forces them to quit the app. That’s not the best experience.

At the very least you should have some code in the App.UnhandledException event for your desktop/web/iOS app so that you will know when these occur. The code do something as simple as log the error to the system log or a file so that you’ll have it to investigate.

Then you can pinpoint the part of the code where it occurred and add the appropriate Try…Catch code to deal with it appropriately and gracefully.

As an example, if you call XMLDocument.LoadXML and supply invalid XML, then an XMLException is raised. By catching this exception you can display a message to the user telling them the XML file they selected is invalid and asking them to choose another.

Skipping Database Error Checking

Whenever you run a database command it is possible that there was a database error that happened. But you won’t know about it unless you check the if Database.Error is True. Always do this and then display or log the Database.ErrorCode and Database.ErrorMessage.

This can really help with catching subtle problems, such as a typo in a SELECT statement.

Ignoring Memory Leaks

A memory leak in your app is when it keeps reserving memory but never gives it back. Oftentimes this is not noticeable as the increased memory usage is minimal and does not typically affect 64-bit apps. In addition the memory is released when your app quits. But if you have a significant memory leak you should look into figuring out how to eliminate it.

You can determine if your app has a memory leak by checking (using the OS Task Manager or Activity Monitor) if its memory usage increases significantly as the app is used even while you are closing windows or documents that are no longer used.

It is possible you have some objects that are never going Nil and thus not releasing their memory. Normally you don’t have to worry about setting objects to Nil manually as Xojo uses automatic reference counting (ARC) to clean up memory. But there is a situation, called a circular reference, that can lead to objects not being set to Nil.

A circular reference means that ObjectA refers to ObjectB and ObjectB refers to ObjectA. Since neither ever has its reference count get to zero, then they cannot be released from memory.

You can either manually set things to Nil to ensure that memory is released or you can make use of the WeakRef class to help manage it.

Fuzzy Graphics in HiDPI

If you used pictures in older projects then they’ll only have a single size. When you enabled HiDPI for your project (Shared Build Settings -> Supports HiDPI) then this picture is treated as a 1x size and is scaled in HiDPI screens. This can result in a fuzzy or blurry picture.

Instead you want to start using Image Sets. When you create an Image Set you have three “slots” for 1x, 2x and 3x image sizes. Supplying at least 1x and 2x images will limit unnecessary scaling and cause your images to appear much sharper and clearer. Image Sets are created by default in current versions of Xojo when you add a picture or image to your project. Right click on existing pictures in the project and choose “Convert to Image” to convert them to an image so you can add additional sizes.

Not Updating to 64-bit

For macOS, you should definitely be updating your projects so they build 64-bit apps. It’s likely that the version of macOS that is released later this year will no longer support 32-bit apps at all and you’ll want to be prepared. For many projects you just have to change the Build Architecture setting for the OS from “x86 32-bit” to “x86 64-bit”. Some projects may require updates to Declares that call OS libraries to ensure they can call the 64-bit version of the library.

It’s less of a rush on Windows as 64-bit versions of Windows still fully support 32-bit apps. However, on a 64-bit version of Windows, which are becoming increasingly common, you will get better overall performance as the OS does not have to load 32-bit compatibility layers which use up memory and CPU.

On Linux, 64-bit distributions are becoming more and more common and many do not include any built-in support for 32-bit apps. So you’ll want to be able to distribute a 64-bit app if at all possible.

Not Checking the Docs

We are working to consolidate all the documentation into one place and that place is: https://documentation.xojo.com

As part of this process, the docs have been cleaned up, updated and we’ve improved the categorization to make it easier to find things. This is an ongoing process, of course. But sometimes it will be faster to look up something in the docs than it is to post a question in the forum and wait for replies.

I hope you find some of these tips helpful. At XDC 2019, I’ll be covering additional tips in my two sessions: Avoid Troubleshooting Troubles: Effective Debugging Techniques and Virtuous Code Optimization.

With Apple’s announcements at WWDC 2018 and the introduction of dark mode it was time to revisit our graphics and the overall appearance of the IDE again. Here are some things which contribute to the changes that have been made and ones that you will see in the coming months.

Dropping macOS 10.9

Xojo 2018r3 drops support for macOS 10.9 and as the last version which had the skeuomorphic design elements all of our supported OS’s now have the flatter modern design. It’s not that this has held anything up per se, but it’s a good reminder that “it’s time”. 

To that end, we have taken that opportunity to remove some of the graphics that make the IDE look out of place and doing so subtly lowers the memory footprint and accelerates drawing of the IDE itself across all platforms. We’re also using a variation of Apple’s image templates which has somewhat reduced the on-disk footprint of the IDE itself.

macOS Dark Mode

Apple’s addition of a darker variant of the visual “Aqua” theme in macOS means that we needed to do an audit and update of several of our base framework controls so that your apps would render correctly as well as ours. 

Events

While it probably won’t be used very often (how often does one change themes while running a piece of software, besides the novelty of seeing it happen), we added an event to the App class named AppearanceChanged to notify you when the user changes from light to dark or changes their accent color. This is a good place to clear any graphic or color caches which contain theme specific UI graphics. 

Methods

There is also a new global method called IsDarkMode(Boolean) which will return True if your app is running with the Dark Mode theme on macOS 10.14 or higher. If your app is running on 10.13 or lower or in light mode on 10.14, IsDarkMode will return False.

Build Settings

Enabling Dark Mode in your apps is as easy as flipping a switch in the Shared Build Settings. Unfortunately, because Apple made the assumption that most apps would “just work” versions of your apps compiled with older versions of Xojo will either need to be recompiled with Xojo 2018r3 or you’ll need to push out a new version with a plist entry to prevent macOS 10.14 from showing your app dark in Dark Mode. 

Testing

When testing apps for use with Mojave’s dark mode, I seriously suggest that you test on a system that allows you to see the translucency effects of dark mode. Virtual Machines are usually really handy for testing, but in this case, Parallels Desktop 14, VirtualBox 5.2 and VMWare Fusion 11 do not show the subtleties of dark mode.

Colors

One of our goals at Xojo is to remove some of the headaches involved with the minutiae of each OS that you deploy for and to that end, we wanted to make drawing custom controls easier too. What this means is that the built-in global colors are largely theme aware now and will change depending on whether your app is running in light or dark mode on macOS. This affects things like TextColor, FillColor, FrameColor, HighlightColor, etc, so if you use those methods when drawing in pictures and canvases, you will want to audit that code. If you want a specific color, you should use a color constant. For instance, use &c000000 if you want black because TextColor will now return white in Dark Mode. 

In terms of the framework controls themselves, we are taking this opportunity to make some changes to make your apps appear better in the macOS 10.10+ ecosystem. Ever notice that a Label control and the text portion of a CheckBox or RadioButton control are not exactly the same color? Going forward, the default colors of controls which should automatically change between Light and Dark modes will do that. So if you have a Label using the default color of &c00000000 (Black with Transparency = 0), the color that is actually used is what Apple calls labelColor. It’s still black, but is a tiny bit translucent. TextFields and TextAreas will automatically change text, placeholder, selection and background colors to match the Apple prescribed colors for automatic Light/Dark compatibly. We think you’ll find that building your apps with 2018r3 will largely make them just behave and appear the way you expected them to.

IMPORTANT NOTE: These color and framework changes affect how your apps draw on all versions of macOS, so make sure you try them out on your 10.10 through 10.14 VMs before shipping!

Eating our own dog food

One thing we hear from users every so often is the desire for Xojo to use our own products for building apps. As most of you know the IDE itself is written in Xojo, but we also have several other apps (big and small) that are written in Xojo.

• Feedback – Our bug reporting system
• Xorders – Our internal order system
• Lingua – The Xojo localization app
• Remote Debugger – The remote debugger stubs for desktop and console

While the 2018r3 cycle was in progress, all four of these projects got updated for Mojave’s Dark Mode and definitely helped us find framework rendering bugs early on in the pre-release process.

What about Windows and Linux?

The TL;DR version is that we’re still looking into it. 

Currently there are several different ways to change Windows 7, 8 and 10 to use a dark interface, not all of which are compatible with the Xojo Framework controls and the Windows 10 2018 Fall Update promised yet another way but that ended up only being for UWP. We are looking into which method gets you the most “bang for the buck” so to speak. 

In 2016 we took many big steps forward with Xojo including HiDPI support for macOS (Retina), Windows and the web, hardware-acellerated graphics for Windows, tons of new iOS features, IDE improvements and compiler optimization for 64-bit builds. Check out the 2016 Release Highlights. The Xojo Forum has grown to over 16,000 members. We published our 100th video in the Xojo YouTube Channel and added new playlists for Raspberry Pi and Web Services and more new videos in our Spanish, Italian and German language playlists.

We hosted another highly successful Xojo Developer Conference in Houston, Texas and we’ll have an announcement soon about the next XDC. 2016 was another great year for Xojo and 2017 is looking even better! One of my favorite things is hearing about all the cool projects our users create and I have no doubt that there will be many more this year.

From everyone here at Xojo, Happy New Year!

General Changes

First, the Web Framework now has support for Retina/HiDPI in supported browsers. All controls have been updated with new graphics to allow your Web Apps to look great on any screen. All you have to do is just flip the “Supports Retina/HiDPI” switch and start using Image objects instead of Pictures and you’re off and running!

NOTE: Regardless of whether you check the “Supports Retina/HiDPI” switch, the web framework now stores all of your image assets in the Resources directory next to your app and they are only loaded momentarily when a browser requests one. This means that your app should use a lot less memory overall.

Controls

WebCanvas: HiDPI/Retina drawing out of the box! No code change required!

WebPicture: Just start using Images instead of Pictures and flip the Retina/HiDPI switch and the web framework will automatically send the correct resolution image to the browser.

WebImageView: Because it’s backed with a WebPicture, it just works!

WebToolbar: Toolbar icons now support Images as well.

Events

WebSession.ScaleFactorChanged: Fires whenever the ScaleFactor of the current session’s browser changes.

Properties

WebSession.ScaleFactor (Read-Only): Reflects the current ScaleFactor of the browser.

WebSDK

The WebSDK has been given a ScaleFactorChanged event so your control is notified when a change occurs instead of your control needing to periodically check the ScaleFactor property on the Session object.

WebControlWrapper.ScaleFactorChanged: Fires whenever the ScaleFactor of the current session’s browser changes.

Also for WebSDK, we are now enforcing unique Javascript Namespaces throughout a project at compile time. This means you’ll be able to tell ahead of time if your controls are missing a namespace or if you’ve inadvertently used the same exact namespace more than once!

*As with other posts, we’ll use “HiDPI” to refer to both HiDPI on Windows and Retina on OS X.

If drawing directly into the Graphics object passed into the control’€™s Paint event isn’€™t feasible or you need to manage your own caching of costly drawing for some reason, the BitmapForCaching function can be used to create a mutable bitmap that’s configured appropriately for using as a cache. This bitmap has some screen-specific properties, like the scale factor, and should be thrown away in the ScaleFactorChanged event. For example:

Class Foo

 Inherits Canvas

 Sub Paint(g As Graphics) Handles Event

  CreateCacheIfNeeded()

  g.DrawPicture(mCachedContent, 0, 0)

 End Sub
 Sub ScaleFactorChanged() Handles Event

  mCachedContent = Nil

 End Sub
 Private Sub CreateCacheIfNeeded()

  If mCachedContent <> Nil Then Exit Sub
  // Pretend this is a costly operation

  mCachedContent = Self.TrueWindow.BitmapForCaching(100, 100)

  Dim g As Graphics = mCachedContent.Graphics

  g.FillRect(0, 0, g.Width, g.Height)

 End Sub
 Private Dim mCachedContent As Picture

End Class
]]>
					
					https://blog.xojo.com/2016/04/07/advanced-retinahidpi-bitmapforcaching-and-scalefactorchanged/feed/
			2
		
		
			
		
		
		https://blog.xojo.com/2016/04/05/xojo-retinahidpi-the-journey-of-a-thousand-pixels/
					https://blog.xojo.com/2016/04/05/xojo-retinahidpi-the-journey-of-a-thousand-pixels/#comments
		
		
		Tue, 05 Apr 2016 00:00:00 +0000
				
		
		
		
		
		
		
		
		http://blogtemp.xojo.com/2016/04/05/xojo-retinahidpi-the-journey-of-a-thousand-pixels/

					
										“Retina” is the name for high resolution screens on Mac and iOS devices while “HiDPI” is the Windows equivalent. For simplicity, I’ll use HiDPI (which really is the universal technical term) for the rest of this blog post. Now that we have HiDPI support in Xojo, if you app doesn’t use any pictures, you can simply open your project, click on Shared under Build Settings and turn on the “Supports Retina/HiDPI” option. That’s all you need to do to have a HiDPI version of your app!

Having said that, if you are creating or using pictures in your project, there may be a few adjustments you’ll need to make to your code. A little over a year ago the process of making sure we had all of the necessary graphics together to build a Retina/HiDPI IDE was added to my to-do list. While 95% of the icons created for the Xojo IDE in 2013 already existed, most of the graphics that made up the IDE itself did not, and the IDE itself needed a bit of an overhaul to get it ready for the big change, both in graphics and in code…
Graphics
Since the Xojo framework didn’t have any HiDPI support yet, everything done last year was done brute force, that is, 2x images were loaded, scaled down by 50% and drawn where they belonged, just to make sure things would mostly line up correctly. While doing this did reveal the amount of work that we were in for, it also hid some issues that we ran into when the HiDPI-enabled frameworks started coming available this spring.
To give you an idea of the size of the task, there are a little over 1000 distinct icons and images used in the IDE today, of which ~370 we did not have a HiDPI version. Now while I like using programs like Photoshop® or Fireworks® for doing work like this, I wanted to transition our graphics to a vector drawing tool so that if/when a higher resolution screen is available, we’ll be able to go back to the originals and start from resolution-independent source-material. That said, we settled on using Bohemian Coding’s Sketch for the majority of the new graphics work. Total time to generate the missing images was about two man-months.
Code
Once the HiDPI-enabled frameworks started coming together, every place where a picture was being drawn needed to be audited (see why in the next section). This work took us from mid-December all the way through mid-March. I won’t tell you that it took two of us three full months of 60 hour weeks to accomplish, but it sure felt like it.
A couple of legacy coding issues came to light which would have to be resolved for everything to work right and I wanted to go over them just in case your projects don’t render correctly right off the bat. Let’s look at what’s changed.
Points vs. Pixels
This is by far the most common issue you’ll probably run into. Before Xojo had HiDPI support, a single element of color on a Picture and a single element of color on a Graphics object were exactly the same thing, pixel for pixel.. If your code looked like this:
Dim p As New Picture(100, 100)
Dim g as Graphics = p.Graphics
Dim widthPic as Integer = p.Width
Dim widthGraphics as Integer = g.Width
both widthPic and widthGraphics would have values of 100.
Now with HiDPI turned on, Picture coordinates and Graphics coordinates can be different from one another if the scale factor of the screen is greater than one. If you were to change the code above to:

Dim p As TrueWindow.BitmapForCaching(100, 100)
Dim g as Graphics = p.Graphics
Dim widthPic as Integer = p.Width
Dim widthGraphics as Integer = g.Width
Note: The BitmapForCaching method creates an image that has the right number of pixels and the right scale factor so you can just draw to it the way you always have and have everything still work exactly the same.

The value of widthPic will differ depending on whether your application is running on a HiDPI screen or not:




widthPic
widthGraphics


Normal
100
100


HiDPI
200
100



…and this is where the trouble begins because the number of physical pixels has actually doubled (in both directions, by the way) while the width and height of the Graphics object still reflect the original dimensions. The difference between these values is the scale factor of the screen you are drawing to.
Now, if you consider that Picture.Width and Graphics.Width have been interchangeable until now, you can see that this can cause a bit of a problem. When drawing to the Graphics object, you need to be working in Graphics pixels, not Picture pixels:
Dim p As TrueWindow.BitmapForCaching(100, 100)
Dim g as Graphics = p.Graphics
Dim widthPic as Integer = p.Width
Dim widthGraphics as Integer = g.Width
g.ForeColor = &cFF0000
g.DrawOval(0, 0, g.Width, g.Height) // Correct
g.DrawOval(0, 0, p.Width, p.Height) // This will draw too large
To wrap up this already long story, make sure all of your drawing routines are using coordinates relative to the Graphics object.
If right about now you’re wondering what we were smoking when this decision was made, rest assured that it was discussed for a long time and the overwhelming driving force was to maintain backward compatibility. With things set up this way you can still draw it onto a Graphics object created with the HiDPI framework and it should just work!
Immutable Pictures
Another hurdle you’ll undoubtedly encounter is the fact that multiresolution images are not inherently editable. This allows the framework to be more intelligent about loading and unloading images at runtime. This affects Image objects created in the IDE as well as ones created in code using the new Picture Constructor API. The most obvious effect is that you can’t draw directly to these images any more and the Graphics and RGBSurface properties will be Nil. If you need the ability to draw onto a picture via its Graphics property, draw the image onto a Picture created in code and work from that – don’t forget to copy the scale properties!
Nested Drawing
If your application creates pictures, and draws other pictures and clips into it using several levels of nesting, make sure you start from the top level when refactoring your code. You’ll find any compounded scaling errors much earlier this way, but you’ll also run a much smaller risk of creating issues that will only manifest when you go back and fix the top level drawing routines.
Drawing Without Context
For most of you, your drawing code will be directly in the Paint event of a Canvas and the Graphics object passed to the event already has all of the information that you need to succeed. In addition, you can always get a mutable picture that is all set up for the current screen by calling the new Window.BitmapForCaching method. This method is available from any RectControl, Window or ContainerControl subclass using TrueWindow.BitmapForCaching.
If (for some reason) you don’t have access to a window from your code, you can create a HiDPI image from a Graphics context by using the new ScaleX and ScaleY properties to set things up. For consistency, we created an extends method in a module like this:
Function BitmapForCaching(Extends g as Graphics, Width as Integer,  Height as Integer) As Picture
  Dim p as New Picture(Width * g.ScaleX, Height * g.ScaleY)
  // Set the appropriate resolution
  p.HorizontalResolution = 72 * g.ScaleX
  p.VerticalResolution = 72 * g.ScaleY

  // Set the scale factor so drawing to it will be correct
  p.Graphics.ScaleX = g.ScaleX
  p.Graphics.ScaleY = g.ScaleY

  // Very important to remember the mask!
  p.Mask.Graphics.ScaleX = g.ScaleX
  p.Mask.Graphics.ScaleY = g.ScaleY

  // Return the new picture
  Return p
End Function
If neither a Window nor a Graphics context is available, you can always create a multi-representation picture and leave it up to the framework to choose the right one when the image is being drawn to a Window, like this:
Dim pa() as Picture
Dim p1 as new Picture(100, 100)
p1.Graphics.DrawOval(0, 0, 100, 100)
pa.append p1

Dim p2 as New Picture(200, 200)
p2.Graphics.DrawOval(0, 0, 200, 200)
pa.append p2

Dim RetinaPicture as New Picture(100, 100, pa)
You’ll have to draw everything twice, so I suggest caching these images so you don’t need to do this more than once, especially if your drawing code is complicated. You can use a similar technique to load images from disk:
Dim pa() as Picture
Dim f as Folderitem = GetFolderItem("Test.png")
Dim pic as Picture = Picture.Open(f)
pa.append pic

f = GetFolderItem("Test@2x.png")
pic = Picture.Open(f)
pa.append pic

Dim RetinaPicture as New Picture(100, 100, pa)
Just remember that the images passed into this form of the Picture.Constructor must all have exactly the same aspect ratio or the framework will throw an InvalidArgumentException!
Conclusion
We’re looking forward to seeing all of your apps become HiDPI-aware and hearing about your experiences. I hope that our experience and suggestions make your transition just a little bit easier!

 
Read more: Advanced Retina/HiDPI: BitmapForCatching and ScaleFactorChanged
]]>
					
					https://blog.xojo.com/2016/04/05/xojo-retinahidpi-the-journey-of-a-thousand-pixels/feed/
			2
		
		
			
		
		
		https://blog.xojo.com/2015/12/08/o-retina-retina-wherefore-art-thou-retina/
		
		
		Tue, 08 Dec 2015 00:00:00 +0000
				
		
		
		
		
		
		
		http://blogtemp.xojo.com/2015/12/08/o-retina-retina-wherefore-art-thou-retina/

					
										During my keynote address last April at XDC, the Xojo Developer Conference, I said that we would be adding Retina support (the OS X feature that provides for ultra-high resolution displays) to the OS X framework in the 4th quarter of this year. We have been working very hard on Retina support both for the OS X framework and for the IDE itself. We didn’t want to stop there though. Windows also supports ultra-high resolution displays. For Windows, this technology is called HiDPI. Xojo is a cross-platform tool so we decided we should support both Retina and HiDPI, and do it in such a way that you don’t have to do much of anything and they just work.

UPDATE: Xojo Retina is here, April 2016

This bigger feature set of course takes a bit longer. We were hoping to ship it in 2015r4 this month but that’s not going to happen. There’s simply not enough time to test Retina/HiDPI support well enough to satisfy us. Instead, this feature along with a Retina/HiDPI-enabled Xojo IDE will come in 2016r1.
There will still be a 2015r4 release. We’ve been squashing bugs as we always do and we’ll get Xojo 2015r4 into your hands this month so you can have an even more robust base upon which to build your apps.
No one likes waiting, but the year is almost over and 2016r1 will be here before you can say Remote Debugger! OK, maybe not quite that fast but soon enough. 
From all of us at Xojo, Inc. we thank you for your continued support and we wish you and yours Happy Holidays.
]]>
					
		
		
			
		
		
		https://blog.xojo.com/2013/11/17/writing-high-dpi-aware-windows-apps/
		
		
		Sun, 17 Nov 2013 00:00:00 +0000
				
		
		
		http://blogtemp.xojo.com/2013/11/17/writing-high-dpi-aware-windows-apps/

					
										Today’s laptops and monitors support high resolution displays which allow you to pack more information and content on the screen. Although one common complaint is that people find the text to be too small at the maximum resolution, Windows’ solution to this is the ability for the user to adjust the DPI setting.



At 150% resolution things get scaled 1.5 times which should make text more readable. However, if your app is not DPI-aware then Windows will scale your content for you, which results in a very blurry looking window.
This DPI virtualization was introduced in Windows Vista, although they still support Windows XP style DPI scaling. The difference is that XP style DPI scaling doesn’t scale your content automatically, but does report the correct DPI resolution to your app (which we use to render text appropriately at the right size). With DPI virtualization your app does not receive the correct DPI resolution information (Windows lies about it) so we render text at the lower resolution and Windows takes over from there and scales your content automatically. The result is a blurry looking window.
Enabling DPI-aware mode
As more computer makers start shipping laptops with high-DPI settings preconfigured, being DPI-aware is increasingly important. We’re constantly trying to improve our framework to support things natively, and I’m confident at some point that you will not even have to think twice about whether or not your Xojo app is DPI-aware, but the one big challenge with high-DPI apps is resizing the controls correctly. However, this does not mean your Xojo app today can’t be DPI-aware with a little work on your part. There are two ways to tell Windows that your app is DPI-aware.

Declare and call the Win32 SetProcessDPIAware API
Modify the embedded manifest in your Xojo .exe app

SetProcessDPIAware
Let’s take a look at the simplist approach to enable your app to be DPI-aware. You can read up on this API here. You’ll notice that Microsoft doesn’t recommend this approach in the case where a DLL would cache the DPI setting before SetProcessDPIAware is called. None of our DLLs currently cache the DPI so you’re fine as long as you don’t rely on other DLLs that might. You can setup this code in the App.Open event like so:
Declare Function SetProcessDPIAware Lib "user32" () As Boolean
If Not SetProcessDPIAware Then
  MsgBox "Error enabling DPI aware mode."
End If

Modifying the application manifest
Modifying the application manifest is the suggested approach by Microsoft, but it requires the use of a resource editor like PE Explorer. A manifest is embedded in each Xojo app which describes some of the elements and attributes of your application. One such attribute is whether or not your app is dpi-aware. You can copy and paste this into the manifest resource in your Xojo app:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
 <windowsSettings>
 <dpiAware xmlns="http://schemas.microsoft.com/                       SMI/2005/WindowsSettings">true</dpiAware>
 </windowsSettings>
</application>

Results
So what exactly does this get you? In normal DPI mode nothing really, now switch to high-DPI mode (say 150%). Now that you’ve told Windows that your app is DPI-aware it no longer virtualizes your interface (by scaling automatically). Your new interface should look something like this:

Notice that your text inherits the default system size, unless of course you’ve specified otherwise. The controls however, are not automatically scaled. Until we come out with an autolayout manager you’ll have to adjust the controls yourself. First, you must find the scale factor. A normal DPI resolution on Windows is 96, while at 150% it would be 144. Here’s some code to find this scale factor:
Declare Function GetDC Lib "user32" (hWnd As Ptr) As Ptr 
Declare Function GetDeviceCaps Lib "gdi32" _
                  (hdc As Ptr, nIndex As Integer) As Integer 
Declare Sub ReleaseDC Lib "user32" (hWnd As Ptr, hdc As Ptr)

Const LOGPIXELSX = 88 
Const LOGPIXELSY = 90

Dim hdc As Ptr = GetDC(Nil) 
Dim dpiX As Integer = GetDeviceCaps(hdc, LOGPIXELSX) 
Dim dpiY As Integer = GetDeviceCaps(hdc, LOGPIXELSY) ReleaseDC(Nil, hdc)

Dim scaleFactorX As Double = dpiX / 96 
Dim scaleFactorY As Double = dpiY / 96
Note how we’re finding both the X and Y DPI resolution. They are usually, but not always, the same. Knowing the scale factor you can now adjust your UI appropriately.
If your controls rely on a fixed sized text, no matter what the resolution, you can always specify the TextUnit to be Pixel instead of Point and enter the size in pixels. This would allow you to ignore any scaling, but note how “off” your UI may feel.

Note that for pictures that you display on screen you may also want to create multiple resolutions instead of scaling them.
Conclusion
Being a DPI-aware app on Windows is becoming increasingly important as resolutions grow larger but how you choose, or not choose, to support it is of course up to you. You may decide that it’s too much effort at this time to update your app, and continue to rely on Windows’ inherent DPI virtualization to scale your app for you, or wait until we support it natively. You can choose to be somewhat DPI-aware and set the mode up (with the declare or manifest change mentioned) but leave all UI unscaled (in which case you would change all the TextUnits to Pixel), or you can be fully dpi-aware and scale/reposition all your controls as necessary.
]]>