• Modules: organize shared helpers that don’t store data. They just do a job and return a result.
• Classes: represent objects that keep data and have actions.
• Interfaces: agreements about what methods exist so parts can work together without caring how they’re built.
• Delegates: a way to pass a function around so another part of your app can call it later (a callback).

Modules

Purpose

• Provide a namespace for related helpers, constants, and enums.
• Offer reusable helpers that don’t remember data between calls.
• Add extension methods that make calling code cleaner.

Use when

• You need shared helpers (formatting, parsing, conversions).
• You want to group constants/enums (error codes, log levels).
• You’re adding behavior to existing types via extension methods.

Avoid when

• You’re tempted to store changeable global data that creates hidden dependencies.

Benefits

Read more: Xojo Modules Documentation

Classes

Purpose

• Represent real concepts in your app (e.g., an order, a report, a session).
• Keep data and the related rules/actions in one place.
• Separate concerns: core logic in classes, screen logic in the UI.

Use when

• You have data that changes over time and rules to enforce.
• You need services that coordinate steps (for example, “Export report” or “Sync data”).
• You want testable units that don’t depend on UI elements.

Avoid when

• You only need a simple helper that returns a result (that belongs in a Module).
• Platform-specific calls would leak into core logic (hide those behind Interfaces).

Benefits

• Clear rules kept close to the data they protect.
• Clean boundaries between UI, core logic, and data access.

Read more: Xojo OOP Classes Documentation

Interfaces

Purpose

• Define the what without the how.
• Let you swap implementations (e.g., memory vs. SQLite vs. REST) without changing calling code.
• Make testing simple by substituting fakes/mocks.

Use when

• A feature may vary by platform or environment (file system, keychain, camera, notifications).
• You want to keep app logic separate from the details of databases, files, or network calls.
• You’ll have multiple strategies that share the same shape.

Avoid when

• There’s only one implementation and you don’t need to test in isolation.

Benefits

• Loose coupling and easier future changes.
• Cleaner, more stable internal APIs.

Read more: Xojo Interfaces Documentation

Delegates

Purpose

• Provide type-safe callbacks by letting you hand a function to another part of your app.
• Enable flexible behavior without defining a whole interface and class.
• Power progress updates, cancel handlers, filters, or small strategies.

Use when

• You need a one-off callback (progress, completion, error reporting).
• You want to inject small pieces of behavior (sorting, filtering, formatting).
• You’re wiring up dynamic behavior at runtime.

Avoid when

• You need a broader contract with multiple related methods (use an Interface instead).
• You need lifecycle or semantic grouping (a Class with events may be clearer).

Benefits

• Lightweight and expressive.
• Less boilerplate than creating full classes for simple callbacks.
• Encourages small, composable, testable pieces.

Read more: Xojo Delegates Documentation

Quick Decision Guide

• I need to group common helpers and constants. → Module
• I’m modeling an object with data and rules. → Class
• I want to depend on behavior, not a specific implementation. → Interface
• I need a small callback or injected behavior. → Delegate
• I need many subscribers to a lifecycle change. → Event on a class

Quick glossary

• Interface: a contract, a named list of methods something promises to have.
• Delegate: a variable that holds a function to call later (a callback).
• Event: a signal that something happened; other parts can listen for it.

Use Modules to organize shared helpers, Classes to model your world, Interfaces to decouple and swap implementations, and Delegates to pass behavior flexibly. Combined thoughtfully, these features keep Xojo projects easy to change, easy to test, and ready to ship across platforms.

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

What are Delegates?

A Delegate in Xojo is essentially a “pointer” to a method. It allows you to dynamically reference a method, treating it as if it were a variable. This means that a method can be passed to another method or function like a data variable.

' Defining a Delegate
Delegate Sub MyDelegateMethod(value As Integer)

' Method to be called
Sub PrintNumber(value As Integer)
  MessageBox("Number: " + value.ToString)
End Sub

' Using the Delegate
Sub UseDelegate()
  Var d As MyDelegateMethod = AddressOf PrintNumber
  d.Invoke(10) ' Calls PrintNumber with the value 10
End Sub

In this example, a delegate MyDelegateMethod is defined to reference a method with an Integer parameter. Then, the method PrintNumber is assigned to the delegate variable d, and it is invoked using d.Invoke().

What is AddHandler?

The AddHandler command is used in Xojo to dynamically associate a method with an event. Instead of assigning an event handler in the design phase, this can be done at runtime. This allows for more flexible programming, especially in situations where event handling routines need to be assigned or changed dynamically.

' Method that acts as an event handler
Sub ButtonPressed(sender As DesktopButton)
  MessageBox("Button was pressed!")
End Sub

' Using AddHandler
Sub SetupButtonHandler(button As DesktopButton)
  AddHandler button.Pressed, AddressOf ButtonPressed
End Sub

In this example, the ButtonPressed method is dynamically associated with the Pressed event of a DesktopButton. When the button is pressed, the ButtonPressed method shows a message.

Important Note: Using RemoveHandler with AddHandler

Whenever you use AddHandler, it’s important to remember to use RemoveHandler to properly un-assign the event handler when it’s no longer needed. If you fail to remove the handler, you may encounter memory leaks or unexpected behavior, especially when working with objects that are frequently created and destroyed.

' Removing the event handler
Sub RemoveButtonHandler(button As DesktopButton)
  RemoveHandler button.Pressed, AddressOf ButtonPressed
End Sub

In this case, RemoveHandler is used to detach the ButtonPressed method from the Pressed event of the DesktopButton. This is especially useful when a button or event source is about to be destroyed or when you no longer want the handler to respond to events.

Similarities between AddHandler and Delegates

1. Dynamic Behavior: Both Delegates and AddHandler allow for the dynamic assignment of methods, providing more flexibility in the flow of the program.
2. Method Referencing: Both concepts use the AddressOf syntax to reference a method.
3. Flexibility: Both mechanisms are useful for reacting to specific events or functions at runtime.

Differences between AddHandler and Delegates

1. Purpose:

• Delegates are more general and are used to treat methods as variables and pass them as parameters to other methods.
• AddHandler is specifically designed for event handling. It is used to assign methods to events at runtime.

2. Target Structure:

• Delegates are strongly typed. They require an exact match between the method signature and the delegate.
• AddHandler binds methods to events, which require a predetermined signature but are dictated by the context of the object used.

3. Lifetime:

• Delegates can exist as standalone variables within any scope.
• AddHandler is tied to the event and object it is associated with. If the event or object is destroyed, the handler is no longer called.

Achieving the same functionality with both approaches

Event Handling with AddHandler

Let’s assume we have a timer event and want to specify at runtime which method should be called when the timer elapses.

' Method called by the Timer event
Sub TimerAction(sender As Timer)
  MessageBox("Timer elapsed!")
End Sub

' Dynamically assigning the event with AddHandler
Sub SetupTimer(timer As Timer)
  #If TargetMobile
    AddHandler timer.Run, AddressOf TimerAction
  #Else
    AddHandler timer.Action, AddressOf TimerAction
  #EndIf

  timer.RunMode = Timer.RunModes.Multiple
  timer.Period = 1000
End Sub

In this example, the TimerAction method is assigned to the Run/Action event of a timer at runtime.

Same Functionality with Delegates

Now, the same logic but using Delegates:

' Defining a Delegate for Timer actions
Delegate Sub TimerDelegate(sender As Timer)

' Method to be called
Sub TimerAction(sender As Timer)
  MessageBox("Timer elapsed!")
End Sub

' Assigning and invoking the method via a Delegate
Sub SetupTimerWithDelegate(timer As Timer)
  Var d As TimerDelegate = AddressOf TimerAction

  #If TargetMobile
    AddHandler timer.Run, d
  #Else
    AddHandler timer.Action, d
  #EndIf

  timer.RunMode = Timer.RunModes.Multiple
  timer.Period = 1000
End Sub

In this case, a Delegate is used to reference the same TimerAction method, but the structure remains nearly identical.

AddHandler and Delegates both provide ways to dynamically handle methods at runtime in Xojo. While Delegates are more flexible and general-purpose, AddHandler is specifically designed for dynamic event handling. Both mechanisms are useful depending on the use case. The main difference lies in how they are used and their target structure: Delegates are strongly typed and can be used anywhere in the code, whereas AddHandler is used to link methods to events dynamically.

Additionally, when using AddHandler, it is crucial to remember to use RemoveHandler to properly unbind event handlers when they are no longer needed. Failing to do so can lead to performance issues, memory leaks, or unintended behavior, especially when dealing with dynamic or temporary objects.

By combining these two techniques, you can make Xojo programs more flexible and dynamic.

Happy Coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

But what is a Delegate? We can define it as a data type definition for a method (or function) signature. That is: when you define a new delegate type you need to provide it with a concrete method or function signature. And here is where everything begins.

Once you’ve defined the new Delegate type, you can use it in your code as you would with any other data type. So, for example, you can add a property to any object (Windows, WebPage, iOSView, Class, subclass…) and define its type as the just-created Delegate type.

That means that during your app’s code execution, you can change, for example, the Delegate property value so it stores ANY method or function matching the Delegate signature and then, you can invoke it! The main point here is that, through the use of Delegates, you can dynamically change the code to execute.

Let’s see how it works through a simple example, randomly drawing to a Graphic class instance using that code will work with any graphic instance you pass along as parameter.

Delegate Creation

Of course, the first step is defining our Delegate data type. In a new Desktop project, select Insert > Delegate, and use the Inspector Panel to change its values to:

• Delegate Name: FigureDelegate
• Parameters: g as Graphics

Voilà! We have created a new data type that can point to any method matching that signature.

Using the Delegate Type

As you do with any of the standard data types or your created classes, you can create new variables or properties whose data type is our delegate type. For example, add a new property to the Window1 item and change its definition in the Panel Inspector so it reads:

• Name: Delegates()
• Type: FigureDelegate

Our Delegate property will be an Array storing FigureDelegates values.

Creating Matching Methods

Now let’s add a few methods matching our Delegate signature, so we can add them as values to our Delegates() Array.

The first one will randomly draw a line in the received Graphics context, as parameter. So, add a new method to Window1 and use the Inspector panel to change its values to:

• MethodName: DrawLine
• Parameters: g as Graphics

And write the following code in the associated Code Editor:

g.ClearRectangle(0,0,g.Width,g.Height)

Var rd As New random
Var x, y, w, h As Double

g.PenSize = 2
g.DrawingColor = RGB(rd.InRange(0,255), rd.InRange(0,255), rd.InRange(0,255))

x = rd.InRange(0, g.Width)
y = rd.InRange(0, g.Height)
w = rd.InRange(0, g.Width)
h = rd.InRange(0, g.Height)

g.drawline(x,y,w,h)

Our second method will draw Ovals; so, add a new method to the Window1 item and change its values to read:

• Method Name: DrawOval
• Parameters: g as Graphics

And write the following code in the associated Code Editor:

g.ClearRectangle(0,0,g.Width,g.Height)

Var rd As New random
Var x, y, w, h As Double

g.PenSize = 2
g.DrawingColor = rgb(rd.InRange(0,255), rd.InRange(0,255), rd.InRange(0,255))

Var widthAvail As Integer
Var heightAvail As Integer

x = rd.InRange(0, g.Width)
y = rd.InRange(0, g.Height)
widthAvail = g.Width - x
heightAvail = g.Height - y
w = rd.InRange(0, widthAvail)
h = rd.InRange(0, heightAvail)
g.DrawOval(x,y,w,h)

Next, add a third method. This one will draw a string. Once added to the Window1 item, use the Inspector Panel to change its values to:

• Method Name: DrawText
• Parameters: g as Graphics

And put the following snippet of code in the associated Code Editor:

g.ClearRectangle(0,0,g.Width,g.Height)

Static t As Text = "Hello World!"
Var tc As Double = g.TextWidth(t)/2

g.DrawText(t, g.Width/2-tc, g.Height/2-g.TextHeight/2)

Adding Methods to the Delegates() type

We told that a Delegate data type points to a Method or Function; but, how can we get that value? Really simple! Xojo provides the AddressOf operator that gives us the memory address where the method “lives”.

Add the Open Event Handler to the Window1 item and add the following code to the associated Code Editor:

Image = New Picture(ImageWell1.Width, ImageWell1.Height, 32)
Delegates.AddRow(AddressOf DrawLine)
Delegates.AddRow(AddressOf DrawOval)
Delegates.AddRow(AddressOf DrawText)

Adding a Picture Instance

We will need a Graphic context to paint in. For that we will add a new Property to our Window1 item, using the Inspector Panel to change its values to:

• Name: Image
• Type: Picture

Layout the User Interface

Now let’s take care of the user interface, so we can see how everything works.

Select Window1 to bring in the Layout Editor for the default application window. Then, add an ImageWell and a PushButton control from the Library to the Layout Editor. Change their positions and the ImageWell size so they matche the following screenshot:

Finally, add the Action Event Handler to the just added PushButton and write the following snippet of code in the associated Code Editor:

Var rd As New Random
Var d As FigureDelegate

d = Delegates( rd.InRange(0, Delegates.LastRowIndex) )

d.Invoke( image.Graphics )

ImageWell1.Image = Image

As you can see, we defined a new FigureDelegate variable and assigned it a random value from our Delegates Array. Then, we only need to call the method (or function) pointed by a Delegate data type using the Invoke method on it. Run the example app and see how it behaves.

As you can see, using this technique you could use the same methods on, for example, any picture instance.