Firstly, the MVPs work as your advocates, drawing attention to issues that they feel are important to the community. Their passion comes through in all interactions with the Xojo team, from justifiably reminding us of bugs we need to address or features that would be appreciated by many.

Since the MVPs all use Xojo in different ways, this helps to make sure we get a wide variety of feedback. Sometimes we get direct, specific suggestions such as the Set class, which (due to the provided code), we were able to add as a feature to Xojo relatively quickly. Some especially valuable MVP insights regarding stack checking helped us to pinpoint areas where we could make changes to the Xojo framework that resulted in dramatic performance improvements to Xojo itself along with all your projects. MVP tips and testing have also helped us nail down some issues that helped improve debugger stabilization. MVPs have even created a supplemental unit testing suite to help test the Android framework!

Speaking of testing, the MVPs certainly do more than their fair share of testing. They have helped with an enormous amount of testing for many parts of Xojo, most recently including PDF, Barcode, Charts and Android. When they find bugs, MVPs always create thorough, well-explained Issues, usually with sample projects, allowing us to fix things faster for everyone’s benefit. At times MVPs even review your own submitted Issues and may offer suggestions or advice for you to try.

In addition to testing and providing feedback on the product as you see it today, MVPs get to see stuff early, sometimes even before designs or implementations are finalized. This may be in the form of demos or test builds. Their tips, comments and suggestions can help provide direction to how we end up actually implementing a feature or change.

The Xojo documentation is also continuously improved by MVP feedback and suggestions. MVPs were first to see the new documentation site before it was unveiled to everyone and their keen eyes have helped us improve search, sample code and continue to polish things.

From inception to documentation, this group of dedicated Xojo experts has helped us shape Xojo. If you are pleased with what Xojo is today, you should thank a Xojo MVP.

To Anthony, Christian, Gavin, Jeremie, Kem, Martin and Wayne we at Xojo offer a heartfelt “Thank You!” and have made donations on your behalf to several open-source projects that also help make Xojo possible: LLVM Foundation, Bootstrap and Ubuntu.

Xojo’s team was all vaxxed-up and so happy to get together in Nashville for #XDC2022. Tennessee’s Music City was a delightful backdrop for the first in-person Xojo event since 2019. Check out the short highlights video from Nashville and then join us for #XDC2023 in London, UK. You can register here.

This year the Xojo team and community welcomed a new Xojo engineer, Ricardo Cruz. Ricardo has applied his expertise to advance and improve Xojo Web. To quote one of Xojo’s engineers, “Ricardo coming in has been awesome,” a sentiment echoed on the Forum and the community in Nashville.

Xojo Web has come so far this year. Control reliability has improved, IDE previews have improved and reconnections have really improved. The web framework can now more often reconnect back to the same web session if it still exists. This is one of the things Ricardo is really happy about, “You can switch to your email app in your mobile, copy something to the clipboard, come back to the web app and it is still there, ready to continue.” Under the hood, some dependencies received updates, like jQuery. As a user, you don’t have to do anything, just use the new Xojo version! Try to tell that to another web developer, that’s sci-fi outside of Xojo. Also, thanks to the community, the memory and CPU usage continues to be improved release after release. “Honestly from my perspective it is just fun to play with little projects in it because it has really matured,” says Xojo’s Director of Engineering, Travis Hill.

Speaking of technical achievements, this year we added two new targets to Xojo: Windows on ARM 64 and Linux on ARM 64. On Windows, you can natively deploy to ARM-based tablets and laptops that run Windows. On Linux, you can deploy to 64-bit Raspberry Pi which can address significantly more RAM than 32-bit versions.

We built the Xojo Cloud Control Panel with an updated version of Xojo, and thanks to some Web framework improvements the controls now stay more responsive under load. Plus we’ve added Xojo Cloud servers in Sydney, Australia for web developers in Australia and New Zealand. We also continued improving and testing our upcoming support for Android, which is now feature complete and awaiting some remaining bug fixes before we make it available to everyone.

In addition, we want to brag about a few technical improvements, including the numerous PDF updates implemented by Xojo Engineer and now PDF expert, Javier Menéndez. Also there is the option to generate Program Database (PDB) files on Windows and improved multi-monitor support shepherded by Xojo Engineer William Yu. The list goes on: Code Assistants, on-device debugging in iOS, new Xojo Documentation site, adding Controls at runtime, loading speed faster for big projects, and the time team-Lefebvre built a web app to Calculate Combat Rolls in Twilight Imperium…

Inside Xojo we improved a lot too. Besides welcoming Ricardo and his beard to the team, we migrated Xojo’s bug and feature reporting platform from the internally managed Feedback tool to the much loved Issues. This has increased productivity, streamlined work flow, made it easier to search and find, comment, edit. The team couldn’t be happier!

This year also included Xojo’s first Bug Bash in a long time! During the Bug Bash, Xojo’s Code Editor got some much needed improvements resulting in noticeably faster updates. Plus updates to the Syntax Help Area thanks to Xojo Engineer and retro-computing expert, Paul Lefebvre. Besides the very real smashing of 100 bugs, the bash had the unintended consequence of giving the engineers an opportunity to work on things they don’t normally work on, giving engineers opportunities to collaborate and better solve things.

All in all, 2022 was a year of forward movement for Xojo. Which has us leaning into 2023 with a lot of excitement and expectation. Our team is committed to continuing to make Xojo the best cross-platform development tool and we thank you for being part of Xojo’s continued success!

You absolutely can. Xojo creates native apps that are also cross-platform. It can be done. It’s just a matter of choosing the right framework. At Xojo, we didn’t take the easy path of drawing controls ourselves or using HTML5. We didn’t dumb things down to the least common denominator. We did the hard work of creating a framework with an API that manages the nuances, intricacies, and subtle yet important differences between 7 different platforms (macOS, Windows, Linux, web, Raspberry Pi, iOS and soon, Android) and multiple OS versions so you can focus on what makes your application unique. We have been doing it for over 20 years.

When discussing Facebook’s blog post, John Gruber of Daringfireball.net said, “…native apps are smaller, faster, and more reliable.”

Nearly every user interface element in Xojo is native. The one exception is the desktop Listbox because way back when, none of the desktop operating systems provided one. Everyone made their own. Having said that, the Listbox is made up of native controls. The scrollbar is a native scrollbar. If the developer makes the contents editable by their end user, a native TextField control appears. The headers are native controls. The advantages of native controls can’t be overstated, Facebook was right about that. Modern operating systems provide an ever-increasing array of features via their native controls and thus using them gives you immediate and nearly free access to these features. From focus rings to spellchecking to accessibility and more much, using native controls makes the most sense.

Event aesthetics come into play. Because the Xojo framework uses native controls, when Apple and Microsoft make changes to the look and feel of their controls, apps made in Xojo automatically change in appearance and behavior. Most recently, Apple added Dark Mode to both macOS and iOS and for most Xojo developers, adding this support required nothing more than indicating they wanted their apps to support it by clicking a checkbox.

While Xojo provides the developer with an easy drag-and-drop way to create their application’s user interface, it also provides a straightforward API for interacting with controls via code. The TextField control, for example, provides events that tell you when the control has appeared for the first time, when the user has changed the selection or the text itself, and even when they press down on a key or release it. There are properties to change the size, style and behavior of controls. And all of this is a level of abstraction that lets you focus not on the details of the platform but on what makes your application unique.

For example, under the hood for the desktop, Xojo’s TextField uses NSTextField on macOS, EditControl on Windows and GTKEntry on Linux. On iOS it’s the UITextField, on Android it’s EditText and on the web it’s <input type=”text”>. Each of these is very different but Xojo has done the hard work to provide a standard, straight-forward API so that you get the benefit of native controls without needing to learn the thousands of APIs and unique behaviors necessary to create a cross-platform app.

It’s not just controls. The Xojo cross-platform framework includes dialog boxes, menus, access to the file system, printing, sockets, database access and much more.

Native is more than the user interface. It’s also about performance. Xojo compiles to native code for each platform as well. Behind the scenes it uses LLVM, the same optimizing compiler that Apple, Google, Intel, AMD, Nvidia and many others use. Native code means native speed.

Thousands upon thousands of Xojo users have built cross-platform apps. The Xojo IDE itself and much of the Xojo framework are written in Xojo. So yes, we eat our own dog food. Studiometry and Property Me are just two of the many examples of commercial cross-platform apps written in Xojo. There are countless others.

We have also done this in a way that makes it easy for students and hobbyists to learn programming so they can take it into their workplaces and build business applications. In some cases, those citizen developers create something revolutionary and become full-time professional developers. That’s why the Xojo user community is so diverse.

So yes, you can create native applications that are also cross-platform. You just have to choose the right tool.

For example, it would not be desirable to send hundreds of emails to all the entries in a database simply to test one of the workflow steps or to verify that emails are being delivered as expected. It would be a lot simpler, and less disruptive to those using your app, to test using a few email addresses that are under your control.

So let’s establish a mechanism that allows us tell our apps when to run in a “simulated” mode vs. a “real” mode for all or some of the components that we need to test along the development cycle.

In fact, the way we can implement this is very simple and is based in the definition of a Boolean property in every class (let’s call it Simulation) that we can make visible under the Inspector Panel using the Inspector Behavior feature. Doing this, we can also change it when we drag and drop the class on the Window Layout tray in order to create an implicit instance.

In association with the property itself, we will implement every public method that will be called from the consumer (other component or code of the app) as usual, with the only difference that we will add two additional private methods for every public method we want to run in both modes: simulated and real. For example, let’s say we have a class that returns a Dictionary array with data from a database. We create a public method for the class, called GetData, but when we just need to test other components it provides some fake data instead of connecting and retrieving a bunch of real data from the remote database. In this case we could define the following methods for the class:

• GetData() As Dictionary(). Public Method, part of the visible interface for the rest of the app.
• GetRealData As Dictionary(). Private Method, called if the Simulation property is set to False.
• GetSimulationData As Dictionary(). Private Method, called when the Simulation property is set to True.

Then, the real code for our public method will be simply this:

Return if(Simulation = True and DebugBuild = True, GetSimulationData, GetRealData)

Simple, isn’t it? With this you will have the maximum flexibility to choose the functionality you want to test using real or simulated data: all, none, part of them … even when you deploy the compiled project it will work always with real data.

Javier Rodri­guez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has be using Xojo since 1998. He manages AprendeXojo.com and is the developer behind the GuancheMOS plug-in for Xojo Developers, Markdown Parser for Xojo, HTMLColorizer for Xojo and the Snippery app, among others

*Read this post in Spanish

I’m going to show you how to connect to IBM’s Watson services with REST APIs and how to use them with Xojo projects to identify images. This is just one example, of course, of the many ways to utilize Watson and AI in your Xojo apps.

IBM Watson

IBM’s Watson services have been online for several years and are continuously updated. They are paid services but you can create a Lite user to test and evaluate them. The documentation and variety of services are huge and includes (among other things) image identification services.

Identify images with Watson

This service mainly offers two possibilities: identifying the faces in an image (returning the position, the probable gender of the subject and the probable age range) and the classification (i.e. the recognition of possible tags that can be associated with the image).

Watson’s Natural Language Classifier, is a service that “applies cognitive computing techniques to return best matching predefined classes for short text inputs, such as a sentence or phrase”. It is really large (and the definitions are localized in many languages); moreover you can create your own classifiers specific to projects. The Lite user can create only one classifier at a time that is replaceable but not updatable. Another limit is the number and total size of the images that you can use to address your classifier.

Watson’s documentation is complete and easy to use. After creating the service in your account, you can start using them with the terminal or through the web page relative to the selected service.

How to use Watson with Xojo

The services use a REST API so you’ll use Xojo.Net.HTTPSocket as the base class to create the object that will consume these services. To learn more about using Xojo with a REST API, you should read up on that before continuing: Cats Up: Using the HTTPSocket with the Cat REST API, PDF File Generation? There is an API for that and Web Services Video Playlist.

In this example, the base class is called “WatsonAPI”. This class will deal with the communication with the API (sending and initial interpretation of the answer) and will have some common features (such as zipping several images so they can be sent all at once). Moreover, since the interaction with the service is asynchronous, the class will have to manage the serialization of the different requests and take care to return the result to the correct call.

Next, you’ll define a delegate who will have as an argument the answer (positive, negative or error) that will have as its signature a Xojo.Core.Dictionary:

WatsonReplyFunction(reply as Xojo.Core.Dictionary)

Now you’ll define two private properties: id and callback. You’ll use id to distinguish the various call, and callback will be the function to call when there’s a the result.

Private Property id as Text
Private Property callback as WatsonReplyFunction

The constructor (protected because the subclasses will call it) can be of this kind:

Protected Sub Constructor( cb as WatsonAPI.WatsonReplyFunction)
  // Register the callback
  callback=cb
  Super.Constructor
  register Me
End Sub

Register is a private shared function that assigns the identifier to the object and saves the pair id, object in a shared dictionary. There’s also a deRegister function that will delete the object whose identifier is passed.

As noted before, you’ll use a dictionary to represent the API result because it’s the format used for positive or negative API replies. Moreover, we can use the same format for network error replies. The dictionary will contain at least 3 values: success as boolean for a positive or negative reply, status as integer for the reply http status and result as text or dictionary to represent the current reply. Since it’s a dictionary, we can easly add more information as needed. Subclasses or consumer classes can transform this data structure in a more specific way (class, record or whatever).

Now you will implement the major events:

Sub Error(err as RuntimeException) Handles Error
  //All replies will have the same structure
  //In the event of an error, the returned dictionary must be structured as correct one
  Dim d As New Xojo.Core.Dictionary
  d.Value("success")=False
  d.Value("status")=0
  d.Value("result")=err.Reason
  //Delete the object from the dictionary
  deRegister(Me)
  //return the reply
  callback.Invoke(d)
End Sub


Sub PageReceived(URL as Text, HTTPStatus as Integer, Content as Xojo.Core.MemoryBlock>) Handles PageReceived
  #Pragma Unused url

  //evaluate the reply
  Dim d As Xojo.Core.Dictionary
  Dim t As Text
  Try
    t=Xojo.Core.TextEncoding.UTF8.ConvertDataToText(Content)
  Catch
    t=""
  End Try
  If Not t.Empty Then
    Try
      d=Xojo.Data.ParseJSON(t)
    Catch
      d=Nil
    End Try
  End If
  Dim reply As New Xojo.Core.Dictionary
  reply.Value("success")=HTTPStatus=200 And d<>Nil
  reply.Value("status")=HTTPStatus
  If d=Nil Then
    reply.Value("result")=t
  Else
    reply.Value("result")=d
  End If
  //Delete the object from the dictionary
  deRegister(Me)
  //return the reply
  callback.Invoke(reply)
End Sub

Now you can create a subclass to classify the images: WatsonVisualRecognition as subclass of WastonAPI.

For the image classification you can use one or more of the classifiers and/or the default one or even those in beta (currently Food and Explicit). So let’s define the constants related to these classifiers:

Public Const IBMDefault as Text =default
Public Const IBMExplicit as Text = explicit
Public Const IBMFood As Text = food

… and the ones related to the services:

//The current version of the service
Private Const version As Text = 2016-05-20

//The address actually depends on the user settings
Private Const kBaseUrl As Text = https://gateway.watsonplatform.net/visual-recognition/api/v3/

//The key to use the service
Private Const keyVision As Text = •••••••

You can now define a public shared method for analyzing an image on the web:

Public Shared Sub classifyImage(cb As WastonAPI.WatsonReplyFunction, imageUrl As Text, threshold As Single=0.5, paramArray classifiers As Text)
  //The method requires a method to be called to return the results,
  // the address of the image to be analyzed
  // the minimum value to be considered for recognition
  // a list of classifiers to use

  //Let's create the instance linking it to the callback
  Dim w As New WatsonVisualRecognition(cb)

  //threshold is the minimum acceptable value for classification
  //  must be between 0 and 1
  If threshold<0.0 Then threshold=0.0
  If threshold>1.0 Then threshold=1.0

  //For classifiers I can use both the ones provided and mine
  //none means the default one
  Dim useIBM As Boolean
  Dim usePersonal As Boolean
  Dim usedClassifiers() As Text
  For i As Integer=0 To classifiers.Ubound
    Select Case classifiers(i)
    Case IBMDefault
      useIBM=True
    Case IBMExplicit, IBMFood
      useIBM=True
      //These classifiers are in English only 
      w.RequestHeader("Accept-Language")="en"
    Else
      usePersonal=True
    End Select
    If usedClassifiers.IndexOf(classifiers(i))=-11 Then usedClassifiers.Append  classifiers(i)
  Next
  Dim classifierIds As Text=Text.Join(usedClassifiers, ",")

  //Set the kind of the classifiers used
  Dim usedOwners() As Text
  If useIBM Then usedOwners.Append "IBM"
  If usePersonal Then usedOwners.Append "me"
  Dim owners As Text=Text.Join(usedOwners, ",")

  //Create the URL to be called
  Dim url As Text=kBaseUrl+"classify"

  //I create the list of arguments
  Dim args() As Text
  args.Append "api_key="+keyVision
  args.Append "version="+version
  args.Append "url="+imageUrl
  If Not owners.Empty Then args.Append "owners="+owners
  If Not classifierIds.Empty Then args.Append "classifier_ids="+classifierIds
  If threshold>0 Then args.Append "threshold="+threshold.ToText
  Dim parameters As Text=Text.>Join(args, "&")

  w.Send "GET", url+If(parameters.Empty, "", "?"+parameters)
End Sub

Finally, you can request the classification of an image. For example, put a button in a Window and in the Action event put the following code:

WatsonVisualRecognition.classifyImage(WeakAddressOf analyzeResponse, "https://watson-developer-cloud.github.io/doc-tutorial-downloads/visual-recognition/fruitbowl.jpg", .3)

Where analyzeResponse is the method that will read the results translating the Dictionary into something useful like actions for a database, a textual list or a simple text message.

Starting from this simple method, it is possible to create all the others, adding a bit of utility functions to the WatsonAPI base class.

As an example, it is possible to obtain the basic information about the people in this image and display it as an overlay:

Or update a database of images with classifications to then find the images of a specific type:

Create your own classifiers

Starting from this object it is easy to create an application to generate, update, and verify a classifier that is specific to this solution. While you can do it with the provided web interface, you can create a Xojo app that can return the feedback in a much easier and manageable way; and you can add some methods to automate the process of automatically discarding bad images and adding new ones in order to refine your classifier better.

Conclusions

Watson’s API services allow you to add a bit of artificial intelligence to your Xojo projects. The simplicity of the classes required to do this are clear proof of Xojo’s versatility.

It’s important to keep in mind that this service is not instantaneous. This is due in large part to network traffic; generally for sending the data and receiving the answer.

A really interesting option if you develop for MacOS would be to download your classifier in CoreML format and use it offline with MBS Core ML plugin.

Antonio Rinaldi is a professional engineer, Xojo developer for almost twenty years, Xojo evangelist for Italy since 2014, consultant and teacher. He develops extensions for Xojo iOS that you can find in the Xojo Store, and manages XojoItaliaBlog.com. Musician, composer, lover of good food, traveler and constantly curious, he is always looking for new ideas to expand his knowledge.

Along the way, we also will see how the Xojo IDE simplifies making subclass properties available from the Inspector Panel, so when using their instances we can set some attributes as the background color, pen size or border color in a more convenient way.

As usual, the first step to create a new subclass is adding a new class item to the Desktop project (Insert > Class). With the new class item selected, change its name to something descriptive. For this example we will use MyImageWell. The most important thing here is setting Canvas as its Super attribute. That means that the subclass will be based on the Canvas class, inheriting all its properties, Events and Methods so they will also be available for the subclass.

One of these inherited Events is Open, and we will implement it using the Event Handler option (click the + button in the toolbar to access the dropdown menu) in order to inform the class that we want to accept the dropped JPEG files. This is done with the following line of code in the Open Event Handler:

Me.AcceptFileDrop("img/jpeg")

Obviously, we can extend this support to accept other Xojo compatible graphical formats. For that, we would add a new File Type Set to the project, using it as the filter in the previous line of code.

Once we inform the class that we accept this feature, the next step is implementing the DropObject Event Handler that fires once this action is detected inside the limits of the control. The code we need to write for this Event Handler will test that the obj parameter passed along contains a valid FolderItem and, in that case, we will load such file as a new Picture object, assigning it to a property of the same Type. The code for the event is:

If obj.FolderItemAvailable Then
  image = Picture.Open(obj.FolderItem)
  Invalidate
End If

Don’t forget to add the Image computed property to the Class using Insert > Computed Property while the MyImageWell item is still selected, and using these values:

• Name: Image
• Type: Picture
• Scope: Public

As you can see, the amount of code we need to load the file as a Picture object and to assign it to the class property is minimal! Why do we use the Invalidate method call afterwards? Well, this is responsible for informing the operating system to redraw the instance when it has a chance. And when this happens it will fire the third and last Event we need to implement: Paint. Here is where we can instruct any Canvas based control how to draw itself through the graphical context represented by the g parameter passed along the Event.

Painting the control

Once we’ve added the Paint Event to the class and before writing the code responible of painting the dropped image inside its limits, we need to add three additional computed properties. We will use them to set some attributes like the color we want to use to paint the control background, the border color and even the width of the border:

• BackGroundColor As Color = &cdddddd
• BorderColor As Color = &c000000
• PenSize as Integer = 2

Add to the Setter method on every computed property the sentence me.invalidate; so every time we assign a new value to them… the control will be redrawn using the new value (background color, border color, pen size or even a new assigned picture).

The last step is writing the code responsible for drawing the control itself: filling the background with the set color, then drawing proportionally (and centered) the loaded picture pointed by the Image property, and finally drawing the border with the width and color specified. All of this is what we can do using the following snippet of code:

// We fill the control background using the set color
g.DrawingColor = BackgroundColor
g.FillRectangle(0,0,g.Width,g.Height)

// If we have a valid image object, then we draw it centered and scaled (if necessary)
If image <> Nil Then 
  Var Height, Width As Integer
  Var sourcey, sourcex As Integer = 0 
  If image.Height > image.Width Then
    Height = Me.Height
    Width = (Me.Height * image.Width) / image.Height
    sourcey = (Me.Width - Width) / 2
  Else
    Width = Me.Width
    Height = (Me.Width * image.Height) / image.Width
    sourcex = (Me.Height - Height) / 2
  End If

  // This is the line that actually draws a picture inside the graphic context of our instance
  g.DrawPicture(image,sourcey,sourcex,Width,Height,0,0,image.Width,image.Height)
End If

// We draw the control border
g.PenSize = me.PenSize
g.DrawingColor = BorderColor

g.DrawRectangle(0,0,Me.Width,Me.Height)

As you can see, the code needed for this is also very simple!

Make the properties visible from the Inspector Panel

While we are on it, we can use the Inspector Behavior feature to make our specific properties visible through the Inspector Panel. This way, when we add new instances from the subclass to the layout of any window, we will be able to easily set their values directly from the Inspector Panel. With the MyImageWell item still selected in the Project Browser, use the contextual menu to select the Inspector Behavior option to access the following Window:

Here you will see all the Class properties, those common to all Canvas derived subclasses and also the ones added for us and that are specific to our class. You can find these properties listed under the Behavior section. To make them visible in the Inspector Panel we just need to check their associated checkboxes; and even modify their default values editing the associated cell if we want to.

Now, we just need to drag and drop the MyImageWell item from the Project Browser into any Window Design Layout in order to add new instances! Once we run the example project, we will see how the controls react to displaying any JPEG picture dropped on it.

If you want, you can investigate deeper into the methods provided by the Graphics class in order to make the control more glittery or more sophisticated.

You can watch this video (en español) to see this in action:

Javier Rodri­guez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has be using Xojo since 1998. He manages AprendeXojo.com and is the developer behind the GuancheMOS plug-in for Xojo Developers, Markdown Parser for Xojo, HTMLColorizer for Xojo and the Snippery app, among others

*Read this post in Spanish

The Win32 API is largely based on the C/C++ programming language and makes heavy use of structures.

As a simple example, you can call a simple function to flash the window to get the user’s attention. Refer to the FlashWindow doc page in the Microsoft Win32 docs, where you can see the declaration for this method. It looks like this:

BOOL WINAPI FlashWindow(
 _In_ HWND hWnd,
 _In_ BOOL bInvert
);

This tells you that this method is a function (the BOOL at the beginning indicates it returns a Boolean) and that it takes two parameters. The HWND parameter is the handle to the window, which you get from Xojo as Window.Handle (it is an Integer). The BOOL parameter is a Boolean. At the bottom of the doc page there is a section that tells you the library that contains this function, which is “User32.lib”. With this this information you can create the Declare statement to this function, which looks like this:

Declare Function FlashWindow Lib "User32" (handle As Integer, invert As Boolean) As Boolean

You can call this function by passing in a window handle, so if you had the above Declare on a button’s Action event handler you could flash the window with this code:

Call FlashWindow(MyWindow.Handle, True)

Since the return value is not needed, the Call statement is used to avoid having to declare a variable to store the result.

If you wanted to make this more easily accessible you could use the Extends method feature to make this available for any window. To do this, create a global method on a module with this code:

Public Sub Flash(Extends w As Window)
  #If TargetWindows Then
    Declare Function FlashWindow Lib "User32" (handle As Integer, invert As Boolean) As Boolean
    Call FlashWindow(w.Handle, True)
  #EndIf
End Sub

You could then call this method with this code:

Self.Flash

For more information:

• Calling Native Windows APIs
• WinAPI Library

Most of the time you will reference the Foundation and AppKit libraries, but there are many other libraries as well. Xojo Declares use the Objective-C names so be sure to refer to those in the documentation rather than the Swift naming.

When you call Cocoa methods, you supply the method name using the Selector part of the Declare command. The selector name has to end in a “:” if there are any parameters that are passed, an oddity of how Objective-C works. Unlike with Xojo methods, the case of the name also has to match exactly. For the Xojo Declare, the first parameter is always required and must be a reference to the class containing the method you are calling.

To start with a simple example, consider that you may to center a window on the screen. You can obviously do this by manually adjusting the window’s Top and Left properties by taking into account the window size and the screen size, but Cocoa has a simple center function that can be used on a window.

On macOS, a Xojo window is actually a native NSWindow. When you view Apple’s docs for NSWindow you’ll see there is a center method. This method is very simple as it does not take any parameters. Looking at the doc page you should note that this function is in the AppKit library. Now you can create a Declare command to map to the center method:

Declare Sub centerWindow Lib "AppKit" Selector "center" (windowHandle As Integer)

Remember, even though the center method does not take any parameters, you still have to add a parameter to the Declare so you can pass in the reference to the calling class, which in this case is the window to center.

You can call this method like this (such as from a button’s Action event handler):

centerWindow(Self.Handle)

Because this method is called for a window, you can put it in a Xojo Extension Method to make it easier to call. To do this, create a global method on a module like this:

Public Sub Center(Extends w As Window)
  #If TargetMacOS Then
    Declare Sub centerWindow Lib "AppKit" Selector "center" (windowHandle As Integer)
    centerWindow(w.Handle)
  #EndIf
End Sub

Note the use of the “#If TargetMacOS” line. This prevents this code from being compiled into Windows or Linux builds of your app where the code could possibly crash your app.

This now allows you to have code like this on a window’s Open event to center the window:

Self.Center

To learn more about macOS Declares:

• Calling Native macOS APIs
• Mac Declare Samples

After a brief intro and some bragging about how this XDC sold out faster than any XDC before, how 25% of attendees are first-timers and how Xojo is represented by users from 12 different countries – shoutout to Stephane Pinel Xojo’s French Evangelist and and Javier Menendez our Spanish Evangelist who is attending for the first time (don’t think he’s a newbie though, he’s been with Xojo for 10 years), Geoff discussed the Xojo Community. Our forum has grown over 20% since the last XDC, with 18,000 members and over 43,000 conversations.

Xojo Cloud

People use Xojo Cloud because zero-configuration is an obvious advantage – we install more than 100 software updates per year which is 100+ actions that protect your app and your data that you don’t have to manage or install yourself. But it’s the industrial strength security that adds the most value. Xojo Cloud servers have been scanned over 1 billion times with zero known breaches to date. While no one can make servers 100% secure, Xojo Cloud certainly has proved itself to provide best-of-class security which is absolutely critical in today’s always-on, always-connected world. Check out Xojo Cloud‘s bigger and better servers – now with monitoring and stats build into the Xojo IDE.

Platform Landscape

Time zones can cause confusion even for super villains. But the Xojo framework has got you covered, whether you are out to do good or evil.

If you’ve written code for long enough, you’ve probably had bugs where you failed to consider some of the differences between two dates.

Consider the following Classic Xojo framework example that adds 3 hours to a specific date:

Dim d As New Date(2017, 11, 5)
d.Hour = d.Hour + 3
MsgBox(Str(d))

Easy enough, right? Unfortunately, while code like this will provide the correct result most of the time, it won’t this time because on November 5th, 2017 here in the United States, Daylight Savings ends. As a result, the value return will be off by an hour.

API 2.0 solves this problem by introducing the DateTime and DateInterval classes which is used to add or subtract time and takes into account time zones:

Var d As New DateTime(2017, 11, 5, 0, 0, 0, 0, TimeZone.Current)
Var di As New DateInterval(0, 0, 0, 3)
d = d + di
MessageBox(d.ToString)

This example creates a new date and provides the current time zone then creates a DateInterval and assigns it 3 hours. The DateInterval is then added to the date and the result displayed. This code will always be correct because time zones are being considered. This one is pretty straightforward because it’s only dealing with US Daylight Savings Time but imagine if one date was tied to someone in the US and another to someone in Europe. Not only do you have different time zones but Daylight Savings Time starts and stops on different dates between the US and Europe. The new DateTime and DateInterval classes in API 2.0 handle all of that complexity for you. Because the new DateTime class understands time zones, using TimeZone.Current for example, means you don’t even have to think about it at all. Your calculations will just work no matter where the user is in the world.

The API 2.0 solution requires one extra line of code. However, that one extra line gets you code that will always produce the correct result. The Date class in the Classic Xojo framework will be right most of the time but when it’s wrong, you may wrack your brain for a while trying to figure out why. That extra line of code is worth every keystroke.

This example deals only with time zones but the DateTime and DateInterval classes also handle leap years for you as well. That’s another example where it would be very easy to miss the fact that a leap year occurred and get the wrong result.

The changes to date and time handling in API 2.0 are just a few examples of why we have created it and why it’s worth your time to start using it.

Note: This post was updated for API 2.0 on June 15th, 2020.

The Mac had single digit marketshare. Creating a development tool, independently of Apple or any company that makes a platform such a tool would support, was considered a fool’s errand. There were plenty of tools available from large companies. Apple made MPW (the Macintosh Programmer’s Workshop). Symantec created THINK C. Metrowerks developed CodeWarrior.  IBM’s VisualAge. Macromedia Flash. If you needed to create a cross-platform desktop app, you’d be told to look no further than SUN Microsystems Java: THE cross-platform language. We were all promised that Java was going to run on everything from our computers to our cars to our can openers. Java was the safe and popular choice. Developers made up only about 5% of computer users anyway. Honestly, who would be crazy enough to launch a new development tool in a  market crowded by giants?

We were.

On July 4th of that same year, in a 10′ x 10′ booth at MacWorld Expo, the four of us that made up the fledgling company that is now Xojo, shipped version 1.0 of a new development tool that did one thing and one thing only: made it easy for regular people to create apps for the Mac.  It was not the most auspicious start but it didn’t matter to us. We believed in what we were doing. We believed that we were creating something that would enable ordinary people to do extraordinary things.

That our highest revenue days each week were Saturday and Sunday told us that our initial users were mostly hobbyists. Over the next year it shifted to the weekdays, telling us that people were building solutions for their jobs. Eventually commercial applications began to appear. Once we had a decent-sized user base, some prospective users, who were planning to make serious investments of their time, started asking the inevitable question of software extinction, “What happens if you guys go out of business?”

As much as I didn’t like hearing it, at the time it was a very legitimate question without a great answer. They would point to all the other development tools and propose that it would be safer to choose of them. Of course it would take much longer with one of those tools and if we didn’t go out of business that “safe” choice of theirs would end up being a very expensive insurance policy.

While it can be argued that the question of software extinction is always a relevant one, we have been providing and improving Xojo for almost 19 years. And in that time it’s gone from a development tool that built only Mac applications for System 7 running on a 68000 or PowerPC processor, to supporting an entirely new MacOS, multiple versions of Windows and Linux, console apps, web apps, iOS, Raspberry Pi and of course both X86 and ARM processors.  The framework has been through many updates to modernize its underlying systems while users have been mostly abstracted from these changes. We are rolling out a new framework that is mostly like the old one but makes some important modernizations to prevent common problems users face, including making it far more consistent and utilizing more OS-level functionality so that apps automatically use the latest libraries for functions such as HTTP, SSL and more. This Xojo framework is designed to allow you to migrate parts of your app as you need to do so. It’s an incremental process rather than a monumental one.

Part of the success of Xojo is not just its continued existence and evolution, but that those of us who had the original vision to bring it to life are still continuing to nurture it, help it grow and keep it modern. Though more have joined us along the way, there’s tremendous value in the consistency of vision.

What about those other development tools that were such good bets back in 1998?

• Visual Basic 6 is dead and has been replaced by Visual Basic.NET which is so different that many VB6 users began calling it “Visual Fred” as a way of mocking it.
• Macintosh Programmer’s Workshop is long dead.
• Symantec’s THINK C is dead.
• Metrowerks CodeWarrior was purchased by Motorola and is now focused exclusively on the embedded systems market.
• Borland Delphi is still around but was sold to another company and has become very expensive.
• IBM has discontinued VisualAge
• Java is of course still around but few use it for desktop applications after it proved to not be a good solution but a far better one for server-side applications. However, it’s no longer in the hands of original visionaries that brought it to market as SUN Microsystems was purchased by Oracle in 2009.
• Flash has been acquired by Adobe and while it is still in use, it’s clearly on its way out

If back in 1998 you chose to write your app in Xojo (then REALbasic), you have been able to continue to improve it and keep it running – not just on the latest version of the desktop OS you care about but several new operating systems and platforms as well. 19 years after that MacWorld Expo, we are still here and still providing the vision of what Xojo will be in the future. We continue to improve and modernize Xojo so that you can do what you do best: focus on what makes your application unique.

While the question of what you should do if you find your development tool of choice extinct or perhaps not properly cared for will always be a relevant one, we have shown that not only has Xojo stood the test of time, but that we have done so far better than most of our competitors who are an order of magnitude or more larger than we are.

No one can guarantee a product will be around forever. Even open source projects survive only as long as there are enough interested parties willing to donate their time and energy to continued development.  One of our engineers once said that, “Source Forge is littered with the corpses of open source projects.” Having said that, I can tell you that the people who bring Xojo to you are extraordinarily dedicated and talented. Our annual turnover rate (the rate at which people come and go at Xojo, Inc.) is only 5% which puts us amongst the best of the best in this area. This is not a happy accident, but very much by design. We have learned over the years to hire mostly users. In fact, nearly every member of the team began as a user. Those that didn’t, have been on the team for an average of 12.5 years. In an industry that sees people come and go through companies like a revolving door, the fact that people tend to stay at Xojo is a fact of which I am immensely proud.

It is our continued privilege to bring Xojo to you, to be a little part of your dreams, your aspirations, and to have you as a member of the Xojo community. Our next reunion will be April 25th-27th, 2018 in Denver, Colorado. We hope to see you there.

After a bit of experimentation this January we were able to isolate one huge cause of this annoying behavior. Unfortunately it has to do with a misconfigured IPv6 DNS server configuration and whether or not yours is correct may be up to your service provider.

Whose bug is this?

According to the spec, IPv6 DNS servers are supposed to return immediately if they can’t fulfill the request. Unfortunately this is almost the exact opposite of what an IPv4 DNS server does, in that it may forward your request to the next server to see if it knows where your request should go. Unfortunately we found that only about two-thirds of the ones we tested were correctly configured.

On macOS and Linux, DNS requests are sent concurrently, that is, two requests are sent at the same time, one each for IPv4 and IPv6. The one that returns first is used. On Windows, the requests are unfortunately sent sequentially, IPv6 and then IPv4. What this means is that IPv6 requests just hang there, waiting for a response that will either never come or will wait until the underlying socket reaches its timeout. When that fails, the IPv4 request is sent and fulfilled and your socket request goes through.

What To Do

Here are a few things you can do to test this theory. While you can’t really ask all of your users to do this, it will tell you if this is where the problem lies.

1. Turn off IPv6.
   1. Click Start and then Settings.
   2. Search for Network Connections.
   3. Click View network connections.
   4. Right-click on the active connection and select Properties.
   5. On the Networking tab, clear the Internet Protocol Version 6 (TCP/IPv6) check box, and then click OK.
2. Change the DNS entries for IPv6 from the defaults to point to Google Public DNS or OpenDNS.
3. Make a Hosts file entry. If your installer runs as an administrator, you can make an entry in the hosts file to force the computer to use IPv4. This is not a long term solution as the world moves to IPv6.The hosts file on Windows 7/8/10 is located at:

   C:\Windows\System32\drivers\etc

   and you should add an entry which looks like this:

   Server IP Address<TAB>domain name

4. If it’s a domain that you control, make sure you only use IPv4 DNS entries and that your server is only listening on the IPv4 interface.

All in all, it’s a frustrating problem. While there’s no easy solution, the good news is that because there are no IPv4 addresses left to be distributed, the world is moving to IPv6. The more demand there is, the more likely that the incorrect DNS servers will get fixed because they’ll cause problems for other sites as well.

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!

The traditional technique has been to use SortWith. You create a separate array of a simple type, populate it and then sort the temporary array using SortWith to sort the class array.

But there is an even slicker way to sort that was added in 2015 Release 3. You can now create your own custom comparison method and use that to sort the class. This custom method returns 0 if the values to compare are equal, a positive if the first value is greater than the second, and a negative value if the first value is less than the second.

This code can sort an array of DateTime:

Function DateCompare(value1 As DateTime, value2 As DateTime) As Integer
 // This assumes the array is populated with non-Nil dates
 If value1.SecondsFrom1970 > value2.SecondsFrom1970 Then Return 1
 If value1.SecondsFrom1970 < value2.SecondsFrom1970 Then Return -1
 Return 0
End Function

myDates.Sort(AddressOf DateCompare)

To learn more about class array sorting, refer to these doc topics:

• Array Sort Method in Reference Guide
• Array SortWith Method in Reference Guide
• Sorting Class Arrays in User Guide

Text

The new Text data type is a substitute for String and has the benefit of making encodings easier to work with. Essentially if you use Text, you don’t have to worry about the encoding. When you get data from an outside source (a file, a database or even a String), you specify the encoding so it can be stored as Text. Once it is in Text, you don’t worry about the encoding. When you need to send the Text to a file, DB or elsewhere, you convert it to data using whatever encoding is appropriate- usually UTF8.

You can easily use Text with your existing projects as a Text value converts back to a String automatically. For example, you can set a button Caption using a Text variable:

Dim t As Text = "Hello"
MyButton.Caption = t // converts automatically to String

If you have a String (such as a property of a UI control) you can easily convert it to Text by calling the ToText method. For example, you store the Caption of a button as Text:

Dim t As Text = MyButton.Caption.ToText

Dictionary

I prefer Xojo.Core.Dictionary because it is has an easy-to-use iterator, making it crazy-simply to loop through the items in the Dictionary:

Dim myDictionary As New Xojo.Core.Dictionary
myDictionary.Value("Name") = "Bob Roberts"
myDictionary.Value("City") = "Boston"
For Each entry As Xojo.Core.DictionaryEntry In myDictionary
  Dim key As Text = entry.Key
  Dim value As Text = entry.Value
Next

Xojo.Core.Dictionary can also be case-sensitive which is not even an option with the classic Dicitonary class! You just have to subclass (or use AddHandler) and implement the CompareKeys event handler:

Dim leftText As Text = lhs
Dim rightText As Text = rhs
Return leftText.Compare(rightText, Text.CompareCaseSensitive)

JSON

In the new framework, JSON is handled by two methods (Xojo.Data.ParseJSON and Xojo.Data.GenerateJSON), typically with Xojo.Core.Dictionary. Creating JSON text from a Dictionary is one line of code:

Dim jsonText As Text = Xojo.Data.GenerateJSON(myDictionary)

And converting JSON text to a Dictionary is also one line of code:

Dim jsonDict As Xojo.Core.Dictionary = Xojo.Data.ParseJSON(jsonText)

Both of these methods are much faster than using JSONItem in the classic framework.

HTTPSocket

Xojo.Net.HTTPSocket uses HTTP 1.1. This is a big advantage over the classic HTTPSocket which only supports HTTP 1.0 making it not always compatible with some sites.

I recently did a webinar that shows how to use HTTPSocket with a variety of web services.

TextInputStream/TextOutputStream

Lastly, I often work with Text files which means I have to deal with encodings. The TextInputStream and TextOutputStream make it easy to deal with encodings because the encoding is part of the method calls.

You can even use these classes with classic FolderItems by first converting them to Xojo.IO.FolderItem. For example, this prompts the user for a file and then opens it using a TextInputStream:

Dim f As FolderItem = GetOpenFolderItem("")
If f <> Nil Then
  Dim openFile As New Xojo.IO.FolderItem(f.NativePath.ToText)
  Dim input As Xojo.IO.TextInputStream
  input = Xojo.IO.TextInputStream.Open(openFile, Xojo.Core.TextEncoding.UTF8)
End If

If you have not already, try these new Xojo Framework classes in your projects. You’ll appreciate it!

Update (June 2020):

Since this was posted, there have been many updates to Xojo. In particular you should check out these equivalent API 2.0 features:

• Dictionary now also has an iterator.
• GenerateJSON and ParseJSON.
• URLConnection

In the Classic framework the JSONItem class is used to create, load and output JSON data. With the new “Xojo” framework, you simply use a Dictionary, which you can easily populate from JSON data or output to JSON data.

For example, here is some JSON data to use as an example:

{ "Seagulls":
  { "players":
    { "Bob":{ "position":"1B" },
      "Tom":{ "position":"2B" } }
},
  "Pigeons":
  { "players":
    { "Bill":{ "position":"1B" },
      "Tim":{ "position":"2B" } }
},
  "Crows":
  { "players":
    { "Ben":{ "position":"1B" },
      "Ty":{ "position":"2B" } } }
}

With the above JSON data pasted into a TextArea, you can load it with just a single line of code:

Dim league As Dictionary = Xojo.Data.ParseJSON(JSONArea.Text.ToText)

This is similar to the classic framework, which would look like this:

Dim league As New JSONItem(JSONArea.Text)

Looping through the JSON data is also similar. In the Xojo framework, you just iterate through the Dictionary with each JSON section as its own Dictionary:

Dim teamName, playerName As TextDim team, players, player As Dictionary

For Each t As DictionaryEntry In league
  teamName = t.Key
  team = t.Value
  OutputArea.AppendText(teamName)
  OutputArea.AppendText(EndOfLine)
  players = team.Value("players")
  For Each p As DictionaryEntry In players
    playerName = p.Key
    player = players.Value(playerName)
    OutputArea.AppendText(" " + playerName + " ")
    For Each a As DictionaryEntry In player
      OutputArea.AppendText(a.Value + " ")
    Next
    OutputArea.AppendText(EndOfLine)
  Next
Next

In the Classic framework, you iterate through the count of items in the JSONItem:

Dim teamName, playerName As StringDim team, players, player As JSONItem

For i As Integer = 0 To league.Count-1
  teamName = league.Name(i)
  team = league.Value(teamName)
  OutputArea.AppendText(teamName)
  OutputArea.AppendText(EndOfLine)
  players = team.Value("players")
  For p As Integer = 0 To players.Count-1
    playerName = players.Name(p)
    player = players.Value(playerName)
    OutputArea.AppendText(" " + playerName + " ")
    For a As Integer = 0 To player.Count-1
      OutputArea.AppendText(player.Value(player.Name(a)) + " ")
    Next
    OutputArea.AppendText(EndOfLine)
  Next
Next

An example project for the above code is here.

To create JSON from a Dictionary, you use the the GenerateJSON method:

Dim d As New Xojo.Core.Dictionary
d.Value("Name") = "Bilbo Baggins"
Dim json As Text = Xojo.Data.GenerateJSON(d)

Grab Xojo 2015r2 and start using GenerateJSON and ParseJSON the Xojo framework today!

Update (June 2020):

Since this was written, GenerateJSON and ParseJSON were also added as part of API 2.0.

Ch-ch-ch-changes (turn and face the strain) – David Bowie

As you have read in previous blog posts, we are building a new framework to clean things up. We refer to the current framework as the “Classic” framework and the new one as the “Xojo” framework. The Xojo framework was introduced four months ago with our support for iOS and at that time was limited to iOS projects only. With today’s release of Xojo 2015r2, we have added a lot more functions to the Xojo framework, all of which are now supported for the desktop and web in addition to iOS.

Previously, there were different ways to deal with errors depending on what part of the Classic framework you were using. For example, if you passed a string to the Val function, it would return zero if the function started with a non-numeric character. Pass Val the string “123$” and you’ll get 123 but pass it “$123” and you’ll get 0. Use the Left function to get the 5 leftmost characters from a string that has only 4 characters, and it will return those 4 characters. These may seem like reasonable results to return given what was passed in. But there are downsides to them.

There are three problems with handling errors in this way. First, they are all different so you have to learn different ways to handle different errors. Second, they are behaviors rather than actual errors and third (and most important), they allow code to pass along a value that could be legitimate without the user knowing it’s an error at all. This can create hard to find bugs. For example, say you are importing sales data from a text file. One of the thousands of values you import has a dollar sign at the front. This results in a zero when passed to Val. If zero is a potentially legitimate value, this error could easily be over-looked.

In the new framework, this won’t happen. Instead of using Val to convert text to a number (integer), you use the FromText function. Your code looks like this:

Sales = Integer.FromText(QuarterlySalesImportedValue)

If QuarterlySalesImportedValue cannot be converted to a number (because it starts with a non-numeric character like a $), rather than return a zero, a BadDataException exception is thrown. While the Classic framework has many different ways to handle errors, the new Xojo framework uses exceptions exclusively for reporting errors, making it more consistent.

In the Classic framework, detecting an error like this means converting the text to an integer then back to text and to compare it with the original value to see if they are the same. If they are, great. If they aren’t, then there was a non-numeric character in there. In the Xojo framework, you don’t worry about it and check for an exception.

If you haven’t used exception handling in your code before, don’t panic. It’s really not a big deal. An exception means that something unusual has happened and in most cases the app (or at least the function of the app the user is using) can’t continue. To use an exception you wrap the block of code that might result in an error in a Try…Catch statement. If an exception occurs, the code will call the exception handler (the catch portion of the Try…Catch statement) and deal with the error. Here’s an example:

Try
  'code to open the file and read the data here
  i =  Integer.FromText(ImportedQuarterlySalesData)
  'code to deal with the converted value here
Catch err As Xojo.Core.BadDataException
   Beep
   MsgBox "The import can't continue because the sales data is bad."
End Try

In this example I’ve left out the code you’d write to open the file, read in the data and do something with it, but you get the idea. In the new Xojo framework, all the functions that deal with opening and reading files throw the same BadDataException if something goes wrong, a single Try…Catch can handle it all. And of course you could choose to make the error message more specific, telling the user what row the bad data came from and showing them the bad data itself so they can go fix the data file. Exceptions also potentially remove lots of IF statements that often litter code checking for error conditions.

When it comes to errors, luck favors the prepared. Write your code so that it anticipates errors properly and handles them rather than waiting for the user to report that your software doesn’t work. In the new Xojo framework we are making it easy for you to do this by consistently using exceptions to report errors. They don’t require more code than using IF statements and in many cases, require less code and make your code easier to read.

We’ve added a lot more functionality to the new framework in 2015r2 allowing you to write most of your non-GUI code using the new framework and share that across all project types. For example, we have:

• HTTPSocket (which supports HTTP 1.1 – yes, you’ve been asking for that for years)
• FolderItem
• SpecialFolder
• BinaryStream
• TextInputStream
• TextOutputStream
• Crypto
• Introspection
• All the math functions (log, min, max, abs, etc.)
• JSON

You’ll find that most of these classes work very similarly to those in the Classic framework. Click the items in the list above to review them. And these are just the new Xojo framework functions. We’ve added more to our iOS support as well.

When using the Xojo framework with your existing Classic code, you’ll need to use the new Using command or include the namespace with each function. I think you’ll find Using to be a better option. You can also use it for an entire class, module or window by right-clicking on the project item then choosing Add To -> Using Clause. Once the Xojo framework is complete, there will be a way to use it without bothering with Using at all.

We’ve made a lot of progress on the Xojo framework for 2015r2 which provides you with a more consistent and thus more productive experience. Yes, there will be a few new things to learn but there’s also a lot of great, new functionality as well. Over the years, we have had to write a lot of this functionality ourselves or use third party libraries. So much of what is needed is now built-in to the OS so in the Xojo framework, we can now call the OS functions directly. That means your Xojo apps pickup more functionality automatically without you (or us) having to do additional extra work. It also means that when bugs are fixed at the OS level, your apps automatically become more reliable without having to recompile them.

First, remember the old Date class remains available for desktop/web/console projects.

In this post I’m specifically talking abou the new Xojo.Core.Date class. The big change is that Xojo.Core.Date is now immutable. With the old Date class, if you changed Date properties in the “wrong” order, such as set Day to 31 before setting Month to 9 then unexpected things start to happen. It also caused problems with things like FolderItem.ModificationDate (for example) because you might think you could actually change the modification date by directly changing its Date properties, but that doesn’t actually work.

So Xojo.Core.Date is immutable. You get a new Date by using one of the Constructors. If you need the current date, you use Date.Now. And with this we’ve added the companion DateInterval and TimeZone classes to make it easy to do math on Dates and to convert a date/time to a different time zone.

In particular, you can now do arithmetic on Dates. For example, if you want to get the Date that is two months earlier than now, you can create a DateInterval and subtract it from the Date:

Dim twoMonths As New DateInterval
twoMonths.Month = 2 // 2 month interval

// Get date two months before today
Dim past As Date = Date.Now - twoMonths

Or if you want to know the the interval until Jan 1, 2030:

Dim d2 As New Date(2030, 1, 1, TimeZone.Current)
Dim interval As DateIntervalinterval = d2 - Date.Now

Need to convert the current date/time to GMT? Try this:

Dim GMTZone As New TimeZone("GMT")
Dim GMTDate As New Date(Date.Now.SecondsFrom1970, GMTZone)

You can use Xojo.Core.Date in all project types (Desktop, Web, Console and iOS).

Update (June 2020):

Since this was written, the DateTime class was added as part of API 2.0.