Once you add this ability to your macOS apps, they will fit better when compared with other apps running alongside them. Even better, you don’t need to write additional code in order to handle these additional menu options.

Create a new Desktop project and add a new Module to it called “macOSExtra”. Then add a new method to it using the following signature, make sure to set the Scope of the property to Global:

AddMacOSWindowMenu(item as DesktopMenuItem)

As you can see, this method expects to receive a DesktopMenuItem instance; but before we write a line of code for this method, select the MainMenuBar item in the project Navigator.

The previous action will bring up the Menu Editor. Click on the toolbar button in charge of adding a new first level menu item to the menu bar:

Next, with the new menu item selected in the Navigator, change the following properties in the associated Inspector Panel:

• Name: WindowMenu
• Text: Window

Now, let’s go back to the AddMacOSWindowMenu method in the “macOSEXtra” module, type the following code in the associated Code Editor:

// This code will be only executed when compiling the project
// for the macOS target

#if TargetMacOS then
  
  // We declare the function allowing us to get the reference to a class
  // from the macOS framework (Foundation, in this case), from the parameter passed
  // to it as a String (the class name we want to get the reference to).
  // You can get additional information about this from the Apple Documentation at: https://developer.apple.com/documentation/foundation/1395135-nsclassfromstring?language=objc
  Declare Function NSClassFromString Lib "Foundation" ( name As CFStringRef) As Ptr
  Var theClass As Ptr = NSClassFromString("NSApplication")
  
  // Now that we have the reference to the class
  // we will use it to call the shared method / selector from the NSApplication
  // class in charge or returning a reference to the running app (that is "our" app in this case).
  // You can get additional information about this from the Apple Documentation at:
https://developer.apple.com/documentation/appkit/nsapplication/shared?language=objc
  
  Declare Function GetSharedApplication Lib "AppKit" Selector "sharedApplication" (Application As ptr) As Ptr
  Var theApp As Ptr = GetSharedApplication(theClass)
  
  // Now that we have a reference to the app object, we need to get a reference to the "submenu" hanging from the menu instance received as parameter by the method. For that
  // we need to call the method / selector "submenu" passing along the underlying native
  // menu object retrieved via the "Handle" property from DesktopMenuItem.
  
  Declare Function GetSubmenu Lib "AppKit" Selector "submenu" (menuReference As Ptr) As Ptr
  Var subMenu As Ptr = GetSubmenu(item.Handle)
  
  // The last step is to assign the previous reference to the window property from the app reference.
  // You can get additional information about this from the Apple Documentation at: https://developer.apple.com/documentation/appkit/nsapplication/windowsmenu?language=objc
  
  Declare Sub setWindowMenu Lib "AppKit" selector "setWindowsMenu:" ( appReference As Ptr, menuReference As Ptr)
  setWindowMenu(theApp, subMenu)
  
#EndIf

Testing it!

In order to see how this new method works, select the App item under the IDE Navigator and add the Opening event. Then, type the following line of code in the associated Code Editor:

AddMacOSWindowMenu(WindowMenu)

Run the app and click on the Window item in the main menu bar. You should see that the operating system has added several menu options, similar to the ones displayed in this screenshot (they will vary depending the macOS version the app is running on):

Choose any of the options added and you will see how macOS handles them, without the need to write a line of code in you Xojo project to do it.

Localizing the Window Menu

At this point, the Window menu with the added menu options will look great, but if your app is localized to other languages, then it will be a bit odd to read “Window” for the menu (as well as the English text in the added menu items). To improve this experience, let’s localize the WindowMenu item too!

Let’s add a new Constant to the “macOSExtra” Module and name it “kWindowName” setting its default value to “Window” and switching on the “Localized” field in the Inspector Panel:

Then, use the associated Constant Editor to add new entries (in as many as languages you support). In this case we will just add the entries to support both English and Spanish:

Next, select the WindowMenu item hanging from the MainMenuBar item in the Navigator, and change the value of the Text property to use the new constant:

Change the macOS Settings > General > Idiom and Region so the Spanish language is the main language. Then run the Xojo project again from the IDE and you will see how the “Window” menu entry now reads “Ventana”. Moreover, macOS will add the right localizations for the added menu items so they are in Spanish too.

In Brief

As you have seen, using just a few Declares we have been able to add the expected options for the Window menu to our macOS apps, without the need to write the code in charge of handling them! This doesn’t just mean more options for your users, it also means your Xojo apps will look and feel better when running on macOS.

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

1. Add a Constant, give it a name, default value and set its type to String.
2. A Localized property will now appear in the Inspector. Turn it on.
3. This constant will now appear in a new “Localized Strings” section in the Navigator for the project item.
4. Use the “+” button to add a localized string, then set its Language and Value.
5. Use this localized string in your project.

Below is a localized string that contains some translations of “thanks”.

The most common way to use this is to specify the localized string name as the text property for a control, such as a Label. You prefix the name with “#” to indicate it should be looked up at runtime.

Below you can see “#ThanksString” is set as the value for the Text property of Label1.

Note that “Default” is shown in the IDE because it is using the value for the “Default” language in the localized string. If there was no “Default” language, then the value specified in the Inspector as the “Default Value” is shown in the IDE.

If we then run this project on a device set to US locale, it displays “Thanks”:

If I change to a German locale and run again, it shows “Danke”:

To change the locale, open Settings on the Android device. Navigate to System and then Languages & input. There you will see the Languages option.

Choose that to see the list of languages supported by the device. Click the “+” to add a language. Here I’ve added German (Deutsch):

To make Deutsch the default, drag it so that it is first in the list. You’ll immediately see the UI change its language.

You can also specifically request a language in code by providing the locale as a parameter to the localized string. For example to get the French value:

Var french As String
french = ThanksString("FR")
// Variable french now contains "Merci".

Read the Introduction to App Localization documentation topic to learn more.

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

What’s New in Xojo 2024r4

Xojo 2024r4 brings a range of exciting updates that enhance cross-platform development, improve security, and provide more tools for creating dynamic and interactive applications. Here are some of the standout features:

Web Framework
Enjoy smoother and more efficient web applications with updates to Xojo’s Web Framework. Improved memory usage and numerous bug fixes ensure that your web apps run reliably and perform optimally, providing a better experience for your users.

Discover Web Framework Improvements

These updates and enhancements are designed to make your development process more efficient, productive, and enjoyable. Whether you’re building new applications or enhancing existing ones, Xojo 2024r4 provides the tools and capabilities you need to succeed.

Get Started

To learn more about Xojo 2024 Release 4 and begin your development journey, please visit the Xojo 2024r4 Release Notes. The update is available for download now from the Xojo downloads page.

What’s Next?

We’re continuously working on new features, updates, and enhancements to our platform. If you have any suggestions or ideas, please add them to the Xojo tracker. We’re always looking to improve and expand Xojo to better serve our community.

Thank you for being part of the Xojo community. We’re excited to see what you create with Xojo 2024r4!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

1. Drag a DesktopXAMLContainer to a window.
2. Add the Opening event handler.
3. In the Opening event handler, create the XAML string that defines the control you want and concatenate in your localized constant.

Here’s an example of a simple button with a localized constant named Hello used to define the button text:

Me.Content = "<Button Name='Button' Content='" + Hello + "' />"

Notice that you can use single quotes for the the values. Which makes concatenating them via code easier.

If you’re not exactly sure what the right XAML code is, drag out a DesktopXAMLContainer, click on the Pencil icon on it and then choose the control you want and click the OK button. In the Inspector, you can now edit the Content property of your control to see what the XAML code is to create that control. You can then set the Content property in the Opening event (as described above) using that string.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

I first made a desktop Secret Santa app back in 2015 for an event with friends. We were tired of drawing names out of a hat and having couples being paired together. The app I created solved that problem because couples were excluded from offering a gift to each other. And we didn’t need a hat!

In November of 2018, I had the idea of making a Secret Santa iOS app so that anyone with an iPhone or iPad could benefit from the same features I had been enjoying for the past 3 years.

The app would need to be easy to use, avoid couples getting matched with each other, send notifications by email without letting the organizer know which pairs were matched, and of course make sure no name would be assigned twice.

After just 8 days of development, the app was ready to ship and sent to the App Store.

Within 5 days, the app had been downloaded from 35 different countries and was my fastest app to reach 1000 downloads!

Having the app translated to English, French, Italian, and Spanish in the initial release helped to reach more users.

Version 1.1 of the app was released a few days later with German and Portuguese translations.

That’s when I realized that Secret Santa is something extremely common in Latin America. Many families draw names for Christmas so that they can give and receive one big gift instead of smaller trivial gifts for each family member.

Most updates of the app came with new localizations, which really helped in realizing more and more downloads. After 3 years of updates, the app is now available in 32 languages.

A high quantity of downloads also meant that I received a lot of feedback from users. Many users were happy with the current features, but I started getting feature requests to send the gift pairs by SMS or WhatsApp instead of by email. We all have a parent or grand-parent who isn’t tech-savvy and doesn’t have an email address.

Leveraging the biggest advantage of Xojo – Sharing code across platforms

From 2018 until 2022, I had become used to updating the Secret Santa app itself to add new features and new translations while also fixing bugs. This year, I received a message from an unhappy user stating that they really need a wishlist feature and downloaded my app thinking it already had one.

A valid wishlist feature needed to be accessible to anyone with an Internet connection, whether they used a computer, an iPhone, or an Android device.

Using Xojo Web and a coding language I already knew was the obvious choice for this task. Sharing important bits of code from my main iOS project to the web wishlist project was as easy as copy and paste.

As with any Xojo project, copying classes from one project to the other was a real time saver, especially for the API layer required to communicate between Xojo and the online database that holds all the Secret Santa data.

The main difficulty working on a web project came from the UI. Not that Xojo Web’s UI is difficult, but I am so used to designing mobile apps that my brain didn’t know where to start.

I knew I wanted to display two columns of data:

• The user’s wishlist
• The wishlist from the person they are offering a gift to

The layout had to be responsive to be accessible on both mobile and desktop devices.

Graffitisuite from Anthony Cyphers came to mind, and within a few minutes of reviewing the online demo, I was convinced to use GraffitiKanban web control. I am a big fan of Trello for organizing my work, displaying cards in labeled columns. That’s exactly what I needed for the wishlist feature.

GraffitiKanban is “responsive” (Web Design term), meaning the display changes to adapt to smaller screens such as mobile devices.

GraffitiSuite also offers a wide variety of UI elements that made me save a lot of time.

7 days after the initial feature request, the wishlist feature was available to all.

Wishlist on a desktop browser:

Wishlist on a mobile browser:

Deploying the app to Xojo Cloud was extremely easy.

A single button press in Xojo, a subdomain DNS record, 2 minutes of configuration in Cloudflare, and the web app was up, running, and accessible through HTTPS.

Customer use of the wishlist feature has blown-up more than I ever would have expected. So far 30,000 gift ideas have been added to the wishlist (and counting).

The next feature request

With an app that sees 60,000 new users per month, I receive a lot of feature requests. Most recently, I received a one star review on the app store because my app isn’t accessible to the Visually Impared. When VoiceOver is activated, all it says is “button”, “button”, “button”, with no explanation.

Adding voice-over capabilities in Xojo is simple. The MobileUIControl class has two String properties, AccessibilityHint and AccessibilityLabel.

But it actually is a lengthy task to check each control on each screen and make sure that the translations are correct.

VoiceOver support will soon be released in English and French, but all other localizations will be only ready next year. It is currently a bad time to get 30 different translators to work on the project under such short notice.

Xojo has enabled me to create a business out of developing iOS apps for the App Store. Including all of my apps, I have had over 6.5 million downloads and counting. Secret Santa is a prime example of what is possible and how you can leverage your Xojo skills to expand to other platforms when you need to. I look forward to what’s to come and will be at XDC London to learn more about the future.

If you are organizing a Secret Santa event or just curious to see the app, download Secret Santa on the App Store.

Jérémie Leroy has been using Xojo since 2008, he won two Xojo Design Awards in the iOS App category and has released over 13 iOS apps made with Xojo on the App Store. He also released iOSDesignExtensions on Github to help style and polish your Xojo made iOS apps.

I did some research and found that Amazon provides a service that does exactly what the client was asking for. The service, called Amazon Translate, is available as one of many services that are available through Amazon Web Services.

In this post, I’ll walk you through the process of getting signed up for Amazon Translate, and then share some code that you can use to add language translation to your own Xojo projects. We’ll use the MBS Xojo CURL Plugin, which makes calling the Amazon Translate API easy. But first, let’s learn a little about Amazon Translate.

Amazon Translate

Amazon Translate is an API that can be used to translate text on demand. You send it text in a “source language,” tell the API what that source language is, as well as the “target language” that you want the text translated to. The API responds with the translated text.

Amazon Translate uses machine learning and neural networks that have been designed specifically for language translation. When performing a translation, the service reads the text one sentence at a time, and reads each word individually, to determine the meaning of a sentence. In other words, the service doesn’t just translate words. Instead, it’s acting as an interpreter. This results in translations that are extremely accurate.

In order to use Amazon Translate, you’ll need an AWS account. If you already have an AWS account, log into the account.

Next, you’ll need to create an “Identity and Access Management” (IAM) user. To do so, under Services, select “IAM” (which can be found in the “Security, Identity, & Compliance” category). This will present you with the IAM Dashboard.

Under Groups, create a new group and give it a recognizable name. For example, you might call the group “translate.” As you are creating the group, give it the “TranslateFullAccess” permission.

Next, create an IAM user. Under Users, click the “Add user” button. Give the user a name such as “XojoTranslater.” For the “AWS access type” be sure to select “Programmatic access.” Add the user to the “translate” group that you created above. There’s no need to assign any tags to the user, so you can skip that step.

And finally, create an Access key for the user. Be sure to make note of both the “Access key ID” and “Secret access key” values that are automatically assigned. You’ll need these in order to make API calls.

The MBS Xojo CURL Plugin

If you don’t already have the MBS Xojo CURL Plugin, download it and install it. To install the plugin, simply drag it into the Xojo “Plugins” folder.

The project will work with an unlicensed version of the MBS Xojo CURL Plugin. In this case, you’ll occasionally see a popup message reminding you to purchase a license. However, I highly encourage you to purchase a license. You can license the plugin individually, or as part of the MBS Complete plugin bundle.

The Xojo Example Project

To demonstrate the Amazon Translate service, I’ve put together an example Xojo desktop project (project file). Before running the application, be sure to set the three App-level properties: AWSAccessKeyId, AWSSecretAccessKey, and the AWSRegion. For the AWSAccessKeyId and AWSSecretAccessKey properties, use the values that you set when you created the Access key for the user. For the AWSRegion, refer to this and use the value that makes the most sense for you.

Once you’ve configured the app, run it, and it will look something like this.

The Xojo Code

Let’s take a look at some of the code.

The AWSTranslator class is a subclass of the CURLSMBS class. The class does two important things: It provides access to a list of the languages that are supported, and provides a method for calling the Amazon Translate API.

The “Languages” property is a dictionary that you can use to get the names of the languages that Amazon Translate supports and the corresponding language codes. The example app uses this dictionary to populate the “Translate From” (SourcePopupMenu) and “Translate To” (TargetPopupMenu) popup menus.

The Translate method creates the payload that gets sent to the Amazon Translate API, and sets special HTTP headers that are needed in order to call the API. But most importantly, it uses the CURLSMBS class’s “SetupAWS” method to configure the CURL instance so that all of the steps that are required to “sign” the API request are done automatically. This is an amazingly convenient function of the MBS Xojo CURL Plugin. You can get a sense of what’s involved in signing the request here.

To translate text using the AWSTranslator class, you create an instance, configure it with your IAM credentials and AWS region, pass it the source language text, the source language code, and the target language code. In the example app, this all handled in the Window1.Translate method. The values are pulled from the App-level properties, as well as the various window controls. Finally, you call the AWSTranslator instance’s Translate method. If the translation is successful, the translated text will be available via the TranslatedText property. If any errors occur, the ErrorType and ErrorMessage properties will be set.

The “Estimated Translation Cost” is calculated whenever the Source Text changes. The value is calculated by taking the length (number of characters) of the Source Text and multiplying it by 0.000015 (the average cost for translating a single character).

Wrapping Up

I’ve been amazed at the speed and accuracy of the Amazon Translate service. And after developing the AWSTranslator class, I was able to quickly and easily add language translation to my client’s middleware app.

I hope you’re equally impressed by the Amazon Translate service, and that you find the AWSTranslator class to be helpful in your own Xojo projects.

Tim Dietrich is a custom software developer based in Richmond, Virginia. To learn more, visit: https://timdietrich.me

For English systems you don’t have to do anything. By default the Edit menu text is “Edit” so macOS will find it and automatically add “Start Dictation” and “Emoji & Symbols”. Should you not want them to appear, you can change the text so that it is “Edit ” (with an extra trailing space).

For non-English systems you will need to provide a Dynamic Constant to use in place of the hard-coded text of “Edit” on the EditMenu. This dynamic constant needs to have the appropriate translation for Edit as required by macOS.

Here’s how you can set this up for a variety of languages.

Added a public Dynamic Constant to App:

Then use it in the menu:

When you run the project with French set as the primary language you will see “Démarrer Dictée” in the Édition menu:

Do the same thing for other languages you need. The easiest way that I found to determine the correct word was to change your System Language and then start a built-in Apple app such as Notes or Safari and make a note of what the “Edit” menu is called.

Download a project with the above languages in a Dynamic Constant.

Here are 5 basics to consider when localizing your app:

1. Different Word Lengths
Some languages, such as German, have longer words than other languages like English. When designing your UI controls, you’ll need to account for this. A common way is to make the buttons large enough to accommodate the longest text.

You could also add code to the UI controls to have it resize itself if the localized text would not fit. But resized controls can also affect other controls on your layout, so a system like auto-layout can also help greatly to ensure that your UI adjusts itself appropriately when the text changes.

2. Don’t use Google Translate
Find someone that natively speaks both languages to do your translation. Obviously, you will need more than one person if you are translating to many languages.

Google Translate has its uses, but it’s translations often have unusual (or wrong) words and phrasing. So even though the text will be in the localized language, it could still remain difficult for native speakers to understand.

You don’t want your translations to say “Throw me down the stairs my shoes.” when it should say “Toss my shoes down the stairs to me.”

3. Don’t forget about dates
Date formats vary, so be sure to consider how they are displayed. What is the date for 3/7/14? Is it March 7th, 2014 or July 3rd, 2014? For internal dates that are not displayed to the user, you should use a standard format, such as SQL Date: YYYY-MM-DD.

When displaying dates, you should always use the user’s OS settings. This applies to both short dates with just the numbers and long dates where the month and day are spelled out.

And remember the position of each date component. Some places might use “March 7th, 2014”, but others would use “7 march 2014”.

4. Numbers
As with dates, numbers are also displayed differently. Not all countries use a “.” as the decimal separator. Not all countries use “,” as the thousands separator. The display of 3456.78 could be “3,456.78” is one location, but “3 456,78” in another.

Ask the operating system for the values specific to the user’s system settings.

And as with dates, when using numbers internally always use a standard and consistent format so that you can read them correctly regardless of the localization.

5. Currency
This trend continues with currency. Don’t presume that “$” is the currency symbol. As above, you should ask the OS for the specific currency symbol. And when storing currency values, do not include the currency symbol as that could make doing math on the values more difficult.

To display dates formatted in the locale of the user session, you need to get the LanguageCode from WebSession and use that to create a locale that you can then use to display the date.

This code (in a WebLabel Shown event handler) gets the language code for the user session and then uses it to display the current date:

Dim langCode As Text = Session.LanguageCode.DefineEncoding(Encodings.UTF8).ToText
Dim locale As New Xojo.Core.Locale(langCode)
Me.Text = Xojo.Core.Date.Now.ToText(locale, _
  Xojo.Core.Date.FormatStyles.Long, _
  Xojo.Core.Date.FormatStyles.None)

When the browser is set to English, this displays: January 9, 2017

When it is set to French, this displays: 9 janvier 2017

Use the same technique with number formatting. This code (in a WebLabel Shown event handler) gets the language code for the user session and then uses it to display a formatted number:

Dim langCode As Text = Session.LanguageCode.DefineEncoding(Encodings.UTF8).ToText
Dim locale As New Xojo.Core.Locale(langCode)
Dim num As Double = 1234.56
Me.Text = num.ToText(locale, "#,###.##")

When the browser is set to English, the number displays like this: 1,234.56

When it is set to French, it displays like this: 1 234,56

To get both the language and region information, you should check the value of the “Accept-Language” HTTP header:

Dim langHeader As String = Session.Header("Accept-Language")

Which returns both the language and region code in a format like this: en-US.

Note that there may be more than one value returned in this header so you may need to parse it to ensure you get the value you actually want.

Refer to Localization in the User Guide for more information on how to localize your desktop, iOS and web apps.