The goal wasn’t to add new features but to explore how applying thoughtful UI design principles can significantly enhance the look and feel of an application, making it more visually appealing and cohesive.

Here are some of the key aspects of the UI revamp:

• Design System Foundation: I started by establishing a basic design system. This involved defining core visual elements to ensure consistency across the entire application interface.
• Typography Definition: Specific styles were defined for how titles and standard text should appear. This helps create a clear visual hierarchy and improves readability.
• Consistent Color Palette: A specific set of colors (Light & Dark mode) was chosen and implemented throughout the project, contributing to a unified and more polished look.
• Refined ListBox Appearance: The standard DesktopListBox control received some visual tweaks to better align with the overall updated aesthetic.

The aim was to demonstrate how focusing on UI details can elevate even a simple example application.

Here’s a glimpse of the revamped ToDo app:

You can find the complete source code for this UI-enhanced ToDo app project on GitHub.

Stay tuned for more exciting projects as we continue our Year of Code 2025 journey!

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

Year of Code Project

• Year of Code: Kickoff
• January Project: Desktop Apps | Forum Discussion
• February Project: Database Apps | Forum Discussion
• March Project: Web Apps | Forum Discussion
• April Project: User Interface | Forum Discussion
• May Project: Mobile Apps | Forum Discussion
• June Project: Code Sharing | Forum Discussion
• July Project: Charting | Forum Discussion
• August Project: Console Apps | Forum Discussion
• September Project: Games | Forum Discussion
• October Project: Multi-Platform | Forum Discussion
• November Project: PDF | Forum Discussion

How to Play:

Each month we’ll announce a new theme and share an example project of our own. Share your projects to the Xojo Forum thread for that month via GitHub (all the links you need are posted above ↑ ). Learn how to use Xojo and GitHub.

The Prizes:

Monthly winners get $100 at the Xojo store. Every month you submit a project is another chance to win the grand prize. The grand prize is $250 cash plus a Xojo Pro license and a year of GraffitiSuite and will be announce in December. Learn more about the prizes.

This control is available in the Xojo Library panel and works similarly to iOSMobileUserControl: drag it onto a layout and implement the CreateView event.

Declare Function Button Lib "Kotlin" Alias "android.widget.Button(context as android.content.Context)" (context As Ptr) As Ptr

Var bp As Ptr = Button(App.AndroidContextHandle)

Return bp

The above code uses a Declare to create a native Button and returns it so that it can be displayed in a layout.

By using AndroidMobileUserControl and Declares to access the Android UI library, you can create your own UI controls. I look forward to seeing what the community creates!

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

GraffitiSuite is a series of user interface components for Xojo developers. With a powerful data grid component for web, an extensive WYSIWYG HTML content editor, and beautiful animated in-window modal popups for Desktop, GraffitiSuite classes have helped people make stunning UIs for their Xojo-made apps since 2003. Anthony Cyphers, GraffitiSuite’s founder, is a well-known name in the Xojo community and a Xojo MVP; and he volunteered to be our first Spotlight On guest. GraffitiSuite is offering 10% off this month only! Use coupon code SPOTGS10 in June go get 10% off GraffitiSuite.

10 Questions with Anthony Cyphers of GraffitiSuite

Mac, Windows or Linux?

Mac, primarily, but I’m comfortable pretty much anywhere since I tend to have a set OS for specific things. macOS for work, Windows for play, Linux for servers. I keep multiple machines for each hanging around here.

What do you wish more people would ask you about when it comes to GraffitiSuite?

I wish people would show me their project and ask how GraffitiSuite can help them more.

How would you explain your most recent project to a 5 year old?

I make pretty things that help people use computers.

What’s next on your Learn Next list?

I’ve been deep in TypeScript for the last six months — and enjoying it — expanding from my JavaScript skills. The plan is to continue that journey and use it to augment Xojo Web as much as I can. This means rewriting some Xojo Web components with more modern, useable, performant and attractive controls.

When do you think of solutions for big bugs?

Usually when I’m trying (and failing) to sleep or when watching something on TV that I’m really not paying any attention to.

What programming moments made you think “Wow, I love my job so much.”

That feeling of triumph when you spend an inordinate amount of time working on an idea without doing any actual testing, then you hit “Run” and it just works. As though the stars aligned in that moment to say “Yeah, you can have this one, but the next one will be harder” — and it usually is.

What’s something that has surprised you about coding in the last 10 years?

Meh. Not much.

What’s a cool piece of software more people should know about?

The obvious answer would be Xojo, but I’m also very impressed with a lot of software that I use. And, in keeping with the Xojo theme:

• Version Tracker from Tim Parnell immediately springs to mind as an indispensable part of my toolkit.
• Apple Profile Triage from Greg O’Lone has saved me from some headaches.
• Beauty Shot by Ricardo Cruz is wonderful for tweaking screenshots.

What’s the coolest thing you worked on recently?

I’d have to say it’s my web application firewall (WAF) for Xojo Web called GraffitiFirewall. I spent some time reading white papers, tutorials, specs, and just playing with other implementations. I’m really happy with how it’s turned out and excited to add more features over time that may help protect Xojo users’ web apps. I work on a lot in a given week, both new and old stuff, but this one feels right.

Music or no music while coding?

Doesn’t matter. It’s all background noise. I often stream an old TV show like The X-Files, Law & Order, The Big Bang Theory, or Adventures of the Gummi Bears.

Thank you to Anthony Cyphers for answering our questions and for being a rock in the Xojo community. If you want to learn more about what GraffitiSuite can do for you, visit graffitisuite.com. And take 10% off in June with coupon code SPOTGS10.

Anthony G. Cyphers is the Lead Developer and Sole Proprietor of GraffitiSuite Solutions, and has been providing custom Xojo components and contract development since 2003 and is a Xojo MVP.

And what do we mean by the transitory character of Popover windows? Well, and here comes one of the first differences from Modal windows. When a Popover is visible and the user clicks or taps on any other element of the graphical interface not contained in the Popover itself it will close, hence transitory. So, you don’t have to include the typical “Close window” button in a Popover (though you can), since it will close when the user clicks outside of it, i.e. when the Popover loses focus.

Where are the Popover Window Contents?

Where do you define the content displayed in a Popover window? While in your Web app, you can do it on any Container control added to the project. In the case of Desktop and iOS apps, you can do it on either the designs of a Container Control or any Window or Screen added to the project.

For example, here you can see that the content shown as a Popover in the previous screenshot is actually that of a Window (Window2) added to the project:

This introduces additional flexibility allowing your app’s logic to decide when to display a Window or Container instance as you have been doing until now, or display it as a Popover.

Showing a Popover

Displaying a Popover is very straightforward, whether it is created from a Container or a Window, the method is the same:

DesktopContainer.ShowPopover(parentControl As DesktopUIControl, facing As DesktopWindow.DisplaySides = DesktopWindow.DisplaySides.Bottom, detachable As Boolean = True)

The explanation of the expected parameters is as follows:

• ParentControl: The control that will act as the parent, or on which the Popover will be pointing to.
• Facing: The direction in which the Popover will point on the parent control; by default it will appear under the parent control, but you can use any of the values available in the DesktopWindow.DisplaySides enumerator (or the iOS equivalent).
• Detachable: This value only applies to macOS Popovers, since said operating system has the ability for the user to “detach” the Popover from the parent control as long as this value is defined as True. To detach, drag the Popover with the mouse cursor.

Let’s say we have a window called Window2 and a button called MyButton. In the Pressed event of MyButton we can use the following lines of code to display Window2 as a Popover:

Var w As New Window2
w.ShowPopover(me)

And that’s all!

Platform Differences

In the previous section we already pointed out the first: macOS is the only operating system that acts on the value indicated in the Detachable parameter. But there are some other considerations to keep in mind so you don’t get caught off guard:

• Beyond the limits. Although in Windows and macOS Popovers can exceed the limits of the window on which the parent control is located, the position of the popover in Linux is restricted to the limits of the window that contains the parent control. This is the same for iOS and for Web pages.
• iPhone and iPad. When a Popover is displayed on an iPhone, it will look like a modal window; while if the same application is run on an iPad, the appearance will be the typical one expected from Popovers: the window pointing to the parent control in the indicated direction.
• On the Web. The contents of a Popover are those defined in a Container control, while on the rest of the platforms you can use both Container controls and Windows / Screens.

Why the Popover doesn’t “point” in the configured direction?

By default it will try to do so according to the value that has been set in the “facing” parameter, but if it does not find enough space on the margins of the screen, then it will be displayed on the next side of the parent control in which there is available space for display the Popover in its full width and height; This is true on macOS, Linux, Web and iOS.

Can I reuse a Popover?

No, You can not. Whether you use a Container control or a window as the source of the UI design to be displayed by the Popover, do not lose sight of the fact that the Popover is just another type of window; and therefore behaves as such. That is, once it is closed either because it has lost focus or because you have closed it explicitly through code invoking the Close method, all the displayed controls and the rest of the internal structures will be closed / invalidated, so that although the instance If a Popover is not Nil (because, for example, you keep a reference to the window or container instance used as the UI source), you will not be able to invoke the ShowPopover method again on said instance but you will have to create a new instance of the Container/ Window used as the source of the UI to be displayed by the Popover.

How can I communicate with the UI elements contained in the Popover?

You would do so just as you would do with any other type of window that you have been using so far in your Xojo projects.

Conclusion

Without a doubt, Popovers are a new way to improve the design of your apps’ user interfaces, providing a more direct relationship between the user interface elements displayed in the Popover and the “parent” control in charge of displaying it. Furthermore, since you can use any window or container you want as the source of the UI to be displayed by the Popover, you will have greater flexibility about when you want to display them in a Popover or display them using any other of the available window types or, in the case of Containers, embedding them as part of other UI elements at runtime.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

But first, what’s an Extension Method anyway?

There are situations where you want to add functionality to a Xojo Framework class. Let’s say we want to add a method to every visual web control. We know that every visual control inherits from WebUIControl. This class can’t be modified, as it’s part of the framework. One option would be subclassing each control and adding new methods… but that’s so boring…

Extension Methods are part of the Modules feature, allowing us to extend classes with methods, even if we don’t have access to their source code.

Adding SetBadge and RemoveBadge methods to every visual control

The first thing you need is a Module. Press on the Add button from the toolbar and select Module. The name of the module is up to you, I’ll be using WebExtensions in this example.

Now add a new method into that module, called “SetBadge”. Then, in the inspector, ensure its visibility is set to Global, instead of Public or Protected.

The magic happens in the first parameter of this method. “Extends” is the reserved keyword for this feature, for example:

Extends myInstance As ExampleClass

Above method would be extending an imaginary class called “ExampleClass”, and its instance would be available inside that method, accessible from the variable “myInstance”.

In our case, for SetBadge, we want to use this method signature instead:

Extends control As WebUIControl, caption As String, indicator As String = "danger", top As Integer = -10, right As Integer = -10

Inside, paste the method contents:

Var classes() As String = Array("xojo-badge", "d-flex", "p-2", _ 
"border", "border-light", "bg-" + indicator) 
classes.Add(If(caption.Length < 2, "rounded-circle", "rounded-pill"))

Var styles() As String = Array("height: 21px", "font-size: 10px", _ 
"align-items: center", "color: white", "position: absolute", _ 
"top: " + top.ToString + "px", "right: " + Right.ToString + "px", _ 
"z-index: 10")

If caption = "" Or caption = " " Then caption = "&nbsp;"
Var html As String = "<span class=""" + String.FromArray(classes) + _
""" style=""" + String.FromArray(styles, ";") + """>" + caption + "</span>"

Var js() As String
js.Add("$('#" + control.ControlID + " .xojo-badge').remove();") 
js.Add("$('#" + control.ControlID + "').append(`" + html + "`);")
control.ExecuteJavaScript(String.FromArray(js))

What this little sorcery does is appending a new HTML layer into our control, using some Bootstrap’s component CSS classes. Did you notice we are using “control” instead of “Self”? It matches the “control” variable from the method definition.

Add another Extension Method for removing the badges, called “RemoveBadge”.

The method definition reads like this:

Extends control As WebUIControl

The content is a bit easier this time:

Var js As String = "$('#" + control.ControlID + " .xojo-badge').remove();"
control.ExecuteJavaScript(js)

That’s it. Plumbing done.

Now, if you have a WebButton called… “AwesomeButton”, you can set its badge using this code:

AwesomeButton.SetBadge("Hello!")

And to remove it:

AwesomeButton.RemoveBadge()

You can use these badges in different scenarios. From displaying a pending notifications counter in a WebButton, to validation errors in a WebTextField.

Adjust and play with the code to meet your needs! 

You can download the example from the GitHub code repository.

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

We love to share Xojo tips and tricks! Please write us if you have something to share.

The new AddControl method on DesktopWindow and DesktopContainer accepts any DesktopUIControl instance you want to add to a window or container.

To make the new DesktopUIControl instance really visible in the target window or container, you’ll need to set some basic properties; specifically the desired width and height values for the new instance control and also the left and top coordinate values where you expect the control to be added. These values are relative to the left/top corner of the target window/container, so a value of top = 0 and left = 0 means to add the control at the top/left corner of the target window itself.

In order to see how this works, this example creates a Desktop project that includes multiple DesktopButton instances at runtime while also removing them from the target DesktopContainer (calling the Close method on the instance to do that). Plus we’ll make them adjust as the size of the Container changes like you see in this example below.

1. Creating the Base Container

Open Xojo and create a new Desktop project. Double click on the Container in the Library so it is added to the Navigator in the IDE. Use the Inspector panel to change the following properties:

• Name: BaseContainer

Add a new property to the BaseContainer subclass in the Navigator (use the contextual menu for that), setting the following values in the Inspector panel:

• Name: Controls()
• Type: DesktopUIControl
• Scope: Public

2. Adding New Controls to the BaseContainer

We are going to need some Methods in the BaseContainer, starting with the one responsible for adding new DesktopButton instances. Add a new Method setting the following values in the associated Inspector Panel:

• Method Name: AddNewControl
• Scope: Public

Write the following snippet of code in the associated Code Editor for the Method:

// Setting static values for the new Button instances
// Width and Name values
Static cWidth As Integer = 40
Static cInitialName As String = "ControlName"

// Initial X and Y coordinates for the control instance
Var startX As Integer = If(Controls.Count = 0, 20, Controls(Controls.LastIndex).Left + cWidth + 20)
Var startY As Integer = If(Controls.Count = 0, 20, Controls(Controls.LastIndex).Top)

// We need to adjust the X/Y coordinates if the control
// exceeds the available BaseContainer width
If startX + cWidth > Me.Width Then
  startX = 20
  startY = startY + Controls(Controls.LastIndex).Height + 20
End If

// Creating the new DesktopButton instance to be added
// and setting the expected values so it is visible
// at the desired size and position.
Var nControl As New DesktopButton
Var idxNumber As Integer = Controls.LastIndex + 1
nControl.Name = cInitialName + idxNumber.ToString
nControl.Caption = idxNumber.ToString
nControl.Left = startX
nControl.Top = startY
nControl.Width = cWidth

// On macOS we get the default height for free
// this is not the case on Windows
#If TargetWindows Then
  nControl.Height = 22
#EndIf

// We set the method to be called by the instance
// when the user presses the button
// so we can catch it and forward it to the
// BaseControl instance
AddHandler nControl.Pressed, AddressOf ControlActionCallback

// Adding the new control instance to the array
controls.Add(nControl)

// …and adding it to the BaseContainer
// calling the new AddControl method for that
Me.AddControl(nControl)

As you can see, we are using the AddHandler method to substitute the original Event fired by the control with our own Method; so let’s create that. Add a new Method to BaseContainer using the following values in the Inspector Panel:

• Name: ControlActionCallback
• Parameters: tControl As DesktopUIControl
• Scope: Public

And write this line of code in the associated Code Editor:

RaiseEvent ControlPressed(tControl)

3. Removing Controls From the BaseContainer

The third and last method we need to add to our BaseContainer subclass is the one responsible of removing the last added control; add a new method to the BaseContainer subclass using the following values:

• Method Name: RemoveLastControl
• Scope: Public

And write the following snippet of code in the associated Code Editor for the Method:

If Controls.LastIndex <> -1 Then

  Var tControl As DesktopUIControl = Controls.Pop

  // We need to remove the callback method from the original
  // Pressed event on the instance
  RemoveHandler DesktopButton(tControl).Pressed, AddressOf ControlActionCallback

  // Closing the control instance so it is removed from the
  // containing BaseControl
  tControl.Close

End If

4. Forwarding Events

Because we are forwarding the received Pressed event from the DesktopButton to the ControlActionCallback method, and it is raising the ControlPressed method passing along the received instance, we need to define that Event in our BaseContainer subclass using the following values in the associated Inspector Panel:

• Event Name: ControlPressed
• Parameters: tControl As DesktopUIControl

5. Reacting to Resizing

We want our BaseContainer to react to changes in its width and/or height, so it has the chance to change the layout (position) of the controls added to it. With the BaseContainer selected in the Navigator, add the Resizing Event and type the following code in the associated Code Editor:

#Pragma DisableBackgroundTasks
#Pragma DisableBoundsChecking

Var startX As Integer = 20
Var startY As Integer = 20

Var lastIndex As Integer = Controls.LastIndex
Var tControl As DesktopUIControl

For n As Integer = 0 To lastIndex

  tControl = Controls(n)

  If n <> 0 Then startX = Controls(n - 1).Left + Controls(n - 1).Width + 20

  If startX > Me.Width - tControl.Width Then
    startx = 20
    If n <> 0 Then startY = startY + tControl.Height + 20
  End If

  tControl.Left = startX
  tControl.top = startY

Next n

6. Designing the User Interface

Select the Window1 window in the Navigator so it is displayed in the Layout Editor. Next, drag a Button from the Library and place it at the top/left corner leaving the expected margins recommended by the Layout Guides.

With the just added button still selected, change the following values in the associated Inspector Panel:

• Name: AddControlButton
• Caption: “Add Control”

Add the Pressed Event to the button and type the following line of code in the associated Code Editor:

BaseContainer1.AddNewControl

Add a second button and place it just below the previous one. Use the associated Inspector Panel to set the following values:

• Name: RemoveControlButton
• Locking: Left and Top locks closed
• Caption: “Remove Control”

Use the resizing handlers on the control to make its width enough to display the Caption properly.

Add the Pressed Event to just added button and type the following line of code in the associated Code Editor:

BaseContainer1.RemoveLastControl

Add a Label from the Library and place it to the right of the first button. Use the Inspector Panel to set the following values:

• Locking: Left and Top locks closed
• Text: “Control Pressed:”

Use the resizing handlers on the control to make its width enough to display the Text properly.

Add a second Label and place it to the right of the previous one, using the Inspector Panel to set the following values:

• Name: ControlPressedName
• Locking: Left and Top locks closed
• Text: “”

Finally, drag the BaseContainer from the Navigator and place it below the second button. Use the resizing handlers on the control to make it width and tall enough to fill all the remaining area on the window. The final layout should look more or less like this:

Use the Inspector Panel to set the following values:

• Locking: left, top, right and bottom clocks closed (locked)

With the BaseContainer1 instance selected in the Layout Editor, add the ControlPressed Event to it and write the following line of code in the associated Code Editor:

ControlPressedName.Text = tControl.name

7. Running the App

All set! Run the App, press the “Add Control” button to add as many buttons you want to the BaseContainer1 control, and press the “Remove Control” button to remove controls. Try to resize the window and you’ll see how the controls change their position as needed.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

The first beta of Windows 11 is scheduled to be released next week and we will be testing the Xojo Windows framework on it. We will have more blog posts as more information becomes available about the next generation of Windows.

Obviously, adding the same bunch of controls again and again on each window is not the best solution; even less so when we consider the need to add the exact same code in each of these controls.

The ContainerControl is your best bet to avoid these repetitive tasks. The ContainerControl is a component half way between the available controls in the Library (inherited from the Control class) and a Window. If you look at the properties, methods and events offered by the ContainerControl you’ll find many of these are the same ones available in the Window class.

Download the Example Project for this tutorial

ContainerControl Layout

Adding other controls to a ContainerControl couldn’t be simpler. Start by adding a new ContainerControl from the Library to the Navigator (by default, it will be named ContainerControl1), select it in the Navigator to access the Layout Editor. You can use the Inspector Panel to setup the properties. Please note, control’s locks will act on the top, left, right and bottom sides of the ContainerControl they are embedded on; as opposed to using the locks on the ContainerControl itself which locks the position of the container over the top, left, right and bottom sides of the Window where the container is used.

Using ContainerControls in the Window Layout

Now that the layout of the ContainerControl is done, it’s time to add it to the Windows or Panels. Select a Window to access the associated Layout Editor and then drag the ContainerControl from the Navigator to the desired position onto the window frame displayed on the Layout Editor. Once done, that instance will be added under the Controls section for the Window in the Navigator (by default it will be named ContainerControl11 because is an instance from ContainerControl1).

Something interesting to observe is that once you add the container to the Window, you won’t be able to change the position or behavior of the embedded controls in the container from the Window Layout Editor. The controls embedded in the container are displayed as “disabled”.

Select the item ContainerControl1 in the Navigator to change the layout, add new UI controls, and change the position, size or behavior.

Since we only can add Event Handlers to the controls added to ContainerControl1, but not when those containers are added to a window or panel, how do you “communicate” with the windows using these containers? There are several approaches to achieve this. In this example, set the Scope to Public so the Window can access the controls added to a ContainerControl.

If we had added a ListBox control (default name ListBox1) to our ContainerControl1, setting its Scope property as Public in the Inspector Panel, it can be accessed using the usual dot notation. For example, from the Open Event Handler added to the Window1 item:

Me.ContainerControl11.ListBox1.AddRow("New Item")

This solves one of the communication problems; but, how can the controls embedded in a container “communicate” with the Window containing the container? That is, how do we send the value of the selected row in the ListBox1 control to the Window?

Let’s think about that scenario for a moment: the Window Window1 knows the name of the ContainerControl added to it (ContainerControl11), and also the names of the controls added to that container because their Scope has been set to Public. On the other hand, the controls know about the ContainerControl they are embedded in, but they don’t know in advance the name of the Window where such ContainerControls can be added as part of the layout. In addition, the ContainerControl knows the name of the controls added to it, but it doesn’t know in advance the name of the Window or Panels where the container can be displayed. Moreover, it is possible to add ContainerControls to a Window or Panel layout in Design Mode (in the IDE), as well as at runtime!

Considering all of this, the simple solution to communicate between the controls added to a ContainerControl and the Window or Windows that will be using that container is by adding new methods and new Event Definitions on that ContainerControl (in this example, the one named ContainerControl1). There are other techniques, but we are going to use this one in this tutorial.

Continuing with our example,  add a new method to ContainerControl1 using the following method signature:

RowSelected(value As String)

Next, with ContainerControl1 still selected in the Navigator, choose the Insert > Event Definition option in order to create a Event using the following signature:

RowSelected(value As String)

Click on the method added previously to access the associated Code Editor and type the following line of code:

RaiseEvent RowSelected(value)

The method will simply raise the defined event passing along the received value as the argument.

Now, select the ListBox1 item on the ContainerControl1 item, and add the Changed Event Handler. This is the event raised every time the user changes the selected row in the ListBox. Type the following code in the associated Code Editor:

If Me.SelectedRowIndex <> -1 Then
    Self.RowSelected(Me.SelectedRowValue)
End if

Add the Open event to the ListBox1 item, type the following code in the associated Code Editor:

For n As Integer = 0 To 10
    Me.AddRow(n.ToString)
Next

Now, add the defined event in ContainerControl1 to the ContainerControl11 instance added to the Window1 layout. Select that item and choose the Add > Event Handler option. Choose the SelectedRow event handler and confirm the selection clicking the “OK” button.

Type the following line of code in the associated Code Editor:

MessageBox("Selected value: " + value)

Of course, you can do something more useful with the received value; but this is useful enough to show how the values can be sent from the ListBox control to any window where the container can be used.

Subclassing ContainerControl

Some projects may require using several ContainerControls, and many of them may be using a ListBox. As it is when using any other class, it would be great to have both the SelectedRow method and the SelectedRow Event Definition in their own ContainerControl subclass, and they are available by default to any ContainerControl added to the project and embedding a ListBox. The good news is that it is also possible to create a subclass for a ContainerControl, as it is explained in the User Guide.

Add a new Class to the project and use the Inspector Panel to change its name to MyContainerClass and the Super field to ContainerControl.

Next, select the SelectedRow method and the Event Definition with the same name in ControlContainer1, cut them (Edit > Cut), select MyContainerClass and paste them (Edit > Paste). Both the method and the event definition are now available under MyContainerClass.

Select ContainerControl1 in the Navigator and use the Inspector Panel to change its Super field to MyContainerClass. Add a second ContainerControl from the Library to the Navigator (by default it will be named ContainerControl2). With the new item selected in the Navigator, use the Inspector Panel to change its Super field to MyContainerClass. Add the ListBox control from the Library to the layout of the new container and type the following code in the Open event for the ListBox1 item:

For n As Integer = 0 To 10
    me.AddRow(n.ToString)
Next

Add the Changed event to ListBox1 and type the following code:

If Me.SelectedRowIndex <> -1 Then
    Self.SelectedRow(Me.SelectedRowValue)
End If

Next, add the second container ContainerControl2 to the project window Window1. The layout could be similar to that of this screenshot:

Select the ContainerControl21 item under Window1 > Controls and add the SelectedRow event handler. Add this line of code to display the received value in a message box:

MessageBox("Selected value: " + value)

As you can see, both ContainerControl1 and ContainerControl21 do not include the SelectedRow method. These are inherited from their super class: MyContainerClass.

Adding ContainerControls at Runtime

Xojo also lets you add ContainerControls at runtime, something that is really interesting and makes Xojo apps flexible and powerful. Let’s do that in a simple example:

Select the Window1 item in the Navigator and delete the ContainerControl11 and ContainerControl21 items. With Window1 still selected, add a new property using the following values in the Inspector Panel:

• Name: Containers()
• Type: MyContainerClass

Add the Open event to Window1, type the following code in the associated Code Editor:

Var leftContainer As New ContainerControl1

leftContainer.Width = 200
leftContainer.LockTop = True
leftContainer.LockRight = False
leftContainer.LockBottom = False
leftContainer.LockLeft = True

leftContainer.EmbedWithin(Me, 20, 20)

Containers.Add(leftContainer)

Var rightContainer As New ContainerControl2

rightContainer.Width = 200
rightContainer.LockLeft = True
rightContainer.LockTop = True
rightContainer.LockBottom = True
rightContainer.LockRight = True
rightContainer.EmbedWithin(Me, Me.Width - 20 - rightContainer.Width, 20)

Containers.Add(rightContainer)

Run the app, change the window size and you’ll notice how the container at the right side adjusts its height and width to match the changes made in the window while the container at the left side keeps its original position.

Try to change the selected row in any of the ListBoxes. Nothing happens! As you may remember, in order to “forward” the selected row value from the ListBox to the window we needed to add the SelectedRow event handler. This is something we can’t do when adding new container instances at runtime. In order to do that we need to use the AddHandler keyword. This lets us redirect an event handler to a delegated method. Quit the app to return to the IDE and, with Window1 still selected in the Navigator, add a new method using the following signature:

ListBoxSelectedRow(item As MyContainerClass, value As String)

Notice that the first parameter will contain a reference to the instance of the MyContainerClass raising the event, while the second parameter will contain the value itself.

The only thing left is to associate the event name with the memory address of the method that will handle it for each of the Container instances added at runtime. Again, select the Open event tied to the Window1 item and change its code like so:

Var leftContainer As New ContainerControl1

leftContainer.Width = 200
leftContainer.LockTop = True
leftContainer.LockRight = False
leftContainer.LockBottom = False
leftContainer.LockLeft = true

AddHandler leftContainer.SelectedRow, WeakAddressOf ListBoxSelectedRow

leftContainer.EmbedWithin(Me, 20, 20)

Containers.Add(leftContainer)

Var rightContainer As New ContainerControl2

AddHandler rightContainer.SelectedRow, WeakAddressOf ListBoxSelectedRow

rightContainer.Width = 200
rightContainer.LockLeft = True
rightContainer.LockTop = True
rightContainer.LockBottom = True
rightContainer.LockRight = True
rightContainer.EmbedWithin(Me, Me.Width - 20 - rightContainer.Width, 20)

Containers.Add(rightContainer)

The lines of code really are interesting:

AddHandler leftContainer.SelectedRow, WeakAddressOf ListBoxSelectedRow
AddHandler rightContainer.SelectedRow, WeakAddressOf ListBoxSelectedRow

As you can see, through AddHandler we are instructing the SelectedRow event from every container instance to be handled by the ListBoxSelectedRow method added to Window1.

On the other hand, WeakAddressOf is a Xojo programming language operator allowing us to get a “weak” reference to the memory address where the ListboxSelectedRow is found so it can be invoked.

Summary

Through this tutorial we practiced some of the basics of using ContainerControls in Desktop projects: adding them to the project, using them at design time, how to forward values from the container’s controls to the window where these can be added, how to create a ContainerControl subclass that shares its method and events with any ContainerControl subclassed from it, how to add new ContainerControl instances to a window at runtime, and also how to delegate the execution of a event so it can be handled by a window method.

Questions? Ask me on Twitter @XojoES or on the Xojo Forum.

With Xojo 2019R2, everything related to updating the UI is much simpler thanks to the new UserInterfaceUpdate event in the Thread class. This provides, as an Array of Dictionaries, all the values we need to pass along from the Run event of the running Thread.

In order to add new values to these dictionaries, we only need to call the AddUserInterfaceUpdate method, providing as parameter a Pair.

The first (left) value of this pair will be the one acting as the Key for the Dictionary, while the second value of the pair (right) will be the value itself we want to forward to the main thread in order to update our user interface.

In addition, the overloaded AddUserInterfaceUpdate method also accepts a Dictionary as a parameter.

The two ways we can use the new thread class are the same available in previous releases:

• Draging and dropping an object from the Library panel to the Tray in the Window Layout, so the IDE creates a new instance that we can use to implement the Run and, now, also the UserInterfaceUpdate events. The Run event is the one intended to run the code usually associated with a long task, so it doesn’t freeze the responsiveness of the rest of the app (mainly the user interaction or user interface refreshes). The UserInterfaceUpdate event is the new Event whose parameter will provide all the data we are interested in previously added from the Run event calling the AddUserInterfaceUpdate method. That is: every time we call the AddUserInterfaceUpdate method, the Thread will fire its UserInterfaceUpdate event. Think about this as a bridge between our Thread and the main app thread.
• The second approach is the one we use when creating the Thread instances from code. In this case, the solution is simple and is the one we usually use to delegate the code to execute in the Action event of the Timer class. AddHandler sets the method we want to execute in substitution of the UserInterfaceUpdate event handler of a Thread instance. As usual, make sure that the delegated method has the right signature: receiving a Thread object as its first parameter and the data we are interested in as the second parameter.

The example project available here, shows the implementation of both cases, how the Threads sends the data to update the user interface and how such data is received and accessed in the corresponding Thread Event Handler or delegated Method.

As you can see in the example, the user interface is responsive to the user interaction while the two threads do their work.

Easier and faster!

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, GuancheID, AXControlGrid, AXImageCanvas, Markdown Parser for Xojo, and HTMLColorizer for Xojo among others.

Sometimes, subclassing the available controls is the answer to add specific behaviors you need. But what happen when none of the controls offer what you need, whether visually or functionally? The answer is the Canvas class (for Desktop projects), WebCanvas class (for Web projects) and iOSCanvas class for iPhone and iPad devices. But how do you create your own UI controls from scratch? Read on to learn…

Before starting with this basic tutorial about customized UI controls, there is much more to take into consideration about providing the same behavior on your designed controls for multiplatform deployments. For example, in the case of desktop projects, we should add to the mix some things like HiDPI / Retina detection and adaptation on the fly (specially in the case of Windows deployment, with multiple dpi / Windows OS version combinations), and Dark Mode support for macOS. A well as other performance hints and differences when it’s about doing desktop multiplatform layouts; for example, when to set the Transparent or DoubleBuffer properties to True or not.

As the name implies, the Canvas control acts like a painting canvas and you can set its look for all the supported states based on the available events. This is done through the Paint Event and all the Graphic classes availables in the Framework. In fact, the Paint event provides as a parameter the graphical context (canvas height and width) you can paint on. In addition, you can combine these graphic classes (or completely substitute them) with any prepared Picture of your choice as the customize control background (ImageSet recommended, so it supports all the needed resolutions based on display dpi). In addition, and as you can do with the drawing via the Graphic class and functions, you can choose to use a different Picture as the control background based on several events, for example, when the mouse pointer is entering or exiting the control limits in a Desktop or Web app, or as response to the user clicking on it.

Canvas: A matter of Events

The Canvas class provides all the needed Events you probably would want to implement in order to react to the user interaction. These are listed and described in the available documentation online and as part of the Xojo IDE interactive Help.

While you can drag and drop a Canvas instance directly to your project layout window or view, implementing and writing the code associated with  any of the available Events, the recommended way to go is to create your own subclass taking as its parent the Canvas class. This way, you can implement and fine-tune every aspect that makes you control unique and, most importantly, re-use your customized UI controls as many times you want both in current and future projects (or even offer them to the Xojo community or sell them to other developers!).

As you probably already know, in an OOP programming language, subclassing is the method to get a specialized behavior from an existing Class: We get for free all the available properties, methods and events from the parent (and all its parent hierarchy), including also the code executed in the Paint event to truly paint or provide its look on screen; so we just need to implement the specific behavior and/or control drawing/painting we need over these.

This is also the way to go when you are in the inital stages of designing your own customized UI control: will you need to create even more specialized behaviors based on a “parent” or base customized control? Maybe variations on the behavior? In cases like these, you should define your UI control base class at the bare-minimum set of painting, behavior (events and methods) and properties that will be shared from all the future UI Controls inherited from your base/parent UI Control class. (i.e: more specialized or with behavior variations).

Creating a subclass in Xojo is truly simple: just drag and drop the Canvas icon from the Library to the Navigator (the leftmost column in the Xojo IDE), or choose Insert > Class from the Insert menu.

Points vs Pixels: HiDPI and Retina

Once you have added the new Class to your project, select it, go to the Inspector and set the name you want to use for your new Class (using a “company” or personal prefix it’s always a good idea to avoid collision with other existing or future classes in the Xojo Framework, or when using third party classes). Then, in the Super field of the Inspector Panel, type Canvas and confirm the entry. You’ll see how your class icon changes to the one that uniquely identifies Canvas based classes and instances. The most important thing: your new subclass will have all the properties, events and methods you may expect from a Canvas.

This will be the base class in our short tutorial for creating a customized button that will change its associated image (picture) when the mouse pointer is inside the button area, outside the button bounds or when the user click on the control. In the last case, the button will change both the image and its internal state represented by a property as a Boolean value (named Status).

As our customized UI control will not draw itself via the Paint event, we will need to design the images so these precisely fit in the size we want to use for our button. In this example a size of 32 x 32 points.

In general, when designing images to use in our Xojo projects we need to change our mindset from thinking in pixels to points. That’s because Xojo apps do support HiDPI on Windows/Linux and Retina on macOS; that is: hi-def graphics. Thus, it’s important to use a design tool that simplifies the process. Personally, I use the vectorial app Sktech on macOS because it automates the 2x creation of the final images. (Remember that HiDPI/Retina is enabled by default in the Building Settings on every new Desktop project.)

How do you support HiDPI/Retina if you want to draw the control look on the fly? Avoid the use of pixels in your calculations or when setting the values of the existing Graphic class properties, and use Points instead. If you really need to access the Pixels values underneath, then you can resort to the RGBSurface class (if available) and make use of the ScaleFactorChanged event available on the Canvas class. This way, your class will be notified on every change between displays with or withour Retina/HiDPI support.

Good rule of thumb: do all your control drawing inside the Paint event! And, when you need to update or redraw it (maybe as consequence of some change in the app behavior, or from the change made in other UI control), invoke the method Invalidate instead of Refresh. In general, this will speed up the drawing and, thus, the main app performance.

If you use an existing Event… Define the Event again

As our customized class makes use of the Open, MouseEnter, MouseExit and MouseDown Events, we need to make sure we define these events again to the class, so they are also available for the developer using our canvas-based UI subclass. After all, it’s very probable he needs or wants to add extra code on top of ours! This is something we can do choosing Add to "class_name" > Event definition when our subclass icon is selected in the Navigation Browser.

Thus, once we have created the same events (using the same parameters and returning the same kind of Type values as the original ones), we need to make sure we call them; usually as the last line of code for the already used Event. For example, this is the code for our implementation of the MouseDown event in our Canvas subclass:

me.Backdrop = if(me.Status = false, ShellRunSelected, ShellRun)
me.Status = not me.Status
return RaiseEvent MouseDown(X, Y)

Note how, in this case, our implementation of the MouseDown event returns the value returned by the consumer of our subclass instances, called with the RaiseEvent statement. Just remember that returning the True value from this event means that such events will not be propagated further along the Events Chain.

Putting it all Together

With this information at hand, and the basic concepts explained, this video (in Spanish) shows how you can join all the needed pieces: pictures, events, definition of already consumed events by the subclass; creating a new very basic control from scratch. Obviously, from this point on, you can find in the available documentation all the information needed to create more complex UI controls based on the Canvas class (WebCanvas or iOSCanvas). The possibilities are limitless!

Other useful topics:

• User Guide: Desktop Canvas
• Canvas, Graphics classes
• User Guide: iOS Canvas
• User Guide: Web Canvas

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

Before we put our hands on it, let’s make some things clear about the Control Set:

• You can use this feature to dynamically create any kind of control based on the RectControl class.
• You can use Control Sets on Desktop and Web projects (although web projects cannot use Control Sets to dynamically create controls at runtime).
• You cannot create Control Sets for Container Controls.
• The Control Sets may seem like Arrays, because you will use an index to refer every instance from the same Control Set, but they are not. So, don’t think about them in that way.
• All of the instances of the Control Set will share the same Event Handlers, so you will have to use the additional index argument, passed to the Event Handler, in order to identify over which instance are you handling.

But, how can we create one of these Control Set after all? Well, we just need to put any control we want to use as a clonation template on the Window, even if it is placed outside the visible limits of the Window itself. Then, and with the control still selected, you just have to push on the attributes button (the one with the image of a gearwheel) on the Inspector, selecting the New Control Set option from the Member Of entry under the Control Set Section.

Tip: If you change the name of the Control used to create a Control Set, then you will have to recreate the Control Set, so rename the template Control in the first place!

Once you have created the new Control Set, you will see that the first instance of the Control Set is assigned the index number 0; succesive instances will have their index increassed by one, both the ones you may add to the Window (not what we want to do in this case), and those created at runtime (what we want to do).

Now, probably you will want to change the Visibility Property to False on this first cloning template control, so it will not be visible to the users of the app no matter the resizing of the containing Window.

Once our cloning control is all set, it’s time to reveal all the code we will need in order to create new instances of the control at run time. Let’s indicate that we have used as cloning template Control a PushButton and that we have named it btClon. Then, we just need this to create a new instance, making it visible on the Window:

Dim newInstance as PushButton = new btClon
newInstance.visible = true

Remember that every UI component is based on (inherits from) the RectControl class, so you also can do this:

Dim newInstance as RectControl = new btClon
PushButton(newinstance).visible = true

As you can see, the difference is that in this case you have to Cast the generic RectControl instance to the PushButton class in order for you to use and access all the PushButton methods and properties from code.

Why should you use this formula, then? Well, if you are thinking about creating several Types of UI components at runtime, then you will probably prefer to create them using a more generic RectControl variable or reference (maybe a RectControl Array containing all of your dinamically created controls).

As you may expect, the new instances created from a template will have the same properties, events and methods the template control has, with the difference that it will also inherit the clone properties values. This is why once a new instance is created we need to make it visible again and you will want to change other properties too, for example the Caption and the Left and Top properties among others.

Modifying the Z axis order of the Control

We already know that every new created instance of the Control Set gets its index increased by one. What you have to know is that every new instance is above the previous one on the Z axis of the Window. I mean, if the control with the Index set to 2 partially overlays the position of the control with the Index 1, then the first one will overlay the second. What if you decide to have a control with a low index value above the others?

Currently there is no easy way we can dynamically change the Z order of a control to any desired value, but there is an easy way we can move any control to the foreground, so it can stay in front of all of them!

Let’s say that we have our cloned control with the Index 1 and want to show it in the foreground, with the highest possible value in the Z axis. All we have to do is assign it to another RectControl as its parent property value, for example the control we are using as cloning template. Once done, we will assign the Window again as the parent property value of the control. The code could be something similar to this:

btClon(2).parent = btClon(0)
btClon(2).parent = Window1 //Or Self or Me, depending where you place the code

In conclusion, as you can see, the creation of UI controls at runtime is something really easy to do in Xojo! But what if you need to dynamically add a group or layout of control at runtime? Well, in that case don’t forget about the ContainerControls!

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 and the Snippery app, among others.

*Read this post in Spanish

*Watch the video in Spanish

The first thing that went through my mind was how exactly is such an important function of a state emergency management system triggered so easily that it could be done by accident? Did a radar system show an incoming missile that was later discovered to be a mistake? No. As the Washington Post reported, the user interface for the system has a drop down menu with two items: Test Missile Alert and Missile Alert. The facts that these two options are so similarly named and that there is no confirmation dialogue for such an important command is at a minimum bad user interface design.

If I want do something as relatively innocuous as erasing all the data from my iPhone, I have to first find the feature that does this buried two levels deep in the Settings app where it’s clearly titled, “Erase All Contents and Settings.” Tapping it displays a dialog box asking me if I want to Backup Then Erase or just go ahead and Erase Now. If memory serves from the last time I did this, choosing Erase Now then reconfirms that I truly do want to erase all the contents and settings on my iPhone. That’s a lot of steps to accomplish a task that only affects one person: me. However, considering the magnitude of the result, it makes good sense that the user interface doesn’t make this very easy to do and actual makes sure you are deliberately trying to erase your phone.

Hawaii’s emergency management system does none of this. There apparently are just two menu items, one next to the other and once chosen, the computer immediately completes the task without confirmation. That’s just astonishing. What’s even worse, however, than the poor interface design on the part of whomever designed it, is that at a minimum (a) someone had to accept this poor interface design, (b) others had to use it without complaint that it could potentially cause the very situation it has caused.

The Chairman of the FCC wants an an expensive investigation. Let’s please not spend $1 million or more of the taxpayer’s hard-earned money on a $100 fix. First, these two menu items should be reduced to a single menu item entitled, “Missile Alert…” The ellipsis tells the user that before this item performs its function, a dialog will be displayed to confirm it. The dialog that appears should be on that requires deliberate actions by the user to initiate a true warning to the population of Hawaii:

In the above example dialog box notice that in order to initiate a real warning, the user will not only have to uncheck the “Internal Test Only” checkbox but also have to deliberately click the Proceed button as the Cancel button is the default.

After taking those two deliberate actions, the user is then presented with a second dialog box to confirm that requires again clicking the Proceed button, another deliberate action.

With this simple, 5 minute fix, it would be nearly impossible for someone to accidentally send out a warning when they meant to only perform an internal test.

Not all user interfaces have functions with such wide-reaching results. However, user interface guidelines for many years now have said that an action that cannot be undone should be confirmed. That’s a simple rule that all of us that design user interfaces would do well to remember.

Here are 8 proven tips to help ensure you create a user interface that your users will love.

1. Limit choices.
Don’t provide an overwhelming number of options or preferences for your users. Too many choices can be intimidating and confusing and can make people not enjoy using your app. Your job is to design the software, which means choosing what it should do. Don’t take the easy way out and provide loads of options for your users all at one time.

2. Be familiar.
Sometimes you may need to implement an entirely new user interface metaphor in order to design your app. But typically this is unnecessary. Though it can be fun creating new and snazzy UI layouts, your users will likely not appreciate them much. Why? Because they won’t understand them or won’t know how to use them. A unique UI design isn’t always practical – stick to what people are familiar with.

3. Be consistent.
Your app should be consistent within itself. Don’t use UI controls in different ways on different screens because that is just confusing. For example, don’t use buttons on one screen to indicate actions, but then use link text on another screen to indicate the same action.

4. Put the user in charge.
Let the user feel like they are controlling the software. This means don’t force them down a single path to solve something. Let them try things and make mistakes. Have an undo feature so that they can easily fix their mistakes.

5. People can’t.
Don’t spend time writing long text for the user as they likely won’t read it. Keep the language short and simple. Make it easy for people to enter text because they are not good at it. If the user has to enter lots of text, give them lots of room, enable a spell checker and use a larger font to make it easier for them to read the text.

Make your UI targets easy to find and use because people can’t control the mouse, trackpad or even their finger for touch devices. And lastly, users likely won’t remember how they did something the last time, so make it easy to figure out.

6. Design first.
Have a design process – it doesn’t need to be anything complex. Sketching designs on paper or a whiteboard is a great way to get a feel for things. Software to mockup UI designs (such as Balsamiq) can also be quite useful. You can also use development tools like Xojo to mockup UI designs, but be careful not to make your mockup too functional or the users might think it is nearly complete!

7. Time is relative.
Users perceive time differently than you might expect. For example, they typically hate waiting for tasks to complete. But if you make it seem like they are not waiting, they often don’t notice how long a task takes. For example, if your main window takes 5 seconds to appear, that will irritate your users. If you instead display the window immediately with a loading indicator, users are far less likely to notice the delay. In general, users more easily notice delays when the UI becomes unresponsive so try to minimize that.

Also keep in mind that features you have spent a large amount of time creating may only be used for a very short period of time. Don’t let yourself become comfortable with a difficult design because you use it frequently.

8. Help out.
Your app should provide assistance to your users. Tips and guides are a great way to gently remind users how to use your software. It’s also a great idea to provide default data for the first launch of your app so that users can see how it is actually used in the real world. Another strategy is to prevent the user from making a mistake in the first place. Disable things when they cannot be used and enable them when they can be used.

For more tips like these, I recommend User Interface Design for Programmers by Joel Spolsky.

If you want to try your next app in Xojo, download it free anytime.