Ever wonder how to conditionally implement newer features in your code while keeping the ability to use older versions of Xojo at the same time?…
Comments closedCategory: Cross-Platform
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.
Comments closedAt WWDC 2019, Apple announced macOS Catalina (10.15). They didn’t specifically mention it during the keynote, but the writing has been on the wall for…
Comments closedEvery year we watch Apple’s WWDC keynote address to see what new features are coming in macOS and iOS that we’ll want or need to…
Comments closedGeoff just wrapped up the keynote here in sunny, windy Miami, Florida.
After a brief introduction welcoming attendees from 11 different countries, Geoff began the keynote by sharing some graphs showing how the Xojo community has been changing.
Comments closed
Xojo includes a good amount of UI controls available from the Library for Desktop, Web, iOS and Raspberry Pi targets. These are the pieces that allow you to layout the user interface of your apps: properties, methods and events that, when combined, define the specific behavior of the project at hand.
Sometimes, subclassing the available controls is the answer to add specific behaviors you need. But what happen when none of the controls offer what you need, whether visually or functionally? The answer is the Canvas class (for Desktop projects), WebCanvas class (for Web projects) and iOSCanvas class for iPhone and iPad devices. But how do you create your own UI controls from scratch? Read on to learn…
Comments closedFor 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.
Comments closedDid you know that Apple provides a command-line interface for the Application Loader? With a Post-Build IDE build script, you can automatically submit your iOS apps to the iTunesConnect for processing!
Comments closedThe 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.
Comments closed