WinRT is an application framework meant as a replacement for the decades old Win32 API (at least the non-GUI parts of it). Because WinRT is COM-based, and entirely unmanaged code, accessing it directly from Xojo is possible.
Posts related to Windows-specific development.
For more years than I’d like to admit, the Layout Editor has been slow in terms of dragging controls around. As you add more controls, it gets worse. For web layouts, it’s been even worse. That’s primarily because we have to draw everything for a web layout whereas for a desktop layout, the OS draws the controls for us.
In an engineering meeting, I mentioned a discussion I had with a user about the speed of the Layout Editor and Travis said he had recently been reminded of how slow it was too. While most of the time issues in Xojo are carefully calculated and prioritized for maximum bang for the buck (as we say around here), that’s not always how it happens. After the meeting, Travis decided to dive into the Layout Editor code and see what could be done to speed it up.
The results are pretty remarkable.
The Timer and Xojo.Core.Timer classes gives us a resolution that is more than enough for most of the cases where we need to use them. In fact, under macOS we don’t find any kind of limitation when using the classes provided by the Xojo Framework: we can achieve a maximum resolution of 1 ms on any of the most recent computers.
But when working with Windows OS this is not so straightforward . It doesn’t matter if we try to set the Timer Period property to a minimum value of 1 ms; Windows imposes a minimum resolution of 16 ms, insufficient when we demand the maximum precision for a critical task (period interval between Timer firings).
Of course Xojo has a solution for this, you can resort to a third-party plug-in that works extremely well … or you might find the following technique useful for all kinds of projects.
Here’s your first reminder: On January 14, 2020 Microsoft is ending support for Windows 7. We went through this a while ago when Windows XP reached end-of-life (no one really cared when Windows Vista reached end-of-life). Windows 7 was a very popular release as it was much better than Vista. It also didn’t help that Windows 8 was not liked at all with its many UI changes.
About three years ago, we added HiDPI/Retina support to our framework which was released to users as part of Xojo 2016r1 when we also shipped our first HiDPI IDE.
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.
After seeing this conversation on the forums, I thought it would be helpful to run through why you can move some of your app’s DLLs but you cannot move others.
On Windows, the Visual Studio C Runtime DLLs can be in one of two locations on systems that do not already have them installed. All versions of Windows prior to Windows 10 would need these installed.
You can call into Win32 APIs (aka WinAPI) to use methods and properties that are not built into the framework by using the Declare command. To create a Declare statement you first need to track down the API you want to use using Microsoft’s documentation: Microsoft Developer Documentation.
Here are some tips that will help ensure your Windows apps look and feel their best, with Xojo 2018 Release 1 now that Windows apps now have a more stable and flicker-free UI than ever before.
Viruses continue to be a big problem on Windows. As a result, anti-virus software can be a bit over-zealous about detecting what it believes to be apps that have viruses embedded within them. We have had reports over the years that apps made with Xojo are sometimes falsely identified as being infected with a virus. This sometimes occurs because the 32-bit Xojo compiler puts executable code in a location where the anti-virus software doesn’t expect to find it. We’ve seen this occur even when users are debugging apps from the IDE. Fortunately in that case, there’s a fairly easy solution.
Many years ago, the Window Functionality Suite (WFS) library was created by Aaron Ballman. This library was a collection of Win32 Declares (and a few other things) for accessing Windows-specific functionality that was not directly provided by the Xojo framework.
WFS is still available on GitHub, but it has languished over the years. For example, it has lots of legacy code in it for older versions of Windows that is no longer needed since Xojo only supports Windows 7 and later. WFS is also not really compatible with 64-bit projects since the Declares mostly assume 32-bit or bust.
To that end, I’ve started a new open-source project called WinAPILib that is now available on GitHub.