In some cases it may be of interest to also get the Build Phase of the OS; so I built you a class you can use to get both the Major and Minor version of the OS as the Build Phase on macOS, Windows and iOS. In addition, you can use this class with Xojo releases previous to Xojo 2019r3.
Posts related to Windows-specific development.
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.
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.