Now, for even simpler one-off or chained delayed tasks, Xojo offers Timer.CallLater: no Timer instance required.

The Strategy: Timer.CallLater

Timer.CallLater(milliseconds, AddressOf MethodName, arg As Variant) schedules your method to run after the specified delay on the main UI thread. Pass data via the Variant parameter. To chain calls (like our countdown), re-call it from within the method. Use Timer.CancelCallLater(AddressOf MethodName) to abort pending calls.

For full details, see the Timer documentation.

Looking at the Code

Prerequisites: Add a StatusLabel (DesktopLabel control) and a constant kCountTo As Integer = 20000.

Let’s look at how we implement this.

The Setup (Button Pressed)

Place the following code in the Pressed event handler of a button control:

Sub Pressed()
  Timer.CancelCallLater(AddressOf UpdateProgress)
  
  StatusLabel.Text = "0"
  
  Timer.CallLater(100, AddressOf UpdateProgress, 100)
End Sub

The Handler (Recursive Chain)

Create the following method that handles the recursive chain of delayed updates:

Sub UpdateProgress(elapsedMs As Variant)
  Var elapsed As Integer = elapsedMs.IntegerValue
  
  If elapsed >= kCountTo Then

    StatusLabel.Text = "done"

  Else

    StatusLabel.Text = elapsed.ToString
    Timer.CallLater(100, AddressOf UpdateProgress, elapsed + 100)

  End If
End Sub

Crucial Note: The handler method must accept a Variant parameter to receive the argument passed to CallLater. Always use type-safe extraction like .IntegerValue.

How It Works

1. Initial Schedule: The button cancels any pending calls and schedules the first UpdateProgress after 100ms, passing 100 as the elapsed time (just in case we like pressing a button multiple times quickly).
2. Recursion: Each call updates the UI and, if not finished, schedules the next one 100ms in the future with incremented elapsed time.
3. Automatic Management: No Timer properties or handlers to manage; Xojo handles scheduling and cleanup.
4. Cancellation: Ensures only one chain runs at a time.

Wrapping Up

Timer.CallLater shines for delayed UI updates or chained tasks without the overhead of Timer objects. It’s concise, safe, and powerful for responsive apps.

In Part 5, we’ll tackle true background processing with Threads and UserInterfaceUpdate.

Until then, happy coding!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Optimizing Code Series:

• Optimizing Xojo Code, Part 1: Getting Started
• Optimizing Xojo Code, Part 2: Using a Timer to Keep the UI Responsive
• Optimizing Xojo Code, Part 3: Programmatic Timers and AddHandler
• Optimizing Xojo Code, Part 4: Timer.CallLater
• Optimizing Xojo Code, Part 5: Threads and UserInterfaceUpdate

But what if you need a timer inside a Class or a Module where you can’t drop a visual control?

The Strategy: AddHandler

When you use a Timer control from the library, you double-click it to add an Action event. When we create a Timer in code, we don’t have a “code editor” for it in the same way. Instead, we use the AddHandler command to tell Xojo: “When this timer fires its Action event, run this specific method instead.”

Looking at the Code

Let’s look at how we implement this. In our example project, we have a button that initializes our timer and a separate method to handle the “ticks.”

The Setup

First, we define a property on our window (or class) to hold our timer: mWaitTimer As Timer

Then, in the Pressed event of our button, we instantiate it:

Sub Pressed() Handles Pressed
  ' 1. Cleanup
  If mWaitTimer <> Nil Then
    mWaitTimer.RunMode = Timer.RunModes.Off
    mWaitTimer = Nil
  End If
  
  ' 2. Initialization
  mElapsedMs = 0
  StatusLabel.Text = "0"
  
  ' 3. Create the dynamic timer
  mWaitTimer = New Timer
  mWaitTimer.Period = 100 ' 100 ms tick
  mWaitTimer.RunMode = Timer.RunModes.Multiple
  
  ' 4. The Magic: Link the Action event to our WaitTick method
  AddHandler mWaitTimer.Action, AddressOf WaitTick
End Sub

The Handler (Doing the Work)

Now, let’s create the method named WaitTick. Crucial Note: When using AddHandler for a Timer, the first parameter of your receiving method must be of the type Timer so it knows which object triggered it.

Sub WaitTick(t As Timer)
  mElapsedMs = mElapsedMs + t.Period
  
  If mElapsedMs >= kCountTo Then
    ' Achievement unlocked! Stop the timer and clean up
    t.RunMode = Timer.RunModes.Off
    StatusLabel.Text = "done"
    
    ' It's good practice to remove the handler when done
    RemoveHandler t.Action, AddressOf WaitTick
  Else
    StatusLabel.Text = mElapsedMs.ToString
  End If
End Sub

How It Works

1. New Timer: We create a new instance of the Timer class in memory.
2. AddHandler: This command connects the Action event of our new timer to the WaitTick method. The AddressOf operator tells Xojo the memory location of the code we want to run.
3. Passing the Object: Because WaitTick receives t As Timer as a parameter, you can actually use the same handler for multiple different timers and knows exactly which one is calling for attention.

Wrapping Up

By moving your Timers into code, you take a significant step toward writing more modular Xojo applications. You’ve moved the logic from “Global UI state” into “Managed Code execution.”

In the upcoming Part 4, we’ll look at a shortcut that makes one-off background tasks a breeze: Timer.CallLater.

Until then, happy coding and don’t forget to add your own solution in the Xojo Forum!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Optimizing Code Series:

• Optimizing Xojo Code, Part 1: Getting Started
• Optimizing Xojo Code, Part 2: Using a Timer to Keep the UI Responsive
• Optimizing Xojo Code, Part 3: Programmatic Timers and AddHandler
• Optimizing Xojo Code, Part 4: Timer.CallLater
• Optimizing Xojo Code, Part 5: Threads and UserInterfaceUpdate

Step 1: Let’s sketch the goal

We will need a button that, when pressed, starts a simulated wait that updates a label every 100 ms until a fixed duration (kCountTo, which remains 20000 ms in our example) is reached. So, the timer will fire periodically and handle the counting there. The button simply resets state and starts the timer.

Step 2: Prepare the UI components

Create a DesktopLabel named StatusLabel to display progress.
Add a DesktopButton (caption it “Method 1”) whose Pressed event will kick off the timer.
Finally, place a Timer control onto the window, name it mTimer, set its Period to 100, and set RunMode to Multiple (but leave it off until the button starts it).
Add an Integer property to the window such as mMsWaited to accumulate elapsed milliseconds, and keep kCountTo defined as 20000.

Step 3: Wire up the button

The button handler becomes very simple. Reset the tracked milliseconds, show "0" in the label, ensure the timer runs at 100 ms ticks, and let it fire repeatedly:

Sub Pressed()
  // Reset the tracked elapsed ms and start the timer at 100 ms ticks.
  mMsWaited = 0
  StatusLabel.Text = "0"
  mTimer.Period = 100
  mTimer.RunMode = Timer.RunModes.Multiple
End Sub

This code primes the state but does not block. The timer will perform the actual counting.

Step 4: Let the timer take over

Implement mTimer.Action to run on the UI thread. Each tick adds the timer’s period to mMsWaited, updates the label, and turns itself off once kCountTo has been reached:

Sub Action()
  mMsWaited = mMsWaited + Me.Period

  If mMsWaited >= kCountTo Then
    Me.RunMode = Timer.RunModes.Off
    StatusLabel.Text = "done"
  Else
    StatusLabel.Text = mMsWaited.ToString
  End If
End Sub

This keeps your UI responsive because the timer fires briefly and returns control back to the event loop instead of spinning inside a While loop.

Step 5: Test the flow

Run the app, click the button previously created and watch the label count up and stop at the target value. The timer approach lets other interface interactions remain responsive while still providing clear progress feedback.

What makes this timer driven solution a solid first step?

It shows how you can preserve the original behavior while giving the UI breathing room. It avoids App.DoEvents, reduces tight loops, and still delivers frequent updates. In the next article we’ll build on this idea and explore alternative approaches that continue to improve responsiveness and structure.

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Optimizing Code Series:

• Optimizing Xojo Code, Part 1: Getting Started
• Optimizing Xojo Code, Part 2: Using a Timer to Keep the UI Responsive
• Optimizing Xojo Code, Part 3: Programmatic Timers and AddHandler
• Optimizing Xojo Code, Part 4: Timer.CallLater
• Optimizing Xojo Code, Part 5: Threads and UserInterfaceUpdate

Create a new iOS project and on Screen1 add a couple Buttons and a Canvas, the buttons at the top and the Canvas using up the rest of the space. Also add a Timer.

Add some properties to track the ball’s position and direction:

• Public Property XDirection as Integer = 10
• Public Property XPosition as Integer = 10
• Public Property YDirection as Integer = 10
• Public Property YPosition as Integer = 10

In the Opening event for Screen1, initialize the Timer (which I’ve named MoveTimer):

MoveTimer.Period = 50
MoveTimer.RunMode = Timer.RunModes.Multiple
MoveTimer.Enabled = False

Speaking of the Timer, in its Run event put this code to move the ball:

XPosition = XPosition + XDirection
YPosition = YPosition + YDirection
BounceCanvas.Refresh

Add the Paint and PointerDown events to the Canvas. In the Paint event draw the ball with this code:

Var size As Integer = 25
g.DrawingColor = Color.RGB(255, 0, 0)
g.DrawRectangle(0, 0, g.Width, g.Height)
g.FillOval(XPosition, YPosition, size, size)
If (XPosition + size) > g.Width Then
  XDirection = -XDirection
End If
If ( YPosition + size) > g.Height Then
  YDirection = -YDirection
End If
If XPosition < 0 Then
  XDirection = -XDirection
End If
If YPosition < 0 Then
  YDirection = -YDirection
End If

And in the PointerDown event, reset the ball’s position to the touch:

XPosition = position.X
YPosition = position.Y
XDirection = -XDirection
YDirection = -YDirection

Lastly you can add the Pressed event to the Start button and tell it to start the Timer:

MoveTimer.Enabled = True

Similarly add the Pressed event to the Stop button and tell it to stop the Timer:

MoveTimer.Enabled = False

That’s it. Run the project, click start to watch the ball bounce. Tap on the screen to change its position and direction. You could probably use this as the start of a Pong game!

Oh, and I forgot to mention that the code above was actually copied from the Android project where I first created this. The exact code copied over to iOS and worked as is with no changes. For a little teaser, here’s Bounce running on Android:

At first glance you might think that simply looking for the option key in a KeyDown event will do the trick. The problem is KeyDown/KeyUp does not get called for modifier keys. The solution is to use a Timer to detect the Option/Alt key, though it could be adapted to read any of the modifier keys.

First of all, we need to decide whether to create a Timer embedded on a Window, or to create a subclass. Either technique will work, but the subclass creates reusable code, something I always recommend. Also, the subclass will allow you to call events which can come in handy.

Start by creating a new class called “OptionTimer” whose super is “Timer”. Next, add a property “Pressed As Boolean”, an event definition “KeyDown”, and a second event definition “KeyUp” to OptionTimer. Lastly add the Action event handler with the following code:

If Keyboard.AsyncAltKey = True And Pressed = False Then
  Pressed = True
  RaiseEvent KeyDown
ElseIf KeyBoard.AsyncAltKey = False And Pressed = True Then
  Pressed = False
  RaiseEvent KeyUp
End If

That’s it for code. Now go to your Window, place a Timer on it and set the super to “OptionTimer” and you can insert code into the events for that timer. You’ll also want to adjust the period of the timer to something small such as 200 to make sure the events are responsive.

To test this, add a Label to the Window which will be used to display different text when the Option key is held down. In the Timer subclass, put this code in the KeyDown event:

Label1.Value = "You are pressing Option."

And in the KeyUp event put this code:

Label1.Value = "Normal Text"

Run the project and watch the text change when you hold and release the Option/Alt key.

*Updated from an original post written by Thom McGrath.

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.

Let’s start with the foundation. The Timer period is determined by the hardware internal clock and, specifically, by the OS driver. Under Windows, all modern computers are capable of providing a resolution above the 16 ms set by Windows by default.

In fact, when we use the NtQueryTimerResolution function (from the NTDLL.DLL library) we can get minimum, maximum and current timer values for the hardware it is running on, similar to these (based on my own computer running Windows 10 under a VMWare Fusion virtual machine):

• Minimum Resolution: 15.62 ms
• Maximum Resolution: 0.5 ms
• Current Resolution: 0.99 ms

As you can see, the first value matches the current Timer behavior under Windows, but the hardware tell us that we can reach even a higher resolution … even of 0.5 ms between timer firings.

In order to make this change, Windows offers several options (all of them available under Xojo via the use of Declares or, preferably, using External Methods).

The first of these options, the one that would be the optimal approach, uses the group of MultimediaTimer functions (or high resolution Timers); specially these:

• CreateTimerQueueTimer: Allows creating a timer with a delegate (or Callback) that will fire just one time, or regularly at the set period interval. This would be a behavior similar to the current Xojo Timer class.
• ChangeTimerQueueTimer: Using this function, we can modify the firing period for an already created timer; like the one we got when using the previous function.

The main problem we will face when using these functions is that Windows creates these Timers on a different thread than the one used by the Xojo app. During my tests, this is a showstopper due to the fact that, currently, Xojo doesn’t support the use of pre-emptive threading. Thus, it can’t coordinate the execution of our Timer Callback with the tasks in place by the Xojo framework. As result, at some random point our app will be pointing to Nil objects and will silently stall.

In addition, these kind of Timers are reentrant. That means that the timer will execute the Callback again even if the previous call has not finished the job yet.

During my tests, I found a way to solve this kind of reentrant problem using one-time firing Timers. This way, the callback method would be the responsible for deleting the previously created Timer (this is needed to not overflow the maximum limit of 500 timers), and create a new one-time firing timer.

But this approach doesn’t solve the main problem: at a random point, the app unexpectly quits due to the fact of the non preemptive multithreading coordination between the one created by Windows for the Timer and the main, single thread, used by the Xojo apps.

Same Thread Timers

Once you have discarded the previous (optimal) approach, the technique you can use is based on the use of another kind of Timer provided by Windows: WaitableTimer. This kind of timer is created and, most important, run under the same thread they were created on. Thus, there is no collision with the Xojo framework during the application execution. In adition, as it goes with the commented High Definition Timers, we can achieve the same maximum resolution of 1 ms.

To start creating and using this kind of Timers in your Xojo app, first add an External Method so we can set the function definition from the C or C++ Windows Library.

In a new Xojo project, add a Module and our first External Method in it using the following values:

• Method Name: CreateWaitableTimerW
• Parameters: att as ptr, resetMode as Boolean, timerName as CString
• Return Type: Uint32
• Lib: Kernel32.dll
• Soft: Enabled

As you can see, this function returns a UInt32 value that will be non zero if it has succeeded creating the Timer. In fact, the returned value is a Handler pointing to the Timer structure of data. Thus, it is recommended to store this value in a property you can access later when you need it for calling other functions to delete (i.e: cancel), and for deleting the handler in order to free the used memory.

From the Xojo code point of view, later we can use this external function in this way:

Dim name As CString = "name"
handler = CreateWaitableTimerW(Nil, False,  name)

In this example, the handler variable is a property set in a class that works as a wrapper (see the example project).

Once we get the Handler, we will be able to set the parameters of the Timer functionality, using the SetWaitableTimer function. As in the previous case, we need to add a new External Method using the following values:

• Method Name: SetWaitableTimer
• Parameters: hTimer as uint32, byref lpDueTime as LARGE_INTEGER, period as uint32, CompletionRoutine as ptr, parameter as uint32, resume as Boolean
• Return Type: Boolean
• Lib: Kernel32.dll
• Soft: Enabled

As you can see in the method signature, we are using a data type that is not available in the Xojo Framework: LARGE_INTEGER. This is a very simple data structure needed when calling the function (in fact, it needs a pointer to this structure, so this is why we employ the ByRef keyword here. This is the way to get a pointer to the structure).

So, we need to add a new Structure definition into our Xojo project, using these values:

• Structure Name: LARGE_INTEGER

And setting the following value in the Declaration editor for the Structure declaration:

• quadPart As Int64.

Setting the Timer Values

Now we can write the Xojo code to call the added External Method:

pLarge.quadPart = -5
b = SetWaitableTimer(handler, pLarge, TimerPeriod, AddressOf callback, 0, False)

The important arguments passed to the function are these:

• Handler: This is the (non zero) value we got calling the previous function.
• pLarge: This is a property added to the project, and whose data type matches the defined structure. As you can see, we have previously assigned to it the negative value -5. It is very important to assign here a value, or starting point from the past time, in this case, five milliseconds.
• TimerPeriod: Here we set the firing period for the Timer (for example, 1 ms.).
• AddressOf callback: Here we set the memory address of the Xojo method we want to execute when the Timer fires. It is very important to add this method into the project as a Shared Method. In this example, the Xojo Method name is callback.

The function call will return a Boolean value: True if it had success, or False otherwise.

Signaling the Timer Firing

However, this kind of timer need to be signaled for them to execute. That means that we need to add other External Method to our Module from the Windows Kernel32.DLL library: SleepEx:

• Method Name: SleepEx
• Parameters: miliseconds as uint32, bAlertable as Boolean
• Return Type: Uint32
• Lib: Kernel32.DLL
• Soft: Enabled

Once it has been set, we can create an endlees loop in our Xojo Code, so the Timer keeps signaling:

Do 
  result  = SleepEx(INFINITE, True)
  app.DoEvents
Loop Until CancelTimer = True

I’m using here the Boolean CancelTimer property in order to have a way to exit the loop (and interrupting the Timer execution) when required from the app.

Another important parameter is the one used by the call to the SleepEx function: INFINITE. This is a Constant added to the project, whose value in hexadecimal is &hFFFFFFFF.

Timer Cleaning

Unlike the Windows High Definition or Multimedia Timers, we can’t modify the firing period for the WaitableTimers once they have been set. The only way to do it is to delete the one previously created, and create a new one; something you need to do when quitting the app or when you just need the Timer to fire once.

For this, we need to use the CancelWaitableTimer function. Add a new Exterrnal Method with this values for the method signature:

• Method Name: CancelWaitableTimer
• Parameters: thandler as uint32
• Return Type: Boolean
• Lib: Kernel32.DLL
• Soft: Enabled

In addition, and as part of the cleaning process, we need also to call the function in charge of freeing the used Handler. Add the last External Method with this signature:

• Method Name: CloseHandle
• Parameters: tHandler as Uint32
• Return Type: Boolean
• Lib: Kernel32.dll
• Soft: Enabled

Now, you can use the following Xojo code to cancel the timer and delete the handler:

If handler <> 0 Then
  Dim b As Boolean
  b = CancelWaitableTimer( handler )
  b = CloseHandle( handler )
End If

To Summarize

As you can see, the main disadvantage of this technique is that you’ll be interrupting the usual workflow of the app: it will not return to the calling method or event once it enters into the method in charge of creating and firing the Timer (until the exit the Loop, of course). The way to make the app responsive and execute the code associated with the UI controls is through the App.DoEvents line of code.

Additional Reading:

• About Multimedia or High Resolution Timers: CreateTimerQueueTimer function
• About setting the inner clock in Windows: timeBeginPeriod Function
• About setting Timers on the same Thread (WaitableTimers): SetWaitableTimer function
• About Windows Data Types: Data Types

Example Project

You can download the example project, available from this link, to see and test the following:

• Exposed technique in action (Timers with a maximum resolution of 1 ms.)
• How to modify the period value with the cancelation of a previously created timer
• How to modify on the fly the Callback code executed by the Timer
• How to get the Current, Minimum and Maximum clock resolutions from the Windows computer you’re using to run the app

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