To determine whether a macOS app is running with UI Compatibility Mode enabled, we’ll use a small set of Declares inside a method contained in a Module, purely for the purposes of this example. Begin by creating a new Desktop project and adding a new Module to it (for example, a simple “Module1”). Next, add a new method to the Module with the following signature:

IsCompatibilityModeEnabled As Boolean

Then add the following code to the method:

#If TargetMacOS Then
  
  If System.Version.MajorVersion >= 26 Then
    
    Declare Function NSClassFromString Lib "Foundation" (clsName As CFStringRef) As Ptr
    Declare Function NSMainBundle Lib "AppKit" Selector "mainBundle" (obj As Ptr) As Ptr
    Declare Function NSInfoDictionary Lib "AppKit" Selector "infoDictionary" (obj As Ptr) As Ptr
    Declare Function NSDictValueForKey Lib "AppKit" Selector "valueForKey:" (obj As Ptr, key As CFStringRef) As Ptr
    Declare Function NSGetBoolValue Lib "AppKit" Selector "boolValue" (obj As Ptr) As Boolean
    
    Var Bundle As Ptr = NSClassFromString("NSBundle")
    
    If Bundle <> Nil Then
      Var MainBundle As Ptr = NSMainBundle(Bundle)
      
      If MainBundle <> Nil then
        Var infoDictionaryPlist As Ptr = NSInfoDictionary(MainBundle)
        
        If infoDictionaryPlist <> Nil Then
          Var valueObj As Ptr = NSDictValueForKey(infoDictionaryPlist, "UIDesignRequiresCompatibility")
          
          If valueObj <> Nil Then 
            Return NSGetBoolValue(valueObj)
          End If
          
        End If
        
      End If
      
    End If
  End If
  
  Return False
  
#EndIf

In short, the previous code retrieves the app’s Info.plist from the macOS bundle and loads it into an NSDictionary object (similar to Xojo’s Dictionary). It then attempts to access the value associated with the key UIDesignRequiresCompatibility. If the returned object is Nil, it means the Info.plist does not contain that key and the app is therefore running in native macOS Tahoe mode. If the key is present, the method returns the Boolean value associated with it; a value of True indicates that the app is running with UI Compatibility Mode enabled under macOS Tahoe. That’s all there is to it!

Testing the Method

Now add a DesktopButton to the project’s default window and implement its Pressed event. Next, insert the following line of code into the associated Code Editor:

MessageBox("Compatibility Mode Enabled: " +  IsCompatibilityModeEnabled.ToString)

For testing purposes, select Build Settings > macOS in the Project Browser and enable UI Compatibility Mode, which can be found under the Build section of the Inspector. Run the app and, if your Mac is running macOS 26 or later, you will see the following message:

Quit the app and return to Build Settings > macOS to disable UI Compatibility Mode. Run the app again and this time you will see the following message:

In Summary

As you can see, Declares are a powerful feature in Xojo’s extensive toolbox, allowing developers to directly access and use APIs provided by the operating system. In this case, they enable you to retrieve the app’s Info.plist from the main bundle, load it into a dictionary, and read the value associated with a specific key.

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

Create a new Android project with two container controls in the IDE, to which you add some controls. Then switch back to Screen1 in the Navigator and add a MobileSegmentedButton and a MobileTabPanel. In the Inspector, set the locking for the TabPanel to all four sides and assign both container controls to the TabPanel via the Inspector. Those are the basic preparations.

The MobileTabPanel is a subclass of Android’s TabLayout view (com.google.android.material.tabs.TabLayout). This consists of the tabs themselves and a so-called ViewPager that holds the containers.

First, we remove the top tab bar from the control. After that, we update the position of the area where the containers are displayed. Then we disable the swipe gesture (optional). And that’s it.

Now add the Opening event to TabPanel1. First, we add two Android-specific import Declares so that the following Declares don’t take up too much space and readability is maintained:

Declare Sub import1 Lib "android.view.*:Import"
Declare Sub import2 Lib "android.widget.*:Import"

Next, we remove the tab bar from the control:

' Removes the tab bar from the MobileTabPanel.
Declare Function RemoveTabs Lib "Kotlin" Alias "(ref as ViewGroup).apply { visibility = View.GONE }" (ref As Ptr) As Ptr
Call RemoveTabs(Me.Handle)

After that, we adjust the top position of the ViewPager by setting it to 0:

' Update control bounds.
Declare Function GetLayoutParams Lib "Object:Me:MobileTabPanel" Alias "_tabPager!!.layoutParams" As Ptr
Declare Function UpdateLayoutParams Lib "Kotlin" Alias "(ref as FrameLayout.LayoutParams).apply { topMargin = 0 }" (ref As Ptr) As Ptr
Call UpdateLayoutParams(GetLayoutParams)

Now add the Pressed event to the MobileSegmentedButton with this code, which ensures switching between the panels:

TabPanel1.SelectedPanelIndex = segmentedIndex

And that’s it – click Run to start the project.

To make the control feel even more like a PagePanel, we now want to eliminate the ability to switch between panels with swipe gestures. To do this, go back into the TabPanel1 Opening event and add this code:

' Disable swipe.
Declare Sub setUserInputEnabled Lib "Object:Me:MobileTabPanel" Alias "_tabPager!!.setUserInputEnabled" (value As Boolean) setUserInputEnabled(False)

And that’s it: the control is now a PagePanel – without tabs and within the same bounds as the TabPanel.

Here you can see the PagePanel in action.

Once you know where and what to look for in the Android API, there’s almost nothing you can’t already do with Declares in Xojo Android. But if you are looking for a native solution, you can join my feature request to implement MobilePagePanel on Android.

Happy Coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

On macOS, DesktopTextArea uses the native macOS control. When you need to tweak its behavior, Declares can help. For example, by default text lines are soft-wrapped to the control’s width. But sometimes you may want to turn that off so each line displays in full, making the text easier to read line by line.

If you need to do just that, without resorting to other options because the use of a DesktopTextArea is what you really need to use, then put the following snippet of code into the Opening event handler for the DesktopTextArea instance:

If that’s exactly what you need to do and you want to stick with DesktopTextArea, just add the following code to the Opening event of your DesktopTextArea:

#If TargetMacOS Then
  // At this point we are getting really the handle to
  // the wrapping object: NSScrollView
  Var tAObj As Ptr = Me.Handle
  
  Declare Function Subviews Lib "AppKit" Selector "subviews" (obj As Ptr) As Ptr
  Declare Function ObjectAtIndex Lib "AppKit" Selector "objectAtIndex:" (obj As Ptr, index As Integer) As Ptr
  
  // We need to get the real NSTextView view that is set
  // inside the clip view set inside the NSScrollView
  Var subViewsFromScroll As Ptr = Subviews(tAObj)
  Var clipView As Ptr = ObjectAtIndex(subViewsFromScroll, 1)
  Var subViewsFromClipView As Ptr = Subviews(clipView)
  
  //…and here it is
  Var textAreaView As Ptr = ObjectAtIndex(subViewsFromClipView, 2)
  
  // At this point we have the real NSTextView from the wrapping NSScrollerView!
  
  Declare Function TextContainer Lib "AppKit" Selector "textContainer" (obj As Ptr) As Ptr
  Declare Sub SetWidthTracksTextView Lib "AppKit" Selector "setWidthTracksTextView:" (obj As Ptr, value As Boolean)
  Declare Sub SetContainerSize Lib "AppKit" Selector "setContainerSize:" (obj As Ptr, size As CGSize)
  Declare Sub SetMaxSize Lib "AppKit" Selector "setMaxSize:" (obj As Ptr, size As CGSize)
  
  // Retrieving the NSTextContainer
  Var tcObj As Ptr = TextContainer(textAreaView)
  SetWidthTracksTextView(tcObj, False)
  
  Var newSize As CGSize
  newSize.Width = 100000 // Arbitrary value… we only need to set it to a really high value!
  newSize.Height = 100000
  
  // And setting a new max width size to it.
  SetMaxSize(tAObj, newSize)
  
  // …and also using the same value for the size of the NSTextContainer
  SetContainerSize(tcObj, newSize)
#Endif

The code above uses the CGSize data type, a Struct added to the Window (though you’ll likely want to place it in a Module instead). It has two members:

• Width As Integer
• Height As Integer

We need to use this Data Type / Struct because some macOS framework methods from NSScrollView and NSTextContainer expect it.

After adding the code, enable the ‘Has Horizontal Scrollbar’ property in the Inspector for your DesktopTextArea. Run the app and you’ll see that soft wrapping is no longer applied!

What other customized behaviors have you added to macOS DesktopTextArea instances via Declares? Go ahead and share the code so other users can benefit from them.

Happy coding!

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

As you might expect, we’ll need a few more Declares to accomplish this. Continue reading to learn how!

Since we’re building on the example project from the first blog post in this series, I strongly recommend completing that post if you haven’t already, then continuing with the second and third articles before proceeding here.

Select the “DeclaresForiOS” module and add a new method to it, using the following values for its signature in the Inspector Panel:

• Method Name: TabBarBadgeColor
• Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
• Scope: Global

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

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Function BarAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

Var appearance As Ptr = BarAppearance(tabBar)

Declare Function StackedLayout Lib "UIKit" Selector "stackedLayoutAppearance" (obj As Ptr) As Ptr
Declare Function InlineLayout Lib "UIKit" Selector "compactInlineLayoutAppearance" (obj As Ptr) As Ptr
Declare Function NormalState Lib "UIKit" Selector "normal" (obj As Ptr) As Ptr

Var stackLayout As Ptr = StackedLayout(appearance)
Var inLayout As Ptr = InlineLayout(appearance)
Var normalState As Ptr = NormalState(stackLayout)
Var normalInlineState As Ptr = NormalState(inLayout)

Declare Sub SetBadgeColor Lib "UIKit" Selector "setBadgeBackgroundColor:" (obj As Ptr, value As Ptr)

SetBadgeColor(normalState, colorPtr)
SetBadgeColor(normalInlineState, colorPtr)

SetAppearance(tabBar, appearance)

If System.Version.MajorVersion >= 15 Then
  Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)
  SetScrollEdgeAppearance(tabBar, appearance)
End If

Next, select the Screen1 item in the Navigator and add a new property to it using the following values in the Inspector Panel:

• Name: MyTabBadgeColor
• Type: ColorGroup
• Scope: Protected

Setting the Badge Text Color

What’s next? I’m sure you guessed it! Now that we can customize the badge color, the default white text color on the badge may not always provide the best contrast.

Let’s add a new method to our “DeclaresForiOS” module with the following signature values in the Inspector Panel:

• Name: TabBarBadgeTextColor
• Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
• Scope: Global

And type (or paste) the following snippet of code in the associated Code Editor:

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Function BarAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

Var appearance As Ptr = BarAppearance(tabBar)

Declare Function StackedLayout Lib "UIKit" Selector "stackedLayoutAppearance" (obj As Ptr) As Ptr
Declare Function InlineLayout Lib "UIKit" Selector "compactInlineLayoutAppearance" (obj As Ptr) As Ptr
Declare Function NormalState Lib "UIKit" Selector "normal" (obj As Ptr) As Ptr

Var stackLayout As Ptr = StackedLayout(appearance)
Var inLayout As Ptr = InlineLayout(appearance)

Var normalState As Ptr = NormalState(stackLayout)
Var normalInlineState As Ptr = NormalState(inLayout)

Declare Sub SetBadgeTextAttr Lib "UIKit" Selector "setBadgeTextAttributes:" (obj As Ptr, value As Ptr)

Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As Ptr
Declare Function DictionaryWithObjectForKey Lib "UIKit" Selector "dictionaryWithObject:forKey:" (obj As Ptr, value As Ptr, key As CFStringRef) As Ptr

Var dict As Ptr = DictionaryWithObjectForKey( NSClassFromString("NSMutableDictionary") , colorPtr, "NSColor")

SetBadgeTextAttr(normalState, dict)
SetBadgeTextAttr(normalInlineState, dict)

SetAppearance(tabBar, appearance)

If System.Version.MajorVersion >= 15 Then
  Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)
  SetScrollEdgeAppearance(tabBar, appearance)
End If

Next, select the Screen1 item in the Navigator and add a new property to it using the following values in the Inspector Panel:

• Name: MyTabBadgeTextColor
• Type: ColorGroup
• Scope: Protected

Then, select the Screen1.Opening event handler and add these lines of code to it:

MyTabBadgeColor = New ColorGroup(Color.Green, Color.Blue)
MyTabBadgeTextColor = New ColorGroup(Color.Black, Color.Yellow)

Me.ParentTabBar.BadgeAt(0) = "33"
Me.ParentTabBar.BadgeAt(1) = "42"

Lastly, select the Screen1.AppearanceChanged event handler and add this line of code at the end:

Me.ParentTabBar.TabBarBadgeColor = MyTabBadgeColor
Me.ParentTabBar.TabBarBadgeTextColor = MyTabBadgeTextColor

Testing the App

Everything is set! Run the app on your iPhone or in the Simulator, and you’ll see each tab in the TabBar displaying its own badge with the custom background and text colors we configured in the Opening Event.

Download the example project from this link.

Happy Xojo Coding!

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

Continue reading to learn how to do all of this thanks to the powerful flexibility of Declares!

Before we dive in, keep in mind that we’re building on the example project introduced in the first blog post of this series. If you haven’t read it yet, I encourage you to start there. Then, follow up with the second post to make sure you’re fully up to speed and ready to continue adding even more color customization to your iOS screens!

Background Color for the TabBar

In order to colorize the TabBar background, we need to add a new method to the “DeclaresForiOS” Module using the following values:

• Method Name: TabBarBackgroundColor
• Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
• Scope: Global

Add the following snippet of code in the associated Code Editor:

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Function BarAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub ConfigureWithOpaqueBackground Lib "UIKit" Selector "configureWithOpaqueBackground" (obj As Ptr)
Declare Sub SetBackgroundColor Lib "UIKit" Selector "setBackgroundColor:" (obj As Ptr, value As Ptr)
Declare Sub SetAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

Var appearance As Ptr = BarAppearance(tabBar)
SetBackgroundColor(appearance, colorPtr)

SetAppearance(tabBar, appearance)

If System.Version.MajorVersion >= 15 Then
  Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)
  SetScrollEdgeAppearance(tabBar, appearance)
End If

Essentially, we’re setting the color by assigning it to the backgroundColor property of the appearance object associated with the TabBar.

Setting the Text Color

Now let’s add the code responsible for setting the text color of the selected tab in the TabBar. To do this, we just need to set the tintColor property. So, go ahead and add a new method to the “DeclaresForiOS” module with the following values:

• Method Name: TabBarTextColor
• Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
• Scope: Global

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

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Sub SetTintColor Lib "UIKit" Selector "setTintColor:" (obj As Ptr, value As Ptr)

SetTintColor(tabBar, colorPtr)

Setting Unselected Tabs Text Color

To set the text color for unselected tabs, we’ll need to use a few additional Declares. This is because the color must be applied to the normal state of the stackedLayoutAppearance object from the TabBar’s appearance. Additionally, we need to set the same value for the compactInlineLayoutAppearance, which is used when the device is in landscape orientation.

Add a new method to the “DeclaresForiOS” Module using the following values for its signature:

• Method Name: TabBarUnselectedTextColor
• Parameters: Extends tab As iOSTabBar, Assigns value As ColorGroup
• Scope: Global

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

Var tabController As Ptr = tab.ViewControllerHandle

If value = Nil Then Return

Declare Function GetTabBar Lib "UIKit" Selector "tabBar" (obj As Ptr) As Ptr
Var tabBar As Ptr = GetTabBar(tabController)

Var colorPtr As Ptr = ColorGroupToUIColor(value)

Declare Function BarAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

Declare Function StackedLayout Lib "UIKit" Selector "stackedLayoutAppearance" (obj As Ptr) As Ptr
Declare Function InlineLayout Lib "UIKit" Selector "compactInlineLayoutAppearance" (obj As Ptr) As Ptr
Declare Function NormalState Lib "UIKit" Selector "normal" (obj As Ptr) As Ptr

Var appearance As Ptr = BarAppearance(tabBar)
Var stackLayout As Ptr = StackedLayout(appearance)
Var inLayout As Ptr = InlineLayout(appearance)

Var normalState As Ptr = normalState(stackLayout)
Var normalInlineState As Ptr = NormalState(inLayout)

Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As Ptr
Declare Function DictionaryWithObjectForKey Lib "UIKit" Selector "dictionaryWithObject:forKey:" (obj As Ptr, value As Ptr, key As CFStringRef) As Ptr

Var dict As Ptr = DictionaryWithObjectForKey( NSClassFromString("NSMutableDictionary") , colorPtr, "NSColor")

Declare Sub SetTextAttributes Lib "UIKit" Selector "setTitleTextAttributes:" (obj As Ptr, value As Ptr)

SetTextAttributes(normalState, dict)
SetTextAttributes(normalInlineState, dict)
SetAppearance(tabBar, appearance)

If System.Version.MajorVersion >= 15 Then
  Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)
  SetScrollEdgeAppearance(tabBar, appearance)
End If

Testing the TabBar Color

Add a new screen to the project so that our example app includes at least two screens. You can do this by selecting Insert > Screen from the IDE toolbar.

To test the new methods, we need the app to use a TabBar. To enable that, select the iPhoneLayout item in the Navigator. Then, in the Inspector Panel, locate the Content label and choose Tabs from the associated popup menu. Finally, set Screen1 as the content for Tab 0 using the “Tab 0 Content” popup menu.

Next, with Screen1 still selected in the Navigator, click on the “Tab 1” label in the Layout Editor. Then, in the Inspector Panel, use the popup menu next to the “Tab 1 Content” label to select Screen2.

With Screen1 still selected in the Navigator, add a new property to it using the following values:

• Name: MyTabBarUnselectedTextColor
• Type: ColorGroup
• Scope: Protected

Now select the Screen1.Opening event handler and add this line of code:

MyTabBarUnselectedTextColor = New ColorGroup(Color.White, Color.LightGray)

As the last step, select the Screen1.AppearanceChanged event handler and add this line of code:

Me.ParentTabBar.TabBarBackgroundColor = mNavigationBarColor
Me.ParentTabBar.TabBarTextColor = MyNavigationBarTextColor
Me.ParentTabBar.TabBarUnselectedTextColor = MyTabBarUnselectedTextColor

All set! Now it’s time to run the example project in the Simulator or on your iPhone. You’ll see that the TabBar background color matches the one set for the NavigationBar, and the selected tab text color is consistent as well. The unselected tab text appears white in Light Mode and light gray in Dark Mode, reflecting the ColorGroup settings.

As we’ve seen, Declares are a powerful way to tap into native iOS framework functions and routines. The most challenging part is often figuring out which ones to use since that requires digging into Apple’s developer documentation.

Download the example project from this link.

Happy Xojo coding!

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

Continue reading to learn how to customize those elements too.

Just like in the previous blog post, we’ll need to use several Declares to access the necessary iOS framework functions and retrieve the underlying objects we want to modify.

If you haven’t followed the previous post yet, be sure to check it out first—we’ll be building on the same example project to add these new customizations.

Let’s add a new method to our previously created “DeclaresForiOS” Module using the following values:

• Method Name: NavigationBarTextColor
• Parameters: Extends screen As MobileScreen, Assigns value As ColorGroup
• Scope: Global

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

If value = Nil Then Return

Var controller As Ptr = screen.ViewControllerHandle

Declare Function NavigationController Lib "UIKit" Selector "navigationController" (controller As Ptr) As Ptr
Declare Function NavigationBar Lib "UIKit" Selector "navigationBar" (controller As Ptr) As Ptr

Var nc As Ptr = NavigationController(controller)
Var nv As Ptr = NavigationBar(nc)

Var colPtr As Ptr
colPtr = ColorGroupToUIColor(value)

Declare Function DictionaryWithObjectForKey Lib "UIKit" Selector "dictionaryWithObject:forKey:" (obj As Ptr, value As Ptr, key As CFStringRef) As Ptr

// https://developer.apple.com/documentation/foundation/nsclassfromstring(_:)?language=objc
Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As Ptr

Declare Function StandardAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetStandardAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)
Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)

Declare Sub SetTitleTextAttributedText Lib "UIKit" Selector "setTitleTextAttributes:" (obj As Ptr, value As Ptr)
Declare Sub SetLargeTitleTextAttributedText Lib "UIKit" Selector "setLargeTitleTextAttributes:" (obj As Ptr, value As Ptr)

Declare Sub SetTintColor Lib "UIKit" Selector "setTintColor:" (obj As Ptr, value As Ptr)

// We need to create a NSDictionary with the attribute we want to set on text for the NavigationBar Appearance
Var dict As Ptr = DictionaryWithObjectForKey(NSClassFromString("NSMutableDictionary"), colPtr, "NSColor")

Var appear As Ptr = StandardAppearance(nv)

// Setting the new appearance settings both for the regular-sized title
// and the Large one
SetTitleTextAttributedText(appear, dict)
SetLargeTitleTextAttributedText(appear, dict)

// And we apply the modified appearance to the StandardAppearance
SetStandardAppearance(nv, appear)

// And to the scrollEdgeAppearance if the app is run on iOS 15+
If (System.Version.MajorVersion >= 15.0) Then
   SetScrollEdgeAppearance(nv, appear)
End If

// The TintColor is applied on the text of the added buttons to the NavigationBar
// So we need to use the same color for them!
SetTintColor(nv, colPtr)

And that’s all the code we need.

Colorizing!

Select the Screen1 item in the Navigator and add a new property to it using the following values:

• Name: MyNavigationBarTextColor
• Type: ColorGroup
• Scope: Protected

Now select the Screen1.Opening event and add the following line of code:

MyNavigationBarTextColor = New ColorGroup(Color.Yellow, Color.Red)

Finally, select the Screen1.AppearanceChanged event handler and add the following line:

Me.NavigationBarTextColor = MyNavigationBarTextColor

Run the example project, and you’ll see that the title text remains correctly displayed, even when switching between Light and Dark modes.

Download the example project from this link.

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

Keep reading to learn how to style your Navigation Bar.

Declares in Xojo allow you to access functions and constants from compiled libraries and system frameworks such as those provided by iOS or third-party developers. They’re a powerful way to extend your app’s capabilities beyond what is available in the Xojo framework.

In this case, we’ll use Declares to tap into the native iOS APIs and customize the appearance of a MobileScreen‘s NavigationBar, specifically to set its background color.

Start by adding a new module to your existing or empty iOS project. I’ve named this DeclaresForiOS. Within this module, add a new method using the following values:

• Method Name: NavigationBarColor
• Parameters: Extends Screen As MobileScreen, Assigns Value As ColorGroup
• Scope: Global

Add the following snippet of code in the Associated Code Editor:

// Getting the ViewController for the received Screen
Var controller As Ptr = Screen.ViewControllerHandle

// https://developer.apple.com/documentation/uikit/uiviewcontroller/navigationcontroller?language=objc
Declare Function NavigationController Lib "UIKit" Selector "navigationController" (controller As Ptr) As Ptr

// https://developer.apple.com/documentation/uikit/uinavigationcontroller/navigationbar?language=objc
Declare Function NavigationBar Lib "UIKit" Selector "navigationBar" (controller As Ptr) As Ptr

// Getting the NavigationBarController associated with the ViewController
Var nc As Ptr = NavigationController(controller)

// …and the NavigationBar itself from the NavigationBarController
Var nv As Ptr = NavigationBar(nc)

Var colPtr As Ptr
If value <> Nil Then
  colPtr = ColorGroupToUIColor(value)
End If

// https://developer.apple.com/documentation/uikit/uinavigationbar/standardappearance?language=objc
Declare Function StandardAppearance Lib "UIKit" Selector "standardAppearance" (obj As Ptr) As Ptr
Declare Sub SetStandardAppearance Lib "UIKit" Selector "setStandardAppearance:" (obj As Ptr, value As Ptr)

// https://developer.apple.com/documentation/uikit/uinavigationbar/scrolledgeappearance?language=objc
Declare Sub SetScrollEdgeAppearance Lib "UIKit" Selector "setScrollEdgeAppearance:" (obj As Ptr, value As Ptr)

// https://developer.apple.com/documentation/uikit/uibarappearance/backgroundcolor?language=objc
Declare Sub SetBackgroundColor Lib "UIKit" Selector "setBackgroundColor:" (obj As Ptr, value As Ptr)

// Getting the StandardAppearance object from the NavigationBar
Var appear As Ptr = StandardAppearance(nv)

// Setting the BackgroundColor to the StandardAppearance…
SetBackgroundColor(appear, colPtr)

// …and assigning the Standard Appearance again to the NavigationBar
SetStandardAppearance(nv, appear)

// If our app is running on iOS >= 15.0, then we need to set
// the same appearance to the scrollEdgeAppearance attribute on the NavigationBar
if (System.Version.MajorVersion >= 15.0) then
  SetScrollEdgeAppearance(nv, appear)
end if

As shown in the previous code, we’re calling the ColorGroupToUIColor method to convert a ColorGroup instance into a pointer to a valid UIColor. To support this, let’s add that helper method to our DeclaresForiOS module using the following values:

• Method Name: ColorGroupToUIColor
• Parameters: value As ColorGroup
• Return Type: Ptr
• Scope: Global

And type (or paste) the following snippet of code:

Var colorPtr As Ptr
Var c As Color

Select Case value.Mode
  
Case ColorGroup.Modes.Dual
  Var valueColors() As Color = value.Values
  If Color.IsDarkMode And valueColors.LastIndex > 0 Then
    c = valueColors(1)
  Else
    c = valueColors(0)
  End If
Case ColorGroup.Modes.Single
  Var valueColors() As Color = value.Values
  c = valueColors(0)
End Select

If colorPtr = Nil Then
  
  // https://developer.apple.com/documentation/foundation/nsclassfromstring(_:)?language=objc
  Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As Ptr
  
  // https://developer.apple.com/documentation/uikit/uicolor/1621930-colorwithred
  Declare Function RGBA Lib "UIKit" selector "colorWithRed:green:blue:alpha:" (cls As Ptr, r As Double, g As Double, b As Double, a As Double) As Ptr
  
  colorPtr = RGBA(NSClassFromString("UIColor"), c.Red/255, c.Green/255, c.Blue/255, 1-(c.Alpha/255))
  
End If

return colorPtr

Let’s Color That!

And that is all the code we need! Now select the Screen1 item in the Navigator for the iOS project and add the following property to it:

• Name: MyNavigationBarColor
• Type: ColorGroup
• Scope: Protected

With the Screen1 still selected in the Navigator, add the Opening event to it and add the following line of code:

MyNavigationBarColor = New ColorGroup( color.Red, color.Yellow )

As the last step, add the AppearanceChanged event to the Screen1 item; and add the following line of code to it:

me.NavigationBarColor = MyNavigationBarColor

Make sure the “Has Navigation Bar” attribute is enabled in the Inspector for Screen1, then run the project. If your Simulator or device is set to Light Mode, the Navigation Bar will appear red; if it’s in Dark Mode, it will appear yellow. You can switch between Light and Dark modes to see the Navigation Bar color transition between the two colors defined in your ColorGroup.

Download the example project from this link.

Happy coding!

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

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

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

You can now use the SetBottomAppBarMenuAlignmentModeXC extension method for MobileScreen to set the alignment of the buttons in your MobileScreen.Toolbar.

Additionally, new declares for MobileMessageBox have been added, allowing you to display an icon next to the title as well as next to individual buttons.

Give it a try! More exciting Android features are coming soon. Stay tuned!

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library.

I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples at https://github.com/XojoGermany/AndroidDesignExtensions.

Happy coding.

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

From now on, Buttons and TextFields can use Xojo Pictures directly and you no longer need to save images that you want to use. Take a look at the “Deprecations Version 3.0” section in the Read me to find out which methods are deprecated in this regard.

Now it’s getting colorful!

In this version, support for over 180 system colors has been added, depending on which Android version your app is running on. The sample app has a new page with the system colors. It gives you a good overview. Using these colors can help you to design your apps according to the Material Design Guidelines in light & dark mode.

Picture objects and the content of a MobileHTMLViewer can now also be printed.

We are familiar with the DrawInto method from the Desktop Framework, which draws DesktopUIControls and DesktopWindows into a Graphics object. These methods have now also been added for MobileUIControls and MobileScreen.

The title bar and the NavigationBar can now also be highlighted in color. The font, color and alignment of the NavigationBar can also be changed.

How? What? Where?

The system paths for various folders (SpecialFolder) have also been added.

Almost all modules have been updated according to the new Declare data types. The example app has also been further optimized for dark mode in this version.

The new Declare capabilities in Xojo 2024r3 are another huge step forward. You now have the possibility to declare in almost every Android API without having to go through an Android library.

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library.

I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples at https://github.com/XojoGermany/AndroidDesignExtensions.

Happy coding.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This post describes the things you can do with Declares and Libraries with Android projects.

Declare Integer Types

The size-specific Integer types are now precise when used with Declares. The mappings are as follows:

When mapping to Android API functions or Library functions, be sure to use the correct Xojo type that matches what is expected on Android. By far you will use Int32 and Integer.

If you previously created Declares, you will likely need to change usage of Integer to Int32 as the mapping for that have changed compared to prior versions.

Nullable Types

Xojo object variables (also properties, parameters and return values) can be Nil. With Kotlin, the default is that these things cannot be null (the equivalent of Nil). To ensure that you don’t get compile errors with your parameters, declare them as nullable in Kotlin by appending the “?” to the end of the type name.

Application Context

Many Android APIs require the application context. This is not available in a Library so it has to be supplied by the app itself. There is a property for this:

MobileApplication.AndroidContextHandle As Ptr

You can pass this value to a function on the Library that then either saves it or uses it directly.

Using Ptr

Xojo uses the Ptr type to interface with Declares, however Kotlin does not have a Ptr type. Instead the Any type is used with Kotlin. This means that if you are passing something that is a Ptr to Kotlin (such as the app context above), your library function declaration should use “Any?” as the type of the parameter.

In your function, cast the parameter to the actual type you want. The same rule applies to return values. If the return value in the Declare is a Ptr, then in Kotlin the function declaration should be “Any?”.

You can also use Ptr with API calls to save object references as described below.

Library Permissions

Depending on the API you are using, you may need to add permissions to the app manifest.xml for the Library. These permissions also need to be applied to the main app. This can be done using the Advanced tab of the Android Build Settings. There you’ll find the Permissions property in the Inspector where you can add one Permission per line.

Previous versions let you separate permissions by spaces or commas. Going forward, each permission must be on its own line. Empty lines are ignored.

There you can add the permission constants that are required by your Library. In addition, you can follow the constant with additional attributes and they will also be applied to the app’s manifest file.

For example, to include the android:maxSdkVersion attribute with the BLUETOOTH permission:

android.permission.BLUETOOTH android:maxSdkVersion="30"

Library Dependencies

Similarly to permissions, your Library may make use of additional dependencies, which could even be other Libraries. These are added to the build.gradle file for the Library, but also need to be included in the main app.

You can add these dependencies using the Dependencies property on the Advanced Android Build Settings.

Creating Objects

Previous versions of Xojo only let you call Companion (essentially shared) methods on Library classes. Now you can also work with class instances and call instance methods. This gives you even better control and ability to interface with Android APIs.

To create an object, your Library class should have a factory method on the Companion that returns a new instance. It is clearest to use create() as this method name.

In Xojo you create a Declare to this create() method and call it, saving the result in a Ptr.

Declare Function create Lib "com.example.utility.counter" () As Ptr
Var counter As Ptr = create

Instead of using a shared factory method, you can also call the Class constructor using this syntax:

Declare Function counter Lib "com.example.utility.counter" () As Ptr

Because the function name has the same name as the class itself, this will call the constructor of the class.

When you want to call a method on the instance, you pass the instance as a Ptr. First, Declare to the method adding “.instance” to the library location to indicate you are calling a class instance.

Declare Function increment Lib "com.example.utility.counter.instance" (ref As Ptr) As Integer

Then you can call the method and save its value.

Var count As Integer = increment(counter)

The reference as the Ptr must be the first parameter passed in the Declare. Follow it with other parameters as usual.

You can also call instance methods directly in the Android API in this manner.

Method Callbacks

There are Android APIs that use callbacks to methods that you provide. In Xojo these methods are Delegates and are methods that you supply using AddressOf. It is very important that the signature of this method exactly matches what the callback expects which means you’ll be limited to just the Boolean and Ptr types.

If you want to use an API that uses its own callbacks, you’ll be better served by creating a Library and having the API do the callback to your own Library methods, which you can then call back to your Xojo methods.

You can pass the reference to the Xojo method using AddressOf like this:

Var cb As Ptr = AddressOf TestCallback
Declare Sub xojocallback Lib "com.example.utility.callback" (cb As Ptr)
xojocallback(cb)

The Xojo method can only use parameter types of Boolean and Ptr. It looks like this:

Public Sub TestCallback(b As Boolean, i As Ptr, s As Ptr)

In the Kotlin library you have to cast the incoming parameter to a function reference. This is a two-step process where you verify the function has the correct number of parameters and then you cast it to the specific parameter types. Sample code:

if (cb is Function3<*, *, *, *>) {
    try {
         (cb as Function3<Boolean, Long, String, Unit>).invoke(true, 42, "Hello")
         println("Sent callback to Xojo")
    } catch (e: ClassCastException) {
         println("Casting failed: ${e.message}")
    }
}

The “Function3” indicates a function with 3 parameters (the last “*” indicates the return type), but you can change that as needed using Function1, Function2, etc. You can pass anything back through a Ptr type, but the Xojo code has to convert them using Ptr methods so you should not change the types of the values you send back to be different than what your Xojo code expects.

Object Declares

Object Declares are not new, but for completeness are described here. Essentially an Object Declare uses special syntax to Declare to a UI control.

The typical way to use an Object Declare is by adding an Extends method to a Module. For example, an extension method to allow MobileButton to change its colors could look like this:

SetBackColor(Extends ctrl As MobileButton, c As Color)

The Object Declare looks like this:

Declare Sub setBackgroundColor Lib "Object:ctrl:MobileButton" (myColor As Int32)
setBackgroundColor(c.ToInteger)

Breaking this down, we’re calling the setBackgroundColor function. The Lib denotes this new type of Object declare: an Object, separated by a colon, the Xojo name of the object (in this case, our “ctrl” parameter), followed by another colon, and the Xojo type of the object.

Kotlin Declares

You can use the Android-specific “Kotlin” Declare designation to indicates that what is specified in the Alias section of the Declare should be used as is. This is particularly helpful when you want to cast Ptr values to a specific type for use with OS APIs.

This code gets a ColorStateList object for a Xojo Color value:

Var c As Color = Color.Blue

Declare Function valueOf Lib "android.content.res.ColorStateList:Kotlin" Alias _
"android.content.res.ColorStateList.valueOf(android.graphics.Color.argb(alpha.toInt(), r.toInt(), g.toInt(), b.toInt()))" _
(alpha As Int32, r As Int32, g As Int32, b As Int32) As Ptr

Var csl As Ptr = valueOf(255 - c.Alpha, c.Red, c.Green, c.Blue)

This code can then be used to call setStrokeColor on a MobileButton:

Declare Sub import Lib "android.content.res.ColorStateList:Import" // Imports the ColorStateList class

Declare Sub setStrokeColor Lib "Object:ctrl:MobileDateTimePicker:Kotlin" Alias "setStrokeColor(strokecolor as ColorStateList)" (strokeColor As Ptr)
setStrokeColor(csl)

As you can see, in the Alias is the Kotlin method call that casts the incoming Ptr value to a ColorStateList.

Import

Note the “import” declare in the code snippet above. This is also specific to Android. This Declare indicates that a specific class should be imported so that it can be used for casting purposes. If you left off that import, then the cast to ColorStateList would cause a compile error because ColorStateList would not be known.

You only need to import a specific class once. After you’ve done so it can be referenced by any other Declare, even ones in different methods.

The use of an import Declare is optional and is meant to simply the Kotlin method call code in the Alias. Instead of using import you can specify the full class path in the cast like this:

Declare Sub setStrokeColor Lib "Object:ctrl:MobileDateTimePicker:Kotlin" Alias "setStrokeColor(strokecolor as android.content.res.ColorStateList)" (strokeColor As Ptr)
setStrokeColor(csl)

Handles

Many classes in the framework now have Handle properties (or methods) which you can use with various Declare techniques described above. These include: FolderItem, Font, GraphicsPath, Locale, TimeZone, Graphics, Picture. In addition, the mobile controls have Handle properties that can serve as an alternative for an Object Declare.

Sample Project

You can download the sample project that demonstrates a library and some of the concepts described above. You can use this as a template or starting point for creating your own libraries or Declares.

Sample Utility Library Project

You might also want to take a look at the Android Design Extensions open source project, which has hundreds of Declares that can enhance your Android apps.

References

• Android Libraries blog post
• Android Declares blog post

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

The focus of this release was on the integration of pictures in controls, such as MobileButton, MobileDateTimePicker, MobileTextFields, MobileSlider etc.

Let’s take a look at some new possibilities using examples.

Create a MobileButton with a Picture

This is a feature that is in demand in Xojo Issue Tracker and has not yet found its way into the Android framework. So let’s just do it ourselves with the help of the Android Design Extensions.

Create a new Android project. Now copy the Android Design Extensions folder into the project or drag and drop it into the Navigator. Now select Screen1 in the Navigator and add a MobileButton – Button1 – and give it the Opening event. Add the following code to the Opening event:

Me.SetIconXC(SaveSystemImage("camera")) 
Me.SetIconGravityXC(IconGravity.TextStart)

SaveSystemImage is an extension method that returns a FolderItem and saves a Picture.SystemImage with the specified name (here „camera“) in the Documents folder. Why? Xojo Declares do not support Picture as a data type and therefore we have to take the detour and save images once in order to load them into controls via the file path.

You can of course also use any other image and are not restricted to Picture.SystemImage. All Android Design Extensions extension methods that have to do with the display of pictures are prepared for this and expect a FolderItem as a parameter, which must of course be a picture (PNG, JPEG etc.).

SetIconGravityXC ensures that the Picture is displayed in front of the button text. And that’s all there is to it. Execute the project and you have a button with an image.

Tip: If you create a MobileButton subclass, you can cache the FolderItem via Static to create the image file only once. Of course, this only applies to the fact that all button instances of this subclass should always display the same image.

To see how to add an image to a MobileScreen, MobileSlider or MobileSwitch, simply take a look at the Android Design Extensions sample app.

TabPanel Badge Extension

MobileTabPanel tabs now also support text badges. How is it done?

Add a MobileTabPanel – TabPanel1 – to your project and add the Opening event to it with the following code:

Me.SetBadgeTextAtXC(0, "Exclusive")

And that’s all there is to it. The result is as follows:

There are other MobileTabPanel extension methods with which you can customize the badges (color, position, etc.). Give it a try!

TextFields on a New Level

TextFields can also be enhanced with the new Android Design Extensions version.

The SetBoxCornerFamilyXC call now offers the option of choosing whether you want rounded or flattened corners. You can also use SetCursorColorXC to define the color of the cursor for each individual TextField.

TextFields can now also have leading or trailing icons. The helper methods for this are SetStartIconXC and SetEndIconXC, which in turn expect a FolderItem (Picture) as a parameter.

There are many other new declares. Have a look here too.

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library.

I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples here.

Happy Coding.

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

Although Xojo for Android does not yet have full dark mode support, things continue to head in that direction. Previously your app would adjust its UI for light/dark if the Support Dark Mode property was turned on in the Android Build Settings. Starting in Xojo 2023r3, Color.TextColor and Color.FillColor also adjust their values when run in light mode or dark mode, making it easier for your custom drawing to also adapt.

MobileTextField gets a couple new additions. The ReturnPressed event is now called when, as the name suggests, return is pressed. The AllowSpellChecking property is now also available for MobileTextField and MobileTextArea.

In the Shared Build Settings Inspector there is now a Destination property as there is with other platforms.

Many Android devices have physical back buttons and all let you turn on global software controls that have a back button, but sometimes you want to have the back button clearly shown on the navigation toolbar. With Xojo 2023r3, the new HasBackButton property of MobileScreen can show a back button on the navigation toolbar.

To make it easier to write code that is applicable to both iOS and Android, but not other platforms, there is a new TargetMobile constant available for conditional compilation.

MobilePopupMenu is an all-new control for Android that makes it possible to simplify some of your user interfaces. It works similarly to a PopupMenu on Desktop or Web: when the user taps this control a list of items appears and they can choose one.

On the Advanced tab of the Android Build Settings there is a new Manifest section with a Permissions property. Here you can specify the names of Android permission constants that are needed by Declares or libraries. They are added to the AndroidManifest.xml file when the app is run/built.

MobileHTMLViewer got several enhancements. It now has various processing events, including: DocumentBegin, DocumentComplete, CancelLoad, Error, NewWindow, DocumentProgressChanged and TitleChanged.

And there is now support for running JavaScript using the ExecuteJavaScript method along with the JavaScriptResult and JavaScriptRequest events. ExecuteJavaScript is asynchronous and results appear in the JavaScriptResult event. To call the JavaScriptRequest event, use xojo.execute() in the JavaScript code. A method name and up to 5 parameters can be passed back to Xojo. Learn more in the Xojo Programming Documentation.

The last thing I want to highlight is the new Kotlin Declare. For advanced users, this adds the ability to create Android declares that can pass untouched calls via Alias (with the exception of required type/object handling) to the Kotlin compilation step. This is done by specifying Lib “Kotlin” or adding “:Kotlin” to the end of Lib. Here are a couple examples of what this can look like:

Declare Function AndroidVersion Lib "Kotlin" Alias "android.os.Build.VERSION.RELEASE" As CString

Declare Sub findAllAsync Lib "Object:ctrl:MobileHTMLViewer:Kotlin" Alias "findAllAsync(myfind.toString())" (myFind As CString)

Of course there were many bug fixes as well. Be sure to check out the full release notes for all the details.

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.

• Declares for the new MobilePopupMenu
• Declares for MobileMoviePlayer
• Extensions for all MobileUIControl subclasses
• New extensions for AndroidMobileTable
• New extensions for MobileScrollableArea
• New extensions for MobileSwitch
• New extensions for MobileTabPanel
• New extensions for MobileTextArea
• New extensions for MobileTextField

Use MobilePopupMenu to Display it in Other Controls

The new MobilePopupMenu is a nice new addition to Xojo’s Android control library. Wouldn’t it be nice to display the popup menu when clicking on a Button or Canvas as well? With the Android Design Extensions you can achieve this.

1. Create a new Android project
2. Import the Android Design Extension folder into your project
3. Add a MobilePopupMenu (PopupMenu1) from the library to Screen1
4. Add some entries to the PopupMenu1 in the Inspector in the InitialValue section (say “Apple”, “Banana”, “Peach”)
5. Set the Visible property of the PopupMenu1 to False
6. Add a MobileButton (Button1) from the library to Screen1 and place it over the “invisible” PopupMenu1
7. Add the Pressed-Event to Button1 with the following code:

Call PopupMenu1.PerformClickXC

8. Add the SelectionChanged-Event to the PopupMenu1 with the following code:

Button1.Caption = Me.SelectedRowText

9. Run your project by clicking Run.

You can use this technique with any control that you want to have a popup menu. For example, in a Canvas you would use the PointerDown-Event.

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library.

I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples here.

Happy Coding.

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

To create an Android library you will need to use Android Studio, which you should already have installed as its compiler toolchain and SDK are required by Xojo.

Create a New Android project (File->New->New Project), choosing “No Activity” from the Phone and Tablet section.

You should be sure to choose Kotlin as the language and the Minimum SDK should be 26 to match what Xojo uses. For this example, I’ve named the project “LibraryTest”.

In this project, add a module (File->New->New Module), choosing the “Android Library” template. Here you can name your library, choose the language, etc. Again, stick with Kotlin.

I’m naming the library “utility” so that it can contain a random collection of things.

In the Android Studio navigator, expand the utility library and then the java folder. Yes, it is weird that Kotlin code is in a Java folder, but a lot about Android Studio is weird to me.

Right-click on “com.example.utility” and select New->Kotlin Class/File. In the selector, choose “Class” and type the name of the class as “regex” and press return. In this class will be a method to do some simple regex pattern matching.

This creates an empty class:

package com.example.utility
class regex {

}

Currently Xojo can only talk to methods in the companion class. These methods are similar to Shared methods in Xojo and work without creating a specific class instance.

In the class, add the companion object so that it looks like this:

package com.example.utility

class regex {

    companion object {

    }

}

Inside the companion object, add a method that will do simple regex pattern matching. Your code now looks like this:

package com.example.utility

class regex {

    companion object {

        fun regexmatch(regex: String, text: String): Boolean {

            // Use the regex pattern
            val pattern = Regex(regex)

            // Returns true if it matches, false if it does not.
            return pattern.matches(text)
        }

    }

}

The last step is to change the Kotlin version to match the version Xojo uses. In the Android Studio navigator, open Gradle Scripts and double-click “build.gradle (Project: LibraryTest)” to open it.

Change the last line with the kotlin.android version from whatever is there to “1.6.20”:

// Top-level build file where you can add configuration options common to all sub-projects/modules.

plugins {
    id 'com.android.application' version '8.0.2' apply false
    id 'com.android.library' version '8.0.2' apply false
    id 'org.jetbrains.kotlin.android' version '1.6.20' apply false
}

Note: You may be prompted to do a Gradle sync after making this change. Go ahead and do the sync if prompted.

The last thing to do in Android Studio is to build the library. From the Build menu, choose “Select Build Variant”. In the Build Variants panel that appears, click on the Active Build Variant value for the utility row and change it from debug to release.

Select Build->Rebuild Project to build the library file that Xojo will use.

In your file system, go to your project’s location and fine the aar file, which is located here: LibraryTest/utility/build/outputs/aar/utility-release.aar Make a note of this as we will be using it with Xojo in a moment.

Speaking of Xojo, create a new Xojo Android project and name it LibraryTest. Add a button and a table like so:

In the button’s pressed event, write the Declare statements to call the regexmatch method in the library, passing it a regex pattern and a string to test. Here is the code, which tests three strings and outputs the result to the table:

Declare Function regexmatch Lib "com.example.utility.regex" (pattern As CString, value As CString) As Boolean

// Look for g, followed by any number of "ee" pairs and ending with ks
Var pattern As String = "g([ee]+)ks?"
Var result As Boolean
Var values() As String = Array("geeks", "geeeeeeeeeeks", "geeksforgeeks")

For Each v As String In values
  result = regexmatch(pattern, v)
  Table1.AddRow(v, result.ToString)
Next

// From: https://www.geeksforgeeks.org/kotlin-regular-expression/

The important thing to note in this code is the use of CString in place of String, a requirement when working with a Declare even if it doesn’t directly apply to Android.

Also note that you need to provide the full path to the class. You have to use “com.example.utility.regex”, not just “regex”.

The next step is to add the Library to the Xojo project. Select Android in the Build Settings and add a Copy Files Build Step (Insert->Build Step->Copy Files).

Expand Android and click on CopyFiles1. Rename it to LibCopy and drag it so that it is before the Build entry. Change the Destination to “Framework Folder”.

Add the library that we built with Android Studio to this LibCopy step. Click “+” in the command bar and locate utility-release.aar.

Note: If you still have Android Studio open at this point, you should close it, otherwise it will lock debugger access and prevent the Xojo app from starting.

Pro Tip: You can keep Android Studio open and run from Xojo by choosing this preference setting: Build, Execution, Deployment -> Debugger -> Use existing manually managed server. You’ll want to set it back to “Automatically start and manage the server” if you use Android Studio for anything else. Constantly flipping that setting is common when working with Android libraries.

Run the project. If you did everything correctly, it should launch on your device or emulator. Click the button to see the output which should look like this:

With libraries you can add your own extensions to Xojo’s Android support. You are limited to simple types at the moment, but that still opens up a lot of capabilities. This capability will continue to be expanded through the Android beta.

Feel free to share any Kotlin libraries you create in the Android topic of the forum.

Download this Example RegEx Library

Here is another simple Library you can download and examine.

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.

First, let’s just get the Android version number, the kind a user might see if they were looking for what version of Android they were running on. As with any Declare, we first look up the call in the platform documentation. For Android, that is typically here: https://developer.android.com/reference/

After searching the platform docs, we find out how to get the version here: https://developer.android.com/reference/kotlin/android/os/Build.VERSION

The “Lib” section of the Declare will contain the “path” up to the function/property that we want to get the value. We get this from that page as:

android.os.Build.VERSION

The actual property we want is called “RELEASE” (“The user-visible version string.”) and since we want our Declare function to be called something different, we’ll set that as an alias.

In summary, the full Xojo Declare to get the Android version would be:

Declare Function AndroidVersion Lib "android.os.Build.VERSION" Alias "RELEASE" As CString

We use “CString” for any String coming from the Android platform for both ease of use and Declare compatibility – even though the String type from the platform may vary internally, you do not need to worry about that.

You can find this Declare in the Examples section of Xojo in the Platform>.Android>Declare>Declare project.

Object Declares

With Android, there is a special new Declare format that allows us to make calls directly against certain objects and controls. This comes in handy if we want to easily make a Declare that changes the property of a control. As an example, let’s set the background color of a MobileButton.

The typical way to use this new type of Object Declare is by adding an Extends method to a Module. Since we want to extend MobileButton with the ability to change its color, we’ll put a method on a Module called “SetBackColor” with the following parameters: “Extends ctrl As MobileButton, c As Color”

We look through the platform docs again, and learn that in Android, a Button is considered a View and thus has the following method: https://developer.android.com/reference/kotlin/android/view/View#setBackgroundColor(kotlin.Int)

We don’t need an Alias this time since the extension method is what we’ll call in Xojo code. What we’ll do instead is make the Declare like this:

Declare Sub setBackgroundColor Lib "Object:ctrl:MobileButton" (myColor As Integer)

Breaking this down, we’re calling the setBackgroundColor function. The Lib denotes this new type of Object declare: an Object, separated by a colon, the Xojo name of the object (in this case, our “ctrl” parameter), followed by another colon, and the Xojo type of the object.

The next and final line of our extension method will actually call the declared function:

setBackgroundColor(c.ToInteger)

You can see this Declare and its helper method in action from the Examples section of Xojo in the Platforms>Android>Declare>ButtonBackgroundColor project.

We’ve already seen users using Declares to extend their Android projects during our pre-release phase, and some are planning to make Declare projects available to everyone in the future to make using them even easier!

Travis got started with computers as a kid with a TI-99/4A. He moved on to the original Macintosh when it was released and has been programming ever since. He’s been using Xojo in various ways since v3 back in 2001. When not programming he’s usually found playing around with VR, music, games, or watching a good show.

Developers, myself included, love maximizing the potential of their projects and often desire extended access to features that Xojo does not initially provides in their framework, or even features that are not available at all. This can be remedied by using Declares, which are available in Android, as well as in all other project types (Desktop, Console and iOS). The usage may differ slightly from other platforms, but once you grasp its nuances, it becomes just as intuitive.

To make it easier for Xojo developers who are taking their first steps with the Android platform and would like to get more extensions and accessibility, I have created the Android (Design) Extensions modeled after the iOS Design Extensions provide by Xojo MVP Jérémie Leroy. They are extension methods for all controls and classes supported in the Android project type. At the moment the project offers 440+ extensions and that should be good for a start.

Check out this short video of the demo application to see some of the uses of Android (Design) Extensions:

For example, you can add currently missing functionalities for Android MobileHTMLViewer such as GoBack or GoForward, just to name a few.

The project has been customized to support both light and dark modes, offering you an optimized solution for Android projects right from the start, until Xojo implements automatic light/dark mode support for Android.

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library.

I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples here.

Happy Coding.

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

My new path has taken me deep into the world of iOS and macOS and I thought I would create some projects & products which would benefit Xojo apps on those platforms by creating some products which expose some of the larger frameworks which are not already available but also cannot be accessed by declares alone…

WeatherKit

About the time that Apple ended support for the Dark Sky API, forcing users to transition to their WeatherKit Rest API, I was thinking about an iOS project which would benefit from having access to the phases of the moon and barometric pressure on a historical basis. After a bit of research, I found that Apple’s WeatherKit framework was well-suited for the purpose, but found that it was a Swift-only framework and accessing it from Xojo was going to be challenging. I proceeded to create an obj-c bridge framework and a set of Xojo classes to make it available to everyone.

What resulted is a framework which currently provides developers access to the WeatherKit framework as well as some helper tools for:

• Location Geocoding, because WeatherKit requires Latitude/Longitude and humans don’t remember locations that way.
• Unit Conversion, for the units that are used in WeatherKit.
• Multicolor Symbols, for a quick and easy way to access the multicolor SFSymbols which are provided by Apple for weather.

You can read more information about this framework and download a demo from here, and it can be purchased from Xojo’s Extras Store.

Multipeer Connectivity

Another framework which caught my eye was MultipeerConnectivity. This framework allows you to make connections with up to 8 macOS and/or iOS devices simultaneously for use in games or business applications with multiple communicating workstations. It offers both automatic user-driven and manual programmatic device discovery as well as a few data transfer mechanisms. macOS devices use Wi-Fi and/or Ethernet and iOS devices use Wi-Fi and/or Bluetooth. Network selection is completely automatic so once the connection has been established, all your app needs to do is send data back and forth and disconnect when it’s done.

My port of the framework gives you access to nearly the whole framework, short of creating a direct socket connection between two devices, but text and file transfers are both implemented and working just fine. I was even able to transfer a 130MB file from a Mac to an iPhone in about 16 seconds.

You can read more information about this framework and download a demo from here, and it can be purchased from Xojo’s Extras Store.

Free Stuff

I also have several Github repos and a number of free xojo-related items available, including my Profile Triage tool for helping developers figure out why they get errors when trying to sign or notarize their apps. You can see that list on my site here.

More on the horizon…

There’s more to come. I have some other products which I think will benefit Xojo iOS and macOS projects in the future, so watch for posts on the Xojo forum!

Greg O’Lone spent eleven years as a member of the Xojo engineering team from 2011 through 2022. During his time at Xojo he worked on many of the parts of the product that make Xojo what it is today – from the IDE and iOS Framework to Xojo Cloud and both of the Web Frameworks. You can learn more about Greg and what he’s creating now at his website.

Quick Look is the Apple technology in charge of creating icons and thumbnails based on a file contents. With Quick Look, the user can get a more precise preview of the contents stored in the selected file without having to open it.

You can retrieve this kind of information in your macOS Xojo Desktop apps using the Declare feature of the Xojo language, as we already have seen in other blog posts. As you probably already know, Declares give you the ability to, well, “declare” from Xojo any call to functions or methods provided by external APIs and libraries as it is the case with the Frameworks available in the macOS operating system itself.

Once we have “declared” these kind of functions from Xojo code, they will be ready to be used when calling any of your own defined methods or any of the methods directly available from the Xojo classes.

You can download the Xojo Project file from this link.

We will start by adding a new method to a Module in a Xojo Desktop project using the following method signature:

• Method Name: IconForFile
• Parameters: Extends f As FolderItem, tSize As Size, Optional QuickLookIcon As Boolean = True
• Return Type: Picture
• Scope: Global

If you are new to coding in Xojo, then probably you’ll be wondering what “Extends” means in the signature method. In brief, that means that the method will be treated as a method for the data type (or class) included next to the defined parameter; in this case the FolderItem.

The main convenience of extended class methods is that your code will be more readable and you’ll be able to call the method on a data type instance using the dot notation. So, instead of using the following syntax:

Var f As FolderItem = FolderItem.ShowOpenFileDialog("")
Var tSize As New Size
tSize.Height = 128
tSize.Width = 128

var p As Picture = IconForFile(f, tSize) // IconForFile as a regular method definition

We are able to call the method this way:

Var f As FolderItem = FolderItem.ShowOpenFileDialog("")
Var tSize As New Size
tSize.Height = 128
tSize.Width = 128

var p As Picture = f.IconForFile(tSize) // IconForFile as an extended method for the FolderItem class

Notice as the second chunk of code is calling the method using the dot notation on the FolderItem instance referenced by the f variable and how, in that case, we don’t need to provide the FolderItem variable as one of the parameters in the method call.

The second thing you’ll probably find of interest in the method definition is the use of the Optional keyword. We include that keyword in the method signature to indicate that such parameter is… well… optional; that is, you can provide the parameter in the method call or not. In fact, in the previous code snippets you might have noticed the last parameter was omitted in the method call.

In addition, we can also provide a default value for our Optional parameter; that is the value that will receive the method if we don’t provide a value of our own. In our method definition we are setting the QuickLookIcon parameter to the default Boolean value True.

Getting a Quick Look Icon… and a Regular one

With our method just added, the next step is to type in the associated Code Editor the code that will be executed when we call it. As you can see, we are using a lot of Declares here from several macOS frameworks. I have added a brief commentary about their tasks on each one of these, plus a link to the associated documentation webpage on the Developers area from Apple web, so you can continue learning or digging into their functionality and, specially, the parameters and return types declared in their original signatures so you can compare how these are translated or matched from Objective-C when declared in Xojo code.

#If TargetMacOS Then

  #Pragma DisableBackgroundTasks
  #Pragma DisableBoundsChecking
  #Pragma NilObjectChecking False

  If f = Nil Or Not f.Exists Then Return Nil

  Var path As String = f.NativePath

  // Declare for allocating (reserving memory for) an Objective-C object
  // https://developer.apple.com/documentation/objectivec/nsobject/1571958-alloc/
  Declare Function Alloc Lib "Foundation" Selector "alloc" (classRef As ptr) As ptr

  // Declare for autoreleasing (freeing from memory) an Objective-C object
  // https://developer.apple.com/documentation/foundation/nsautoreleasepool/1807021-autorelease/
  Declare Sub AutoRelease Lib "Foundation" Selector "autorelease" (classInstance As ptr)

  // Declare for getting a reference to an Objective-C class based on the received String
  // https://developer.apple.com/documentation/foundation/1395135-nsclassfromstring?language=objc
  Declare Function NSClassFromString Lib "Foundation" (className As CFStringRef) As ptr

  // Declare for getting a reference to the shared Workspace of macOS process.
  // https://developer.apple.com/documentation/appkit/nsworkspace/1530344-sharedworkspace/
  Declare Function sharedWorkSpace Lib "AppKit" Selector "sharedWorkspace" (classObject As ptr) As ptr

  // Declare for getting the Icon object from the recived file path
  // https://developer.apple.com/documentation/appkit/nsworkspace/1528158-iconforfile/
  Declare Function iconForFile Lib "AppKit" Selector "iconForFile:" (instanceObject As ptr, path As CFStringRef) As ptr

  // Declare for setting the size of an NSImage
  Declare Function setSize Lib "AppKit" Selector "setSize:" (instanceObject As ptr, size As NSSize) As ptr

  // Declare for Lock and Unlock an NSImage in Objective-C
  // https://developer.apple.com/documentation/appkit/nsimage/1519891-lockfocus?language=objc
  // https://developer.apple.com/documentation/appkit/nsimage/1519853-unlockfocus?language=objc
  Declare Sub LockFocus Lib "AppKit" Selector "lockFocus" (imageObj As ptr)
  Declare Sub UnlockFocus Lib "AppKit" Selector "unlockFocus" (imageObj As ptr)

  // Declare for getting a new Bitmap Representation based on the Locked view
  Declare Function InitWithFocusedView Lib "AppKit" Selector "initWithFocusedViewRect:" (imageObj As ptr, rect As NSRect) As ptr

  // Declare for getting an NSData object with the specified image format from a Bitmap Representation
  // https://developer.apple.com/documentation/appkit/nsbitmapimagerep/1395458-representationusingtype/
  Declare Function RepresentationUsingType Lib "AppKit" Selector "representationUsingType:properties:" (imageRep As ptr, type As UInteger, properties As ptr) As ptr

  Var targetSize As NSSize
  targetSize.Width = tsize.Width
  targetSize.Height = tsize.Height

  Var tRect As NSRect
  tRect.Origin.x = 0
  tRect.Origin.y = 0
  tRect.RectSize = targetSize

  Var data As ptr

  If QuickLookIcon Then

    //=================
    // Let's try to retrieve the icon from Quick Look

    Var dictClass As ptr = NSClassFromString("NSDictionary")
    Var numberClass As ptr = NSClassFromString("NSNumber")

    // Declare for getting an NSNumber object from the received Boolean value
    // https://developer.apple.com/documentation/foundation/nsnumber/1551475-numberwithbool/

    Declare Function NSNumberWithBool Lib "Foundation" Selector "numberWithBool:" (numberClass As ptr, value As Boolean) As ptr
    Var numberWithBool As ptr = NSNumberWithBool(numberClass, True)

    // Declare for getting an NSDictionary object from the received Key and Value
    // https://developer.apple.com/documentation/foundation/nsdictionary/1414965-dictionarywithobject/

    Declare Function NSDictionaryWithObject Lib "Foundation" Selector "dictionaryWithObject:forKey:" (dictClass As ptr, value As ptr, key As CFStringRef) As ptr
    Var dictInstance As ptr = NSDictionaryWithObject(dictClass, numberWithBool,"IconMode")

    Var fileClass As ptr = NSClassFromString("NSURL")

    // Declare for getting an NSURL object from the received path as string
    // https://developer.apple.com/documentation/foundation/nsurl/1410828-fileurlwithpath/

    Declare Function NSFileURLWithPath Lib "Foundation" Selector "fileURLWithPath:" (fileClass As ptr, path As CFStringRef) As ptr
    Var fileInstance As ptr = NSFileURLWithPath(fileClass, f.NativePath)

    // Declare for getting the Quick Look based icon thumbnail for the received file and with the specified size
    // https://developer.apple.com/documentation/quicklook/1402623-qlthumbnailimagecreate?language=objc

    Declare Function QLThumbnailImageCreate Lib "QuickLook" (allocator As Integer, file As ptr, size As NSSize, dictRef As ptr) As ptr
    Var imageRef As ptr = QLThumbnailImageCreate(0, fileInstance, targetSize, dictInstance)

    If imageref <> Nil Then

      Var BitmapImageRepClass As ptr = NSClassFromString("NSBitmapImageRep")
      Var BitmapImageRepInstance As ptr = Alloc(BitmapImageRepClass)

      // https://developer.apple.com/documentation/appkit/nsbitmapimagerep/1395423-initwithcgimage/

      Declare Function CGInitWithCGImage Lib "AppKit" Selector "initWithCGImage:" (bitmapInstance As ptr, CGImage As ptr) As ptr
      Var BitmapImageRep As ptr = CGInitWithCGImage(BitmapImageRepInstance, imageRef)

      data = RepresentationUsingType(bitmapImageRep, 4, Nil) // 4 = PNG

      AutoRelease(BitmapImageRep)
      AutoRelease(imageref)

      // Getting Xojo Picture instance from NSData object
      Var p As Picture = NSDataToPicture(data)

      data = Nil
      numberWithBool = Nil
      fileInstance = Nil
      dictInstance = Nil
      BitmapImageRepInstance = Nil
      Return p

    End If
  End If

  // If we reach this point is because there is no way to retrieve the
  // Quick Look icon for the file, it has returned a non valid object,
  // or we received the optional QuickLookIcon param set to False,
  // so we fallback to the regular one (FileType based).

  Var WorkSpace As ptr = NSClassFromString("NSWorkspace")
  Var sharedSpace As ptr = sharedWorkSpace(WorkSpace)
  Var icon As ptr = iconForFile(sharedSpace, path) // We get NSImage here

  Var resizedIcon As ptr = setSize(icon, targetSize)

  // Getting bitmap image representation in order to extract the data as PNG.

  LockFocus(resizedIcon)

  Var NSBitmapImageRepClass As ptr = NSClassFromString("NSBitmapImageRep")
  Var NSBitmapImageRepInstance As ptr = Alloc(NSBitmapImageRepClass)
  Var newRep As ptr = InitWithFocusedView(NSBitmapImageRepInstance, tRect)

  UnlockFocus(resizedIcon)

  data = RepresentationUsingType(newRep, 4, Nil) // 4 = PNG

  // Getting Xojo Picture instance from NSData object
  Var p As Picture = NSDataToPicture(data)

  data = Nil
  icon = Nil
  AutoRelease(newRep)

  Return p

#EndIf

As you can see, all the code is wrapped into a compilation conditional #If… #EndIf block. This means that the code will be compiled only if the condition is evaluated as true. In this case, it will compile only when we try to compile a desktop app for macOS as stated with the TargetMacOS keyword.

Next, we will use three #Pragma directives to speed things up a bit. In this case the pragma disable the tasks in the background, checking bound in collections like the Arrays and checking instances set to Nil, but only during the method execution, after which things return to their original settings.

The remaining code includes comments so you can see what happens at the more important points; for example whether to retrieve the Quick Look icon associated with the file or the regular one based on the file data type.

You’ll have probably noticed that we called a second method: NSDataToPicture. This method will be in charge of converting the data from an Objective-C NSDATA object to a Xojo Picture, using the technique used in previous blog posts (here and here). In this case we included it as a method call to avoid the duplication of code.

Let’s add a second method to our Module using the following values:

• Method Name: NSDataToPicture
• Parameters: data As Ptr
• Return Type: Picture
• Scope: Protected

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

Declare Function DataLength Lib "Foundation" Selector "length" (obj As ptr) As Integer
Declare Sub GetDataBytes Lib "Foundation" Selector "getBytes:length:" (obj As ptr, buff As ptr, len As Integer)

Var dlen As Integer
Var mb As MemoryBlock
Var mbptr As ptr

// Getting image data to generate the Picture object in the Xojo side
// We need to get the length of the raw data…
dlen = DataLength(data)

// …in order to create a memoryblock with the right size
mb = New MemoryBlock(dlen)
mbPtr = mb

// And now we can dump the PNG data from the NSDATA objecto to the memoryblock
GetDataBytes(data, mbPtr, dlen)

// In order to create a Xojo Picture from it
Return Picture.FromData(mb)

Adding Required Structures

As in previous tutorials dealing with Declares, we need to add several structures to the Module; these are required when calling to some of the declared functions in the IconForFile method. The required structures are:

• Structure NSOrigin
  X As CGFloat
  Y As CGFloat
• Structure NSSize
  Height As CGFloat
  Width As CGFloat
• Structure NSRect
  Origin As NSOrigin
  RectSize As NSSize

Creating the User Interface

We have prepared for retrieving the file icons on macOS, let’s continue creating a user interface for the app so we can test how it works! The final user interface will look like this:

Click on the Window1 window in the Navigator panel; that will display the window in the Layout Editor. With Window1 selected, go to the associated Inspector Panel and change the following properties:

• Name: MainWindow
• Title: Icon File Viewer

Next, with the MainWindow item still selected and displayed in the Layout Editor, drag a Button control from the Library and drop it in the top-left area of the window in the Layout Editor (you can rely on the displayed alignment guides to position the control).

With the button selected in the Layout Editor, change the following values in the associated Inspector Panel:

• Name: SelectFileBt
• Locking: Top and Left closed (locked)
• Caption: Select File

Return to the Library, drag a Label control and position it just under the button in the Layout Editor. Use the associated Inspector Panel to change the following values:

• Name: IconSizeLB
• Locking: Top and Left closed (locked)
• Text: Icon Size:

Drag a Slider control from the Library and position it just to the right of the label. Drag the right corner of the Label handler in the Layout Editor to change its width so it reaches the right margin of the window. Use the associated Inspector Panel to change the following values:

• Name: IconSizeSL
• Locking: Top, Left and Right closed (locked)
• Line Step: 32
• Allow Live Scrolling: Enabled
• Page Step: 32
• Tick Mark Style: Bottom Right
• Value: 128
• Minimum Value: 32
• Maximum Value: 1024

Once again, drag a CheckBox control from the Library and position it just below the Label in the Layout Editor. Use the associated Inspector Panel to change the following values for the CheckBox:

• Name: QuickLookCB
• Locking: Top and Left closed (locked)
• Caption: Quick Look Preview
• Visual State: Checked

The last control we need to add is an ImageViewer. Drag the control from the Library and position it just below the CheckBox. Use the ImageViewer resizing handlers in the Layout Editor so its width and height matches the right and bottom alignment guides in the window. Then, use the associated Inspector Panel to set the following values:

• Name: IconPreviewIV
• Locking: Top, Left, Right and Bottom closed (locked)

Adding Functionality to the User Interface

Let’s add the code to execute when the user interacts with certain controls. With the SelectFileBt button item selected in the Navigator or the Layout Editor, use the contextual menu to add the Pressed Event to it. Then, type the following code in the associated Code Editor:

file = FolderItem.ShowOpenFileDialog("")
If file <> Nil Then
  FileNameLB.Text = file.Name
Else
  FileNameLB.Text = ""
End If
GetIconForFile

With the IconSizeSL slider control selected, use the contextual menu to add the ValueChanged Event to it, and type the following code in the associated Code Editor:

If Self.File <> Nil Then
  GetIconForFile
End If

With the QuickLookCB checkbox item selected, use the contextual menu to add the ValueChanged Event, and type the following line of code in the associated Code Editor:

GetIconForFile

As you can see, all of these events will call the getIconForFile method, so we need to add it to the MainWindow window using the following signature:

• Name: GetIconForFile
• Scope: Public

…and type the following snippet of code in the associated Code Editor:

If file <> Nil Then
  Var tSize As New Size
  tSize.Height = IconSizeSL.Value
  tSize.Width = IconSizeSL.Value

  IconPreviewIV.Image = file.IconForFile(tSize, QuickLookCB.Value)

End If

In the final step, add the File property (as FolderItem type) to the window, because this will be the one responsible for storing the reference to the FolderItem selected by the user when they click the SelectFileBt button.

Once the File property has been added, run the app, click on the Select File button and change the slider value to retrieve the icon for the file using a different size. Try to click in the checkbox to change the retrieved icon from the Quick Look view (enabled by default) to the kind of icon associated with that particular file type.

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.

For those of you that don’t consider reading through over 220 items as fun as I do, here are a few things I thought I would highlight, in no particular order.

• Desktop projects now save icon resources as compressed PNGs. This can greatly reduce binary/xml project file size and also reduce the .xojoresources file size in text projects. In the case of the Eddie’s Electronics sample project, the binary project dropped from 11MB to 780K, the XML project from 22MB to 1.1MB and the .xojoresources file from 11MB to 388K.

• Need to iterate through a String’s characters in a completely unicode-friendly way (including emojis)? Rather than using the String.Characters iterator, use the new String.Codepoints iterator which returns one value for each unicode scalar.

• You can now install Xojo on Windows ARM 64-bit. Xojo itself remains an Intel x86-64 binary, but Windows ARM has a translation system built-in that will allow Xojo to run. This should allow those of you using ARM Windows in a VM on an Apple Silicon Mac to use Xojo there. If you’re interested in native Xojo support for Windows ARM, subscribe to Feedback Case 62672 so you’ll be notified of updates.

• Auto-complete continues to get smarter and faster. It can’t quite write your code for you, but now it does a better job of substituting text and offering suggestions, among other things.

• The Code Editor has more improvements, particularly in the area of code folding. Another improvement is that you can use Go To Location to jump to a specific line in the code using “#50” (for example) in addition to the previously allowed “50”.

• For use with Declares, there is now an OSHandle class that can handle either an Integer or a Ptr.

• And although we mentioned it in another blog post, I’d still like to remind people that you can again build your Mac apps from Windows and Linux. Improvements in the open-source linker project used by Xojo allowed us to bring this feature back. Of course, please continue to test your Mac apps on an actual Mac before you ship them.

Create a new Desktop project in the Xojo IDE and add a new Module to it (for example, named External).

Next, add a new method to it using the following data in the associated Inspector Panel:

• Method Name: MetadataForImageFile
• Parameters: source As FolderItem
• Return Type: String
• Scope: Global

Now add the following snippet of code to the Code Editor for the just added method:

Var desc As String

#If TargetMacOS
  
  // Declares against the "Foundation" framework
  Declare Function NSClassFromString Lib "Foundation" (clsName As CFStringRef) As Ptr
  Declare Function FileURLWithPath Lib "Foundation" Selector "fileURLWithPath:" (obj As Ptr, path As CFStringRef) As Ptr
  Declare Function Description Lib "Foundation" Selector "description" (dict As Ptr) As CFStringRef
  
  // Declares against the "ImageIO" framework
  Declare Function CGImageSourceCreateWithURL Lib "ImageIO" (path As Ptr, options As Ptr) As Ptr
  Declare Function CGImageSourceCopyPropertiesAtIndex Lib "ImageIO" (imageSource As Ptr, index As Integer, options As Ptr) As Ptr
  
  If source <> Nil Then
    
    // Getting a Reference to the NSURL class
    Var nsurl As Ptr = NSClassFromString("NSURL")
    
    // Getting a reference to a NSURL object created from the given Path
    // for the source file
    Var filePath As Ptr = FileURLWithPath(nsurl, source.NativePath)
    
    // Getting a reference to the image object created from the 
    // given NSURL object
    Var imageRef As Ptr = CGImageSourceCreateWithURL(filePath, Nil)
    
    // Getting an NSDictionary containing the Metadata for the image
    Var dict As Ptr = CGImageSourceCopyPropertiesAtIndex(imageRef, 0, Nil)
    
    // Getting the contents of the NSDictionary instance as a String
    // This will contain the metadata for the image file!
    desc = Description(dict)
    
  End If
  
#EndIf

Return desc

Now you can call this method from your code in order to get a String containing the metadata information for the FolderItem passed to it as parameter.

You can find more information from Apple about the ImageIO Framework here. Ask me questions on Twitter @XojoES or on the Xojo Forum.

Such a loop might look like this:

Var xdcs() As String = Array("Orlando", "Austin", "Houston", _
"Las Vegas", "Denver", "Miami")

For Each city As String in xdcs
  Display(city)
Next

The Xojo Developer Conference, aka XDC, is the biggest Xojo event of the year. We’re looking forward to XDC London in October 2021.

Here is the code for the Display method:

Public Sub Display(it As String)
  ListBox1.AddRow(it)
End Sub

But what if you wanted to simplify things even further? Say you want to write code like this:

xdcs.ForEach(Display)

Is that even possible in Xojo? Yes, it mostly is, with a couple things called Extension Methods and Delegates.

To set this up, add a Module to your project and add a Delegate to the module. A Delegate is a type that is a method declaration. Here are its specifics:

• Delegate Name: ForEachString
• Parameters: it As String
• Scope: Global

Any actual method that matches this delegate signature is said to satisfy the delegate. If you look at the Display method above, you’ll see that it matches this delegate’s signature. So the Display method could be passed into a parameter of this delegate type.

In the same module, add a method. This will be an extension method on a string array. An extension method is a method that is called using dot notation on a specific data type (or class), even though it is not specifically part of the data type. This method also takes the delegate defined above as a parameter. Here are the method specifics:

• Method Name: ForEach
• Parameters: Extends stringArray() As String, action As ForEachString
• Scope: Global

Its code still uses For Each and calls the delegate like this:

For Each s As String In stringArray
  action.Invoke(s)
Next

Note: The above method and delegate are designed to work with String arrays. To work with other array types you’d need to add equivalent delegates and ForEach method overloads.

With these pieces now in place, this code (which is almost exactly what we wanted above — AddressOf is used to pass a reference of the Display method to the delegate) now works:

Var xdcs() As String = Array("Orlando", "Austin", "Houston", _
"Las Vegas", "Denver", "Miami")

xdcs.ForEach(AddressOf Display)

The above code is slightly shorter since it doesn’t need to declare the variable, but was this really worth all this this effort just for that? Well, perhaps not, but I think it’s cool and sometimes it’s fun to do stuff just because you can! Plus, it makes for a good excuse to learn about some more advanced Xojo features. Either way, I hope you found this interesting.

After a brief introduction welcoming attendees from 11 different countries, Geoff began the keynote by sharing some graphs showing how the Xojo community has been changing.

Along with a growing interest in Xojo, account creation is up 200%, we’ve seen a change in the demographics of our users. In 2017 only 22% of Xojo users were women. This year, that number has nearly doubled to 41%!

A few years ago, just under half of Xojo users were under 35. Now in 2019, 61% of our users are under 35.

This broader change is partially the result of current Xojo community members who evangelize Xojo on social media, blogs or simply in speaking with friends and colleagues. We know that word of mouth recommendations always carry more weight than any advertisement. Geoff took some time to recognize a few members of the Xojo community that have gone the extra mile to build this community. Hal Gumbert and Tim Dietrich, both Xojo developers from the FileMaker community, regularly blog and share on social media their experiences with Xojo. Also thanks is due to Thomas Templemann whose rally cry on the forum encouraged users to review Xojo on slant.co. What may appear to be small single actions all add up to make a difference. The stronger our community is, the better Xojo will be.

Next Geoff announced the winners of the Xojo Design Awards 2019, learn more more about these stellar examples of what has been done with Xojo!

Our team has been very busy over the last 12 months. Xojo has introduced 48 new features, made 75 changes and fixed 465 bugs. To name a few: we added Dark Mode for macOS, native labels in Windows, iOS Table pull to refresh and variable row heights, better text rendering on Windows, URLConnection in API 2.0, incremental compilation for 64-bit and ARM and significantly sped up the layout editor.

But we’ve also spent a lot of time working on some big, multiyear features so let’s take a look at where Xojo is going.

Xojo Cloud

Xojo Cloud is moving to 64-bit because the modern Linux distros are all 64-bit. Going forward, Named Hosts will allow you to point a domain at a specific app. We will be switching from CGIs to stand-alone apps to utilize modern web protocols and we are putting a load balancer in front of each app so you can easily handle more concurrent users.

Interops

If you don’t already know, Interops are basically a better way to make calls into OS APIs than declares. Interops require less code, remove the need to convert data between OS and Xojo types and are far easier to write. A quick example:

These four lines of declares connect to the EventStore database on your iOS device:

Just to connect to the eventstore, you’re dealing with a lot of very unfriendly stuff. However, with Interops this is reduced to one simple line that is friendly Xojo code:

Interops are already a real thing. We are using them internally in the iOS XDC app for both for calendar events and local notifications as well. We are also using them to build the Android framework.

IDE Update

We’ve been doing a lot of work behind the scenes on IDE improvements. You’ve seen some of this in 2019r1 with the layout editor.

With that completed, we’ve now reached the point where the new Home screen and improved workflow are coming soon.

API 2.0

API 2.0, is a set of APIs that will replace many of the existing ones, they will provide better consistency in naming, offsets and error handling. In some cases, we are taking the opportunity to modernize the implementation as well. You already saw this with URLConnection introduced in 2018r4. URLConnection replaced the old HTTPSocket that used a library that had to be updated. URLConnnection uses the underlying OSs’ library, so as those OSs get updated in order to provide better HTTP connections, your apps will automatically benefit. To name a couple more, API 2.0 supports Bezier Curves for all platforms, not just iOS. And the Date class has all the features we added to xojo.core.date, including: Locale support, DateInterval support and TimeZone support.

In most cases the APIs have not changed and not everything will be replaced. Those that are replaced will remain for many years so you don’t need to worry about rewriting your code right away. This change has gone faster than expected (yay, it does happen!) and we plan to be in beta after just a few more updates are made.

Web Framework 2.0

Last year we talked a lot about the design of Web 2.0, this year Geoff focused on implementation and the great progress made so far. As a way of testing out Web Framework 2.0, we decided to port something to the web using it. Since so many have asked for it over the years, we’re working on a web version of Feedback. It’s in the early stages and Greg will be demonstrating the web version in his XDC session. While there’s still more implementation to do, the fact that we are using it for internally tells you how far we have come. Once the implementation is complete, we will begin beta testing.

Android

As you may remember we showed you a Hello World on Android back in 2018. Since then we’ve got IDE integration, apps running on simulator and apps running on actual hardware. We’re also building Android apps internally. In fact, we have put together an Android version of the XDC app! You can go to the Play Store and download it right now. This is a simple app, basically the HTMLViewer. However, the app is native and was built the same way you will be building native apps in Xojo. Travis will show you more controls and have lots of details and demos in his XDC session.

So what’s left before Android is in your hands? In this as well, a lot of the “heavy lifting” has been done, we need to finish implementing the framework and port the debugger and then we will begin pre-release testing Xojo Android.

As you can see, Xojo has made significant progress towards these many large, multiyear projects. An additional note, currently work on Plugins in Xojo is paused to allow us to focus on Android. We’ll do our best to keep you updated via Twitter and Facebook throughout the conference. Please use hashtag #XDC2019 online to search or share your own thoughts. Even if you aren’t here, we’ll do our best to reduce the Xojo FOMO! The XDC Video set is now available for sale.

Speaking of great conferences, the MBS Software conference will be in Cologne, Germany on October 24th and 25th of this year. There are already 40 people coming from 10 different countries, including Geoff Perlman!

Last year at XDC 2018, Jérémie Leroy talked about making sure your screenshots mimicked the Apple method so that the date was always Jun 9th, the time was always 9:41 AM, the battery always shows as full and the WiFi strength always shows full. It got me thinking that it might be handy to be able to make the simulator always show those values when you do a debug run so that you don’t need to think about it when you are ready to start taking screenshots and movies of your app. One way to do that is to build & run project like SimulatorStatusMagic on the simulator before running your project, but it would be more useful if it was automatic.

Build the Framework

First of all, go to the SimulatorStatusMagic Github page and clone or download the project. Just like Xojo iOS development, you’ll need Xcode for this step. After you’ve downloaded the project, double-click on the SimulatorStatusMagic.xcodeproj file to open it in Xcode. When the project opens, change the target to SimulatorStatusMagiciOS and build it by either pressing CMD-B or pressing the Play button. Once the build is complete, go to the project navigator, scroll down to the bottom and open the Products group to reveal the built parts of this project. The only item we’re concerned with here is the file named SimulatorStatusMagiciOS.framework. Right-click on it and select Show in Finder.

Build the Project

Let’s start off by making sure the framework will be available to your project at runtime.

1. Create a folder on your drive named SimulatorStatusMagic and copy the framework file that you just built into it.
2. Launch Xojo and create a new iOS project. Save the project into that folder as well.
3. To make sure the framework will be available to your project when debugging, go to the iOS target in the Xojo navigator, right-click and select Build Step > Copy Files. Make sure the step is between the Build step and the Sign step.
4. Drag the SimulatorStatusMagiciOS.framework file from the Finder into the Copy Files Step.
5. In the Xojo inspector, set Applies To to “Debug” and Destination to “App Parent Folder”.

Now let’s make it so you can access the framework! We’re going to add this code in the App.Open event so that the status bar gets set up before you do anything else.

Getting the framework to load is fairly straightforward:

#If DebugBuild
  Declare Function dlopen Lib "/usr/lib/libSystem.dylib" (name As CString, flags As Int32) As Ptr
  Call dlopen("@executable_path/SimulatorStatusMagiciOS.framework/SimulatorStatusMagiciOS", 1 Or 8)
#EndIf

That magic string “@executable_path” gets translated into “wherever the current application currently is” at runtime. Now this just loads the framework. We still need to hook up the methods and properties. Note: If you’re working with a framework that “activates itself” like the one that comes with Reveal (an excellent tool for tracking down iOS layout issues), this is as far as you would need to go.

To figure out what we need to do next, we need to look at the documentation and header files that come with SimulatorStatusMagic. Go back to Xcode and look at the navigator. What we’re looking for is a header file (with a .h extension) which has the definitions of each of the methods and properties which are available in this framework. The only file that meets this criteria (and the one that all the others seem to point to) is named SDStatusBarManager.h. There’s a bit of functionality available here, but the framework is set up to use the Apple recommended settings by default, so all we’re going to do here is call the enableOverrides method to activate it.

Go back to Xojo and update App.Open event:

#If DebugBuild
  Declare Function dlopen Lib "/usr/lib/libSystem.dylib" (name As CString, flags As Int32) As Ptr
  Call dlopen("@executable_path/SimulatorStatusMagiciOS.framework/SimulatorStatusMagiciOS", 1 Or 8)

  // Start by creating a pointer to the SDStatusBarManager class itself
  Declare Function NSClassFromString Lib "Foundation" (clsName As CFStringRef) As Ptr
  Dim smclass As Ptr = NSClassFromString("SDStatusBarManager")

  // Next, we need a pointer to the shared instance of the SDStatusBarManager class
  Declare Function sharedInstance Lib "Foundation" Selector "sharedInstance" (clsref As Ptr) As Ptr
  Dim smclassShared as Ptr = sharedInstance(smclass)

  // Last, turn on the overrides
  // NOTE: We're specifically NOT using the actual lib name here. 
  // This is just to satisfy the Xojo linker. The correct framework will be used at runtime.
  Declare Sub enableOverrides Lib "Foundation" Selector "enableOverrides" (obj As Ptr)
  enableOverrides(smclassShared)
#EndIf

Now if you run the project, when it opens the status bar automatically changes to the recommended defaults!

Please Note: These changes persist until the simulator device that you are running on is completely erased. If you need to disable it, you can do that with the disableOverrides method.

After posting this article, it was brought to my attention that I’d forgotten to show you how to sign the frameworks so you can build for the app store. To do that, you’ll need to add a script build step to your project, just after the Copy Files step you added above. The step can probably be set to Applies To: Release. The code should look like this:

// Replace the text in the signingIdentity property with your own
Dim signingIdentity As String = "iPhone Distribution: Your Company (XXXXXXXXXX)"
Dim code As Integer
Dim cmd As String
Dim result As String
Dim builtApp As String

builtApp = CurrentBuildLocation + "/" + ReplaceAll(CurrentBuildAppName, " ", "\ ")

// Get a list of all frameworks, one per line
cmd = "ls -d1 " + builtApp + "/*.framework"
result = Trim(DoShellCommand(cmd, 30, code))

// If there was no error (like none being there), sign each one
If code = 0 Then
  Dim frameworks() As String = split(result, chr(13))
  For i As Integer = 0 To UBound(frameworks)
    frameworks(i) = ReplaceAll(frameworks(i), " ", "\ ")
    cmd = "/usr/bin/codesign -fs """ + signingIdentity + """ " + frameworks(i)

    Result = DoShellCommand(cmd, 30, code)

    // If the sign fails, print the error and stop the build
    If code <> 0 Then
      print Result
      cancelBuild
    End If
  Next i
End If