Let’s build a simple but incredibly powerful Desktop app: a threaded image resizer. This tool will let you pick a folder of images and resize them all without ever locking up the app. It’s a perfect showcase of how easy and effective threading can be in Xojo.

Let’s get started!

Step 1: Designing the User Interface

First things first, let’s lay out our app’s window. We’re going for a clean and simple design. All you need to do is create a new Xojo Desktop project and add the following controls from the Library onto your main window:

1. DesktopButton: This will be our “start” button. The user will click this to select a folder and begin the resizing process. Let’s set its Caption to “Select folder && Start”.
2. DesktopProgressBar: This will give the user visual feedback on the progress of the resizing operation.
3. DesktopLabel: We’ll use this label to display status updates, like which file is currently being processed or when the job is complete. Let’s call it StatusLabel.

Your app layout should look something like this:

Step 2: Adding the Magic Ingredient: The Thread

Now for the star of the show! Go to the Library and find the Thread object. Drag and drop one onto your window. By default, it might be named Thread1, but I’ve renamed mine to ResizeThread to make its purpose crystal clear. This object is where our background work will happen.

Quick note on thread types: Cooperative threads (the default) share a single CPU core with the main/UI thread and other cooperative threads. Preemptive threads can run on separate CPU cores and deliver true parallelism for CPU-bound work. More info on this subject: Cooperative to Preemptive: Weaving New Threads into your Apps

Why this project uses Preemptive threads: resizing many images is CPU-bound and benefits from parallel cores without blocking the UI.

Step 3: Kicking Off the Process

With the UI and thread in place, let’s add the code to get things moving. Double-click the “Select folder & Start” button to add its Pressed event. This is what will run when the user clicks it.

Here’s the code for the Pressed event:

' Ask the user for a source folder (contains images)
Var f As FolderItem = FolderItem.ShowSelectFolderDialog
If f = Nil Then Return ' user cancelled

mSourceFolder = f

' Reset UI
ProgressBar1.Value = 0
StatusLabel.Text = "Starting…"

' Kick off background work!
ResizeThread.Start

Let’s break this down. First, we ask the user to select a folder. If they don’t pick one, we simply exit. If they do, we store the selected folder in a window property called mSourceFolder (Public Property mSourceFolder As FolderItem). We then reset our progress bar and status label and, most importantly, we call ResizeThread.Start. That one simple line tells our thread to wake up and get to work by running its Run event.

Step 4: The Heavy Lifting (in the Background)

The Run event of the ResizeThread is where the core logic lives. This is where we’ll find, load, resize, and save the images. Remember, the golden rule of threads is: never touch the UI directly from the Run event. Doing so can cause crashes and unpredictable behavior.

Instead, we perform our task and then send a message back to the main thread with an update. We do this using a method called AddUserInterfaceUpdate.

Here’s the Run event code:

' Quick validation up-front
If mSourceFolder = Nil Or Not mSourceFolder.Exists Or Not mSourceFolder.IsFolder Then
  Me.AddUserInterfaceUpdate(New Dictionary("progress":0, "msg":"No folder selected"))
  Return
End If

Try
  ' Ensure output subfolder "<selected>/resized" exists
  Var outFolder As FolderItem = mSourceFolder.Child("resized")
  If Not outFolder.Exists Then outFolder.CreateFolder
  
  ' Build a list of candidate image files.
  ' Note: Using Picture.Open to validate images is simple and robust.
  '       (For very large folders, you could pre-filter by extension first.)
  Var images() As FolderItem
  For Each it As FolderItem In mSourceFolder.Children
    If it = Nil Or it.IsFolder Then Continue ' Ignore subfolders
    Try
      Var p As Picture = Picture.Open(it)
      If p <> Nil Then images.Add(it)
    Catch e As RuntimeException
      ' Non-image or unreadable; skip
    End Try
  Next
  
  Var total As Integer = images.Count
  If total = 0 Then
    Me.AddUserInterfaceUpdate(New Dictionary("progress":0, "msg":"No images found"))
    Return
  End If
  
  ' Resize settings (simple “fit within 800x800” bounding box)
  Const kMaxW As Double = 800.0
  Const kMaxH As Double = 800.0
  
  ' Short delay after each file so the main thread can repaint the UI
  Const kDelayMS As Integer = 50
  
  For i As Integer = 0 To total - 1
    Var src As FolderItem = images(i)
    Try
      ' Load source (immutable)
      Var pic As Picture = Picture.Open(src)
      If pic = Nil Or pic.Width <= 0 Or pic.Height <= 0 Then Continue
      
      ' Compute proportional scale (never upscale)
      Var sW As Double = kMaxW / pic.Width
      Var sH As Double = kMaxH / pic.Height
      Var scale As Double = Min(Min(sW, sH), 1.0)
      
      Var newW As Integer = Max(1, pic.Width * scale)
      Var newH As Integer = Max(1, pic.Height * scale)
      
      ' Render into a new mutable bitmap of the target size
      Var outPic As New Picture(newW, newH)
      outPic.Graphics.DrawPicture(pic, 0, 0, newW, newH, 0, 0, pic.Width, pic.Height)
      
      ' Build a safe base name (strip the last extension; handle dotfiles)
      Var name As String = src.Name
      Var ext As String = name.LastField(".")
      Var baseName As String
      If ext = name Then
        ' No dot in the name
        baseName = name
      Else
        baseName = name.Left(name.Length - ext.Length - 1)
      End If
      If baseName.Trim = "" Then baseName = "image"
      
      ' Save JPEG (fallback PNG if JPEG export not supported)
      Var outFile As FolderItem = outFolder.Child(baseName + "_resized.jpg")
      If Picture.IsExportFormatSupported(Picture.Formats.JPEG) Then
        outPic.Save(outFile, Picture.Formats.JPEG, Picture.QualityHigh) ' adjust the quality of the jpeg here
      Else
        outPic.Save(outFolder.Child(baseName + "_resized.png"), Picture.Formats.PNG)
      End If
      
    Catch io As IOException
      ' Likely a write/permission/disk issue; skip this file
    Catch u As UnsupportedOperationException
      ' Unsupported format/operation on this platform; skip
    End Try
    
    ' Progress + message to the UI (safe handoff)
    Var pct As Integer = ((i + 1) * 100) / total
    Me.AddUserInterfaceUpdate(New Dictionary("progress":pct, _
    "msg":"Resized " + src.Name + " (" + pct.ToString + "%)"))
    
    ' Let the main thread paint the update
    Me.Sleep(kDelayMS, True) ' wakeEarly=True allows early resume when idle
  Next
  
  ' Final UI message
  Me.AddUserInterfaceUpdate(New Dictionary("progress":100, "msg":"Done"))
  
Catch e As RuntimeException
  ' Any unexpected failure: report a friendly error
  Me.AddUserInterfaceUpdate(New Dictionary("progress":0, "msg":"Error: " + e.Message))
End Try

Step 5: Receiving Updates and Safely Changing the UI

So, how does the main thread “hear” these updates? Through the UserInterfaceUpdate event on the ResizeThread itself! This event fires on the main thread, making it the one and only safe place to update our controls.

Here’s the code for the UserInterfaceUpdate event:

' This event runs on the main thread – SAFE to update controls here.
If data.Count = 0 Then Return

Var latest As Dictionary = data(data.LastIndex)

If latest.HasKey("progress") Then ProgressBar1.Value = latest.Value("progress")
If latest.HasKey("msg") Then StatusLabel.Text = latest.Value("msg")

' A little bonus: when we are done, open the output folder!
If latest.HasKey("msg") And latest.Value("msg") = "Done" Then
  Var outFolder As FolderItem = mSourceFolder.Child("resized")
  If outFolder <> Nil And outFolder.Exists Then
    outFolder.Open
  End If
End If

In this event, we receive an array of Dictionaries (all the updates that have queued up). We usually only care about the very latest one, so we grab data(data.LastIndex). Then, we safely access the values from the dictionary and assign them to ProgressBar1.Value and StatusLabel.Text. That’s it!

Conclusion

And there you have it! A fully functional, non-blocking image resizer. By moving the heavy work to a Thread, we’ve created an application that provides a smooth, professional user experience.

The pattern is simple:

1. Start the task from the main thread (ResizeThread.Start).
2. Work inside the thread’s Run event.
3. Communicate back to the UI with AddUserInterfaceUpdate.
4. Update the UI safely in the UserInterfaceUpdate event.

That’s pretty much it! Go ahead, download this project’s source code from GitHub, play around with it, and think about how you can use threads in your own applications!

Happy coding!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The History

While we’ve offered an API to get the Destination of a DragItem, it has been returning Nil on macOS for quite some time. In fact, it likely hasn’t worked since our transition from Carbon to Cocoa way back in the day. Amid all the API changes that came with that transition, DragItem.Destination was unfortunately left behind.

A New Way to FolderItem Drag

To avoid breaking existing code, we chose not to overhaul our entire drag-and-drop system just to support this feature. Instead, we’ve made a few simple additions that are necessary to get FolderItem drags to return a valid DragItem.Destination

Here’s how a FolderItem drag would currently be setup (for example in the DesktopWindow.MouseDown event):

Var fileToCopy As FolderItem = SpecialFolder.Temporary.Child("Test")
Var item As New DragItem(Self, 0, 0, 100, 100)
item.FolderItem = fileToCopy
item.Drag

After dropping the item at its Destination, checking item.Destination would always return Nil:

If item.Destination = Nil Then
    MessageBox "Not a happy destination. 😔"
End If

By making one simple addition and using the RawData API, we can now initiate FolderItem drags in a way that correctly returns a valid FolderItem.Destination.

Var fileToCopy As FolderItem = SpecialFolder.Temporary.Child("Test")
Var item As New DragItem(Self, 0, 0, 100, 100)
item.FolderItem = fileToCopy
item.RawData("public.file-url") = ""
item.Drag

Now, when you check the Destination after the drag is complete, you’ll receive something much more meaningful:

If item.Destination <> Nil And item.Destination IsA FolderItem Then
    MessageBox(FolderItem(item.Destination).NativePath)
End If

An Added Benefit

While this change is a big improvement, why stop there? In the past, you could only drag FolderItems to the Destination, and the entire contents of that FolderItem would be copied over. With the addition of this new dragging method, you can now assign content to RawData("public.file-url"). Instead of copying the entire FolderItem to the Destination, we’ll copy the content from the RawData instead.

Here’s how you could set it up:

// The fileToCopy does not need to exist, we'll simply
// pull the file name from it and create the file at
// the destination with the new content that is assigned
// to the RawData.
Var fileToCopy As FolderItem = SpecialFolder.Temporary.Child("DummyFile.txt")
Var item As New DragItem(Self, 0, 0, 100, 100)
item.FolderItem = fileToCopy
item.RawData("public.file-url") = "Content that will be written to the destination file."
item.Drag

Conclusion

With these enhancements, dragging FolderItems on macOS has become more flexible and powerful than ever. Not only can you now easily retrieve a valid Destination, but you also have the power to control the content being copied, thanks to the integration with the RawData API.

So, go ahead—drag that FolderItem and show us your destination!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What is New?

Xojo 2023r3 adds new FolderItem.Zip and FolderItem.Unzip methods with support for the most widely used DEFLATE compression format.

• Zip(destination As FolderItem, contentsOnly As Boolean = False, compression As ZipCompressions = ZipCompressions.Normal) As FolderItem
• Zip(contentsOnly As Boolean = False, compression As ZipCompressions = ZipCompressions.Normal) As FolderItem
• Unzip()
• Unzip(destinationFolder As FolderItem)

How to Zip

Here’s an example of zipping SomeFolder on your Desktop:

Var someFolder As FolderItem = SpecialFolder.Desktop.Child("SomeFolder")
Var outputFile As FolderItem = someFolder.Zip

The outputFile will be created on your Desktop with the name “SomeFolder.zip”.
This zip file will contain a single folder called SomeFolder, along with the contents of that folder.

+- SomeFolder.zip
  +- SomeFolder
    +- File1.ext
    +- File2.ext
    +- etc.

If you’d rather just zip up the contents of SomeFolder then you can pass True to the contentsOnly parameter.

Var outputFile As FolderItem = myFolder.Zip(True)

Now the zip file only contains the contents of the SomeFolder folder.

+- SomeFolder.zip
  +- File1.ext
  +- File2.ext
  +- etc.

Note: on macOS, when the OS unzips this kind of zip folder hierarchy, it will automatically create a folder with the contents, regardless of what the actual zip hierarchy looks like. However, this does not affect our own FolderItem.Unzip method.

With the overloaded Zip method that takes a destination FolderItem, you can use this to specify where the zip file is created.

Var destinationFolder As FolderItem = SpecialFolder.Documents
Var outputFile As FolderItem = myFolder.Zip(destinationFolder)

In this case the outputFile is created in the user’s Documents folder. If you wanted to rename it to something other than the default name with a “.zip” appended to it, you can also use this syntax to pass a destination file instead of a destination folder.

Var destinationFile As FolderItem = SpecialFolder.Desktop.Child("MyZipFile.zext")
Var outputFile As FolderItem = myFolder.Zip(destinationFile)

While we only demonstrated how to zip a folder in these examples, the exact same syntax applies for zipping a single FolderItem file too.

How to Unzip

Conversely, if you wanted to unzip a file, this is a simple call to FolderItem.Unzip

outputFile.Unzip

This unzips the outputFile contents to the same directory that the outputFile resides in. If you wanted to unzip the contents to a different location, pass in a destination folder instead:

outputFile.Unzip(SpecialFolder.Temporary)

This feature is not yet supported in Android. In conclusion, Zipping/Unzipping has never been easier! Learn more in the Xojo Programming Documentation – Zip and UnZip. (Thanks in part to zlib)

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

1. Add a class to your project and name it TempFolderItem.
2. Add a Private property to the class named mFolderItem with a type of FolderItem.
3. Add a Method to the class named Constructor.
4. In the method, add the following code:
   mFolderItem = FolderItem.TemporaryFile()
5. Add a Method to the class named Destructor.
6. In the method, add the following code:
   mFolderItem.Delete
7. Add a new Method to the class named Operator_Convert with a return type of FolderItem.
8. In the method, add the following code:
   Return mFolderItem

That’s it! Now when you need a temporary file, create one of these objects like this:

Var myTempFile as New TempFolderItem

The Operator_Convert method makes it so you can use this object in any place where a FolderItem is expected and as soon as myTempFile goes out of scope, *POOF* the file disappears (assuming of course that no other process has locked the file).

In order to instruct a FolderItem to delete itself when it’s out of scope, we will create a new class that will act as a wrapper for the FolderItem, making use of the Operator_Convert method, so we can assign a FolderItem to it and also get the underlying FolderItem wrapped in it.

So, go ahead and create a new Class. We can name it as TempFolderItem with an empty Super class in the Inspector Panel.

Add a new property to the new TempFolderItem class, using the following values in the Inspector Panel:

• Name: mFile
• Type: FolderItem
• Scope: Protected

Next, let’s add a Constructor method to our class with the following signature:

• Name: Constructor
• Parameters: f As FolderItem
• Scope: Public

And simply put this line of code in the associated Code Editor:

mFile = f

Then, we need to add a couple of Operator_Convert methods:

• Name: Operator_Convert
• Parameters: f As FolderItem
• Scope: Public
• Code Editor: mFile = f

• Name: Operator_Convert
• Returned Type: FolderItem
• Scope: Public
• Code Editor: Return mFile

Finally, we will add the Destructor method. This one will be in charge of deleting the underlaying FolderItem once the class instance is out of scope:

• Name: Destructor
• Scope: Public
• Code Editor:

Try

  If mfile <> Nil And mfile.Exists And mfile.IsWriteable Then

    If Not mFile.IsFolder Then

    mfile.Remove

  End

End If

Catch e As IOException
  Raise e
End Try

Temporary FolderItems in Practice

That’s all – our class definition is done! In order to test it, create a Desktop project, add the Open Event Handler to the default window and write this snippet of code in the Code Editor:

Const textContent As String = "Lorem ipsum dolor sit amet, consectetur adipiscing elit"
f = New TempFolderItem(specialfolder.desktop.child("Test.txt"))

Try

  Var tos As TextOutputStream = TextOutputStream.Open(f)
  tos.WriteLine textContent
  tos.Close

Catch e As IOException
  MessageBox(e.Message)
End Try

Next add a new Property to the default window (Window1) using the following values in the Panel Inspector:

• Property Name: f
• Type: TempFolderItem
• Scope: Public

This way, the TempFolderItem will be in Scope (this is, in memory) while the Window1 window remains opened. Once we close the window, everything will be destroyed from memory, including this property. Also the underlying FolderItem stored on it via the Destructor method of our class will be deleted.

Run the example project and see how it works. While the Window1 window remains open, our file will be available in the Desktop; but as soon we close the Window1 window… the file will be deleted automatically!

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

But, beware! The following implementation will delete all the files and original containing folder every time it finds an alias… not just the alias. Anyway, it is easy to change this behavior in case you just want to delete the alias and not the original it points to.

As you probably already know, when we work with files or folders in Xojo we are actually using the FolderItem class, so we are able to access to all its properties and the methods acting on every instance: changing the file/folder/directory name, getting the creation date, create a copy, to move the file and/or folder to a new destination … and also for deleting the file or folder.

In addition, recursion is a technique that is not always appropriate because the function adds a new frame of data to the execution stack every time it calls itself, something that can cause a stack overflow error if it calls itself a large amount amount of times. This may occur, for example, if a folder or directory has many nested folders. To alleviate this, we can resort to the mechanism provided by the Xojo language itself and gracefully catch this situation on runtime.

Having said this, what is the best way to implement our recursive function so it is available to all the FolderItem instances? You may create a new FolderItem subclass, but that would mean that the method would only be available from the instances created from the subclass, and not for those created from the parent FolderItem class. The answer in this case is to apply it as a Class Extension technique. This technique allows us to add additional functionality to a existing class without needing to subclass it previously.

The way to add a Class Extension in Xojo is through a Module, so it gives us the option to set the method as globally available from all the app code. This way, the Xojo compiler will know that we want to extend a particular class because we use the Extends keyword in the method definition, followed by the variable whose data type designates the class we want to extend.

So, our method (or function) signature will be:

DeleteAllFilesInside(extends f as FolderItem)

Once we’ve added that method to a Module it’s important to set the Scope to the value Global in the Inspector. Now we can put the following code inside the associated Code Editor for the method, so this is the responsible of deleting the files and call itself every time it detects a new folder/directory:

  // We keep the initial (designated) FolderItem
  // So it doesn't get deleted.

  Static originFolder As String = f.NativePath

  // Is the pointed FolderItem a Directory?
  // then proceed to iterate the containing
  // files and (probably) folders.

  If f.Directory Then

    For n As Integer = f.Count DownTo 1

      If f.Item(n) <> Nil Then

        // Are we detecting a new folder
        // while iterating the current one?
        // then we call the function again!

        If f.item(n).Directory And f.Count <> 0 Then

          Dim f1 As FolderItem = f.item(n)

          f1.deleteAllFilesInside

        End If

        // Otherwhise, we proceed to delete the file/folder
        // always it is not the initial FolderItem
        // that is, the initial folder/directory

        If f.item(n) <> Nil And f.item(n).NativePath <> originfolder Then f.item(n).Delete

      End If
      
    Next
  End
  
  // we are outside a folder, so let's check
  // that the pointing FolderItem is not the initial one
  // if it doens't, then we can delete the file/folder

  If f <> Nil And f.NativePath <> originFolder Then f.Delete

Javier Rodri­guez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has be using Xojo since 1998. He manages AprendeXojo.com and is the developer behind the GuancheMOS plug-in for Xojo Developers, Markdown Parser for Xojo, HTMLColorizer for Xojo and the Snippery app, among others.

*Watch a video of this Tutorial in Spanish

*Read this post in Spanish

Of course, as Xojo is a native multi-platform development environment, the FolderItem class is available for all the supported deployment platforms: desktop (macOS, Windows, Linux, Raspberry Pi), console, web or iOS. Of course, under iOS and other sandboxed deployments, you will have to consider the limitations imposed by the OS when dealing with files, as for example not writing to the app bundle (under OS X and iOS), accessing only the allowed folders/directories, etc.

As it goes when using any class, the first thing you will have to do is get a new class instance (an object) pointing to the file item you want to work with, whether it is one already available or one you want to create from scratch (i.e: giving the path, name and extension). In both scenarios, the most basic way to go is the same:

Dim f as new FolderItem("\users\myusuario\documents\test.txt")

With the previous line of code we will be using the FolderItem class Constructor, passing along as the argument the native path to the file we want to get the reference to, if it already exists; or to the file our app expects to create. It is important to point out the fact that the path format, as String, is the native one to the platform over which we are going to deploy the app, something you have to consider if you want to create a multiplatform app. For these cases, you can turn to the use of the conditional compilation clause #If…#Then…#Endif, providing the native path variation expected by the OS under which your app is running.

In addition, when we use the FolderItem constructor in combination with absolute paths as arguments, we have not guarantees that the resulting reference assigned to the FolderItem variable is a valid one (in our example, pointed by the ‘f’ variable). For example, if we were trying to open a file, it could be the case that the file was no longer in the referenced path anymore (moved, deleted…); or maybe we have included a typo in the path composition. It is for things like these that we should always check the correctness of the variable before using any of the provided methods or accessing the properties, because it is possible that we were dealing with a Nil reference.

For example, we can check our FolderItem variables using the conditional form like this:

if f <> Nil then
  // this is a valid reference
  // so we can work with it
end if

Or, preferably, catching the exceptions as in the following example. This way we avoid the use of multiple if…then…else in the same code fragment:

Exception e as NilObjectException
  MsgBox "The file is not valid"

How can we get a reference to a file for those cases were we don’t know the file path in advance? I mean, this is what happens, for example, when using most of the apps that allows us to choose the file via a File Dialog Box; a Window that brings access to the OS file system showing all the files that are compatibles with the app.

Choosing Files: GetOpenFolderItem

For these cases Xojo offers the GetOpenFolderItem function, passing along as a unique parameter the string representing, as a filter, the kind of files our app is interested in. When we use this parameter, the File Dialog Box will show only the compatibles ones as selectable by the user, leaving the rest in ghost mode. We can also choose to not use any filter at all, passing the string “????” as the function parameter.

As result of this function invocation we will get a FolderItem instance. For example:

Dim f a FolderItem = GetOpenFolderItem("????")
MsgBox f.path

However, during the user interaction with the File Dialog Box it can be the case that the user selected a valid file clicking next the ‘Ok’ button, in whose case our app would get a valid reference; but it can also be the case that the user canceled the operation clicking on the ‘Cancel’ button, in which case our variable (‘f’ in the code example) would get a Nil reference. Thus, it’s important to apply the same kind of test over the variable that we have seen on the previous section.

SpecialFolder: Direct Access to Well Known Directories

Xojo also puts in our hands a third option, we can use to get valid references to files in a faster and multiplatform way using the SpecialFolder Module. This module gives us access to well known paths on every supported OS, so our app always points to the right path no matter the OS it is running on. This is the way to go, for example, when we want to point to the Documents folder or other specific folders such as Library or Cache.

For example, if we want to get the right reference to the Documents folder on every supported deployment OS, we would have to use this fragment of code:

Dim docs As Xojo.IO.FolderItem
docs = Xojo.IO.SpecialFolder.Documents
msgbx docs.path

Try to run the previous fragment of code on several operating systems (virtual machines are a great help for this), and you will see how Xojo points to the right path in every case.

Child: Adding Items to a FolderItem Path

In the previous section we saw how to get a reference to a folder or directory; but, how can we complete the path so it also includes a specific file item, either an existing one or the one we want to create? For that we can use the method of the class instance Child. With this method we can add as many path components as we need (for example, several folder or directories levels in the file system hierarchy) until we point to the file item over which we can get a valid reference. For example:

Using Xojo.IO
Dim docs as FolderItem = SpecialFolder.Documents
docs = docs.child("MyFile.txt")

Or we can use also:

Using Xojo.IO
Dim docs as FolderItem = SpecialFolder.Documents
docs = docs.child("Recipes").child("MyRecipe.doc")

With the first example, the reference points to a file item thanks to the use of the Child method. While the second example also adds an additional directory (“Recipes”) to the path via the use of Child, to finally point to the file item. In both cases, the referenced file may or may not exist. If the file doesn’t exist yet, then the ‘docs’ variable will not include valid data on all of the properties that you could read if the variable were pointing to an existing file. For example, some of these properties are creation date, modification date or file length. When the variable points to a folder or directory, then we can use the Count property to know the number of items contained by the folder so we can iterate on them, for example.

Iterating Files and Folders

However, when we need to iterate a folder item, for example to manipulate every available item or transverse the file system hierarchy walking every found folder, the best we can do is get an Iterator on the folder/directory we want to use as the root point of the process. For this, the Xojo.IO.FolderItem class gives us the Children method, so we can use the For…Each…In loop to walk every available item in the iterator.

For example, we can add all the visible files available under the Documents folder to a ListBox using the following code snippet:

using Xojo.io
dim f as FolderItem = SpecialFolder.Documents
for each i as FolderItem in f.Children
  if i.IsFolder = false and i.IsVisible then Listbox1.AddRow i.name
next

In Brief…

We have seen the basics of the FolderItem class and how we can use it to get references to folders/directories and files, both using the Classic Framework or the Modern one. We have seen also several ways to compose the FolderItem paths, how to deal with Nil references, and the best way to walk through all the available files under a folder via an Iterator. Once we get the reference to the file and/or folder of interest, there are a lot of methods and properties you can explore under the FolderItem class!

Javier Rodri­guez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has used Xojo since 1998. He is in charge of AprendeXojo.com and the developer behind the GuancheMOS plug-in for Xojo Developers and the Snippery app, among others.

*Read this post in Spanish