EKlectic Accounting is a new, full-featured, professional accounting application made with Xojo by independent developer Edward Kidwell. EKlectic’s user interface is “QuickBooks-like” and will feel familiar to users of other accounting software. All the code for EKlectic Accounting is “pure Xojo”, and uses no plugins. The application is cross-platform and supported on macOS and Windows.

10 Questions with Edward Kidwell

You mentioned your projects are “pure Xojo” and don’t use any plugins. Can you tell us about that?

I was originally drawn to Xojo by an open-source project that turned out to be heavily dependent on third-party plugins. Even after I had purchased a Xojo Pro license, I couldn’t compile the project without additional purchases. Furthermore, as I dug deeper, I found the functionality provided by the plugins was easier to write in Xojo than it was to implement the plugin. I decided at that point that I would strive for all of my projects to be cross-platform compilable without any third-party purchases being necessary. Several projects later, I have not had to compromise that decision.

Although Xojo is a RAD environment (Rapid Access Development), I’ve observed (on the Xojo forum) that many developers overlook the power that is available in the core language and built-in objects. Anyone using the forum will notice that many answers basically say, “Use plugin ABC for that,” when Xojo itself could often solve the problem without any plugins. For developers who are packaging and reselling their software, I think the less third-party dependencies the package has, the easier it is to maintain, support, and debug.

For example, without using any third-party software, I’ve created reusable Xojo objects for PDF (with both print and preview), ID3 audio-tags-reader (for MP3 files), and custom controls (database-enabled auto-completing dropdown fields, GUI panels, etc). Xojo really can stand “on its own two feet”!

Mac, Windows or Linux?

All of the above! My primary machine is Mac, with a separate Windows machine on a different HDMI channel, and I use various Linux VMs as needed.

What do you wish more people would ask/talk to you about when it comes to the software you develop? 

I wish more people offered criticism of the user experience. Only through critical feedback can you improve a software package, and I’ve learned to appreciate it when people complain.

What’s next on your “Learn Next” list?

In the context of computers, the Rust language has piqued my interest. Besides that, I’m currently studying Greek.

When do you think of solutions for stubborn bugs?

*Always* first thing in the morning. The mind seems to solve them overnight.

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

I felt that way when, using Xojo’s ServerSocket and TCPSocket classes, I was able to implement a bonafide HTTP 1.1 server written from scratch in Xojo. I packaged that code as a reusable object that I can plop in to any of my projects. For example, one of my projects uses that server to allow users to control the app remotely from any device on the same network (e.g. iPhone, iPad, Android, and even Kindle tablets). So yeah … it is very satisfying to see my Xojo apps serving up their own HTML and JavaScript web apps, as well!

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

Two things: 1) How fast certain new languages are adopted (e.g. Swift, Rust), and 2) How indispensable some of the older languages have become (e.g. C++, PHP … they’ll never die! ).

What’s the coolest thing you worked on recently?

There are actually two very “geeky” things that come to mind: The first is a shell script I created on TrueNAS (FreeBSD) using rsync to *pull* scheduled (cron) backups of a remote Linux web server over an authenticated SSH connection. The core functions from the script are also used on my Mac to *push* scheduled backups to the TrueNAS. That made my “geek sense tingle” a bit. Secondly, I created a web-based VOIP phone system (like the automated attendants in a PBX) using a RESTful API on the backend, and a home-grown web-app-GUI on the frontend. It allows people to setup a complete phone system in one or more languages and with different voices, all through a web interface. Again, “geek-sense=tingly.”

Music or no music while coding?

I’m a multi-instrument musician of over 4 decades, so yes, always!

In addition to accounting software, Ed offers additional apps built in Xojo. EKlecticSong is a presentation program for song services, church services, or business presentations. EKlectic Find Duplicates is a duplicate finder with a fast duplicate algorithm. Dock Media is a full-featured yet minimalistic media player.

Thank you to Ed Kidwell for answering our questions and sharing his experience with Xojo with us. If you have an app, a project or a person you want to see featured in Spotlight On, tell us about it!

What are Git and GitHub?

Git is an open-source version control system, also known as a source control system. Created by Linus Torvalds in 2005, it is now the most popular version control system, supplanting Subversion a while ago.

GitHub is an online Git hosting service, now owned by Microsoft. GitHub provides additional features beyond just Git hosting, but for this post we will focus on its Git hosting. GitHub is free to use for both public and private repositories.

A repository is essentially a place to store a project. Public repositories are great ways to share open-source projects. Others can view and download the source code. Private repositories are only visible to you and are great for your own internal projects.

Git is a distributed version control system, which just means that the source code can be versioned locally and on the server, only synchronizing when necessary. For simplicity it is common to keep both in sync, however. Older version control systems such as Subversion were server-based and versions were only ever kept on the server. A distributed version control system is slightly more complex, but it does have the advantage of making it easier to work offline.

A version control system tracks changes made to text files, something that is incredibly useful when it comes to source code. Tracking changes is a very common task that is needed while programming. You may have seen people save their projects as MyProject1, MyProject2, MyProjectNewVersion, etc. That is a rudimentary way of trying to ensure you don’t lose changes as you update your code. With version control and the Xojo version control project file format you get a much more flexible technique.

When you save your project using the Xojo version control project file format (called Xojo Project) in the file selector, each project item is saved as its own file on the drive. And each of these files is plain text — you could view them using a text editor if you wanted.

You might be thinking: “I’m just a single developer, I don’t need this extra complexity.” But version control systems are not just for multi-person teams. Sure, version control is a great way to make sure that different team members don’t make different changes to the same code. But version tracking is useful to everyone. Even as a single developer, being able to review previous changes, and revert changes if they don’t work out can be a lifesaver. It removes any “fear of breaking things” from your workflow. Plus, having your source code on a remote server (GitHub) can also function as one of your source code backups.

A Quick Example

To give you an example of how this works, consider a single text file that exists in Git: ReadMe.txt

Initially it contains just this text:

Hello!

You pull down the file to your computer (I’ll define Git terms like these below) to work on it. Opening the file in a text editor, you change its text to this and save:

Hello, Xojo!

Now the file on your computer contains that text. This is called the working copy. The file in the repository still has the text “Hello!”. Now you can do a couple useful things.

You can ask to see the differences between the file in the repository and the one in the working copy. When doing so, most tools will highlight the line that changed, showing the repository contents on the left and the working copy contents on the right. This is a wonderful way to review changes made to code.

The other thing you can do is commit the change to the repository. This adds this file to the repository and makes it the latest version. In Git you’ll then be able to see that this file has two versions and you’ll be able to see what the file looked like for each version.

These two things mean that you will never again lose any work. Anytime you make a change to your code that you want to save as a version in the repository, you commit it. You don’t want to commit after every change as that is too granular and will be hard to manage, but it means you can safely make a bunch of big changes to something and still be able to go back and review what the code looked like previously.

The other useful thing you can do is revert changes. If, after saving the file with “Hello, Xojo!” you realize that was a mistake, you can go back to the previous version by choosing to revert the file. This discards the local working copy and pulls down the most recent revision from the repository.

I realize that this might all seem rather different and confusing, but once you do this on a couple small projects you’ll get the hang of it and you will never want to go back to using MyProject1, MyProject2 again!

Terminology

Repository: This is essentially a place to store a group of files, which for our purposes will be a Xojo project saved in the version control file format (Xojo Project).

Clone: Copies the repository to your computer so you can work on it

Fetch: Updates the local repository with any changes that are stored on the server

Pull: Similar to fetch, except that it also copies the changes into the working copy

Commit: Add the changed file to the repository as a new version

Push: Pushes the committed file to the server (GitHub). Often this is done as a single step: Commit and Push.

Working Copy: Your local copy of the repository and the file

General GitHub Usage

With Xojo, the general workflow you will use is:

1. Create repository on GitHub for the project.
2. Pull it down to a folder on your computer.
3. Create a Xojo project.
4. Save it in Xojo Project (text) format into the above folder.
5. Commit and Push it to GitHub.
6. Make additional changes to the Xojo project.
7. Commit and Push to GitHub as necessary.

Create a GitHub Account

If you don’t already have a GitHub account, you’ll need to create one. Head on over to the sign up page to start the process:

Create a Repository

Now that you have a GitHub account, you’ll want to go to your GitHub home page and click the “New Repository” button.

As mentioned above, a repository is essentially where your project is stored. You’ll typically want a separate repository for each project. This is what the new repository form looks like:

For open-source projects you’ll want to make sure “Public” is selected as it’s not really open-source if it is not public. For a public repository, be sure to come up with a catchy “repository name” and always include a description. Choose “Private” for internal projects.

I always check “Add a README file”, which adds an empty README file to the repository. You can update it later, but it is where you’ll briefly describe the project and how to use it (using Markdown). The README is shown by default when you go to the repository in a web browser.

You should also select “Xojo” for the gitignore template (click the dropdown and type “xojo”). This identifies the project as using the Xojo programming language, which helps with searches and also marks the “uistate” file (which contains user-specific UI settings, such as window sizes and positions) so that it is not included in the project.

Last is the license. For most public open-source projects, I recommend the MIT License, which essentially allows anyone to use your code however they want. For private projects, you can leave it at “None”.

Click the Create Repository button to create the repository.

Clone the Repository to your Computer

With the repository created, you can view it on the GitHub website for you account:

From here you’ll be able to see the files in the repository, along with other information.

You are now ready to “clone” the repository to your computer. This copies the repository files to a folder on your computer so you can modify its files. Of course, the only files in the repository will be LICENSE and the empty README.md, but it is still necessary to do the clone so that you can create the folder where you will then add your Xojo code.

In order to clone, you’ll want to use a Git client application. There are many to choose from, but two free ones are the official GitHub Desktop and Atlassian SourceTree. GitHub Desktop is simpler so that is the one I’ll show here.

Download GitHub Desktop: https://desktop.github.com

Start GitHub Desktop and click “Sign into GitHub.com”.

On the Configure Git page, enter the name and email you want to use to identify your commits.

Click Finish on the next page to show the main screen where you have the option of creating new repositories or cloning a repository. Since we already created a repository online in the previous section, you want to select “Clone a Repository” (you can also choose this from the File menu). In the list, choose the repository you created above, choose your local folder location (Choose…) and click Clone.

You now have a folder on your disk where you can add your Xojo project. This is what the repository looks like in GitHub Desktop:

Note: If you are using another Git client, you will choose its “clone a repository from URL” feature and then provide the URL shown in the “Clone or Download” button on the repository page.

Add Your Xojo Project Code

Start Xojo and open the project you want for the repository you cloned (or you can just create a new project). Click “Save As”, make sure the Format is “Xojo Project” and choose the folder you created when you cloned the repository.

Go back to GitHub Desktop and you’ll now see all the Xojo files appearing in the list as “changed files”. (For this test I used a Xojo SQLiteExample.)

You now need to “Commit” these changes. By default they are all selected/checked in GitHub Desktop so you can enter a brief summary and description (for the first commit, often “Initial commit.” is used, but I used “Initial Xojo commit.”) and then click the “Commit to main” button.

Each time you commit you want to be sure to type a clear summary and description of the changes. This will be helpful later when you are reviewing prior commits.

This marked the files as committed in your local repository, which is needed before you can push the changes up to the online repository. Generally speaking you want to commit things after you have made changes that you want to track. You don’t need to immediately push the changes up to the server (online repository) each time, however, people often do as it is simpler. Some Git clients even offer a single button or command to commit and push in one step.

For this initial commit you definitely want to push the commit to the server, so click the button in the toolbar that says “Push origin”. This pushes the commit to the origin, which is the GitHub repository in this case.

If you now go back to the GitHub repository online and refresh the page you’ll now see the files have been committed:

Sharing Your Public Project

If you created a public repository then it is now available on GitHub for anyone to use. People can find it by searching or you can share the URL (perhaps in the Xojo Forum).

Since I published a public project, anyone can use it. This means that they can clone it and push changes to your project as “pull requests”. A pull request is a change that a user has made that they would also like you to apply to your project. Since this is your project, others cannot directly change it without you adding them as contributors. However, you can review these pull requests and choose to pull and merge the change into your project if you want. Or you can reject the pull request — it’s all up to you since it’s your project.

Changing and Updating Your Project

You’ll likely be continuing to change your project to fix bugs and add features. Each change you make shows up in GitHub Desktop where you can commit it and then push it to the server.

As an example, go back to Xojo and make a change to the project. I added some comments to the AddTeamRow method. After saving, the changes are now visible in GitHub Desktop:

You can see the one file that was changed, SQLiteWindow, and the changes (or diff) is shown in the viewer. Here you can see the changes by the blue highlighted lines in the gutter. The first change indicates that line 386 was removed and replaced, with the change noting that “Please” was added.

The next two changes indicate that new lines were added to the code.

It’s always good to review code like this before you commit it to make sure the changes are what you expect.

You can now Commit this change (always add Summary and Description text so you know the reason for the change!) and then Push it to the server (Push origin).

Discarding Changes

Say you’ve made changes to your Xojo project, but realize you’ve really messed things up and want to go back to the way the code was. For example, say I’ve accidentally deleted a bunch of code in the ShowData method and saved the project. In GitHub Desktop, it would look like this:

You can see the big red area indicating the code that was removed.

To discard this change, I can right-click on SQLiteWindow in GitHub Desktop and select Discard Changes. This pops up a confirmation dialog and clicking Discard Changes will restore the file to its previous version, which is the version of the file that was last committed to the repository.

After doing this, you will need to close the project in Xojo and then re-open it so that it can refresh its internal project structures to reflect the discarded changes. After doing that, you can go back to the ShowData method to see that the code is restored.

This capability is a big reason why version control is also incredibly useful for solo developers.

Using or Cloning Other Repositories

Don’t forget that you can also use other people’s public repositories. To do so you’ll want to click the “Clone or Download” button on the repository page.

For simple usage, where you just want to grab the current version of the repository because you don’t intend to change anything, you can then click the Download ZIP button. Once downloaded, unzip the file and then open the project in Xojo where you can use it or copy/paste it into your own projects (review the license agreement before you use projects, of course).

You’ll want to clone a project when you want to manage it using GitHub Desktop (or your GitHub client of choice). This allows you to fetch/pull updates from the online repository and also allows you to make your own changes and push them up to the server where the repository owner will get them as pull requests, as described above.

Change Your Default Project Format

You might find it worthwhile to change your default project format to be the version control format. This way it will always be selected by default when you save. You can change this in Xojo’s General Settings:

Pro Tip: When saving a project for the first time in version control format, it is always a good idea to save into a newly created folder. This ensures that all your files will be neatly contained in one place and won’t accidentally override something else that may have been in the folder.

Git Going

If you’ve created Xojo projects in public repositories on GitHub, be sure to share them in the forum!

This post just scratches the surface of what GitHub does and also only touches lightly on Git and the concept of source control in general. If you’d like to use Git for source control, but would prefer an alternative to GitHub you might also want to check out Atlassian BitBucket which also offers free Git hosting for both private and public repositories.

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.

In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use.

Most languages have a unit testing library and Xojo is no exception. Not surprisingly, the Xojo unit testing library is called XojoUnit. It is available for free on GitHub:

https://github.com/xojo/XojoUnit

XojoUnit can be used with Desktop, Console, Web and iOS projects. We use XojoUnit ourselves to run unit tests on the Xojo framework as part of our continuous integration build process.

Watch this quick video to see how you can quickly incorporate XojoUnit into your own projects:

Are you doing iOS development? If so, you can find several libraries on GitHub. Two prominent ones are iOSKit  from Jason King and AppleLib from Ulrich Bogun.

There are nearly 30 desktop-related open-source projects available for use in your own projects. For macOS developers, the macOSLib project is useful (as is the 64-bit fork). CustomEditField from Thomas Tempelmann provides a full-featured text editor for your apps. Calendar Time Chooser  from Intelligent Visibility gives you a control for selecting dates and times. There are several libraries for charting and Xojo’s own VB library might be helpful for those porting from older VB projects. Want to add auto-update capabilities to your app? Be sure to take a look at Kaju from Kem Tekinay.

For your web projects you can find libraries for notifications, including KLNotificationView from Francisco Lobo and ToastrIJ from Ian Jones. Aloe Express from Tim Dietrich can be used to quickly build your own web APIs and microservices. I’ve been meaning to try the WebSocket project from Kem Tekinay to see if I can use it to enhance the open-source Slack library.

The GPIO library is essential for those working with Raspberry Pi.

In addition, you can find tools to use with your Xojo projects, such as Format Code from Jeremy Cowgar and XsEdit from Kem Tekinay.

And there are about 30 general purpose libraries you can use with your Xojo projects. XojoUnit is the definitive unit testing framework. Check out XojoDoc from Jeremy Cowgar for an automated way of generating documentation from your Xojo source code. Or for something different, check out OpenCV from François Jouen to add open Computer Vision support to your apps.

If you have a project you want to share with the world, I encourage you to create a GitHub account and upload your project (see my tutorial here). Maybe you’ll some day catch up to prolific Xojo open-source developer Kem Tekinay who has the most with 9 projects to his name!

You can find the full list of all Xojo-related open-source projects in the Xojo Dev Center: Open-Source Projects

If you know of other open-source projects, please let me know so that I can add them to the list.

Create a GitHub Account

If you don’t already have a GitHub account, you’ll need to create one. GitHub is the most popular place for hosting open-source projects and it is entirely free. As its name suggests, GitHub uses the Git source control system for storing the project source and managing updates. It also has a built-in wiki for documentation and an issue tracker.

The way GitHub works is that you’ll add your project, which is then available for anyone to download and use. In addition, others can submit changes to your project in the form of “pull requests”. These are perhaps enhancements or bug fixes that you can review and choose to merge into the project if you want.

Create Repository

Now that you have a GitHub account, you’ll want to go to your GitHub home page and click the “New Repository” button. A repository is essentially where your project is stored. You’ll want a separate repository for each project. This is what the new repository form looks like:

Be sure to come up with a catchy “repository name” and always include a description. You’ll want to leave “Public” selected as it’s not really open-source if it’s not public – and you actually have to pay to host private repositories on GitHub.

I always check “Initialize this repository with a README”, which adds an empty README file. This is where you’ll briefly describe the project and how to use it (using Markdown).

You should also select “Xojo” for the gitignore setting. This identifies the project as using the Xojo programming language, which helps with searches and also marks the “uistate” file so that it is not included in the project.

Lastly, you’ll need to choose a license. For most projects, I recommend the MIT License, which essentially allows anyone to use your code however they want.

Click the Create Repository button to create the repository.

Clone the Repository to your Computer

Now that the repository is created on GitHub, you’ll want to “clone” it to your computer. This copies the repository files to a folder on your computer to you can modify its files. Of course, the only files in the repository will be LICENSE and the empty README.md, but it is still necessary to do the clone so that you can create the folder where you will then add your Xojo code.

In order to clone, you’ll want to use a Git client application. There are many to choose from, but two free ones are the official GitHub Desktop and Atlassian SourceTree. Personally I prefer SourceTree, but the GitHub Desktop is a bit simpler so that is the one I’ll show here.

Download GitHub Desktop: https://desktop.github.com

Start GitHub Desktop and click “Sign into GitHub.com”.

On the Configure Git page, enter the name and email you want to use to identify your commits.

Click Finish on the next page to show the main screen:

On this screen you have the option of creating new repositories or cloning a repository. Since we already created a repository online in the previous section, you want to select “Clone a Repository”. In the list, choose the repository you created above, choose your local folder location (Choose…) and click Clone.

You now have a folder on your disk where you can add your Xojo project.

Note: If you are using another client, you will choose its “clone a repository from URL” feature and then provide the URL shown in the “Clone or Download” button on the repository page.

Add Your Xojo Project Code

Start Xojo and open the project you want for the repository you cloned. Click “Save As”, make sure the Format is “Xojo Project” and choose the folder you created when you did the checkout. You’ll want to use the “Text Project” format as that is what works best with Git because it allows people to view source online and makes it possible to precisely track changes.

Note: Any Xojo edition can open projects in Xojo Project format, but the Xojo Free edition and Xojo Lite edition cannot save in Xojo Project format. Contact us if you’d like to upgrade.

Go back to GitHub Desktop and you’ll now see all the Xojo files appearing in the list as “changed files”. (For my test I used Examples/Database/SQLite/SQLiteExample.)

You now need to “Commit” these changes. By default they are all checked so you can enter a brief summary (for the first commit, often “Initial Commit.” is used) and then click the “Commit to master” button.

This marked the files as committed in your local repository, which is needed before you can push the changes up to the online repository. Generally speaking you want to commit things after you have made changes that you want to track. You don’t need to immediately push the changes up to the server (online repository) each time, however.

But for this initial commit you do want to push it out to the server, so click the button in the toolbar that says “Push origin”.

If you go back to the GitHub repository online and refresh the page you’ll now see the files have been committed:

Sharing Your Project

Your project is now publicly available on GitHub for you to share with the world. All you need to do now is give people the URL! Definitely at least share the URL with me so I can add it to the Open Source Projects page in the Xojo Dev Center.

However, one other thing you should do on the project is click the “Add topics” link under the project description near the top of the page and add some tags. At the very least, add a tag for “Xojo”, but also add tags for whatever other technologies are relevant to your project. This will make it much easier for people to find your project when they search.

Changing and Updating Your Project

You’ll likely be continuing to change your project to fix bugs and add features. Each change you make shows up in GitHub Desktop where you can commit it and then push it to the server.

As an example, you should also make sure you update the README.md file to actually have a bit more description of your project and how people can use it. On your computer, open README.md in a text editor (or even better, a Markdown editor if you have one — I use Markdown Pro). You can learn more about Markdown here: GitHub Markdown Guide

Save the file and the go to GitHub Desktop to see that it shows as changed. With the file selected in GitHub desktop you can see that it shows you what has changed with the new content identified. This also works with source code and is why you want to use the Xojo Project text file format — you’ll be able to see exactly what code you’ve changed.

You can now Commit this change (always add Summary text so you know the reason for the change!) and then Push it to the server (Push origin).

Using or Cloning Other Repositories

Now that you’ve published your project, anyone can use it. And don’t forget that you can also use other people’s repositories. In both cases you’ll want to click the “Clone or Download” button on the repository page.

For simple usage where you just want to grab the current version of the repository you can then click the Download ZIP button. Once downloaded, unzip the file and then open the project in Xojo where you can use it or copy/paste it into your own projects (review the license agreement before you use projects, of course).

You’ll want to clone a project when you want to manage it using GitHub Desktop (or your GitHub client of choice). This allows you to fetch and pull updates from the online repository and also allows you to make your own changes and push them up to the server where the repository owner will get them as pull requests. The owner can then review your changes and decided whether they want to incorporate (pull) them into the project.

GitHub is Great

I look forward to seeing new Xojo projects appearing on GitHub! This article just scratches the surface of what GitHub does and also only touches lightly on the concept of source control in general. If you’d like to use Git for source control, but don’t want to make your projects public you might also want to check out Atlassian BitBucket which offers free Git hosting for both private and public repositories.

To learn more about Git in general, watch these webinars:

• Getting to Know Git Part 1
• Getting to Know Git Part 2
• Source Control

WFS is still available on GitHub, but it has languished over the years. For example, it has lots of legacy code in it for older versions of Windows that is no longer needed since Xojo only supports Windows 7 and later. WFS is also not really compatible with 64-bit projects since the Declares mostly assume 32-bit or bust.

To that end, I’ve started a new open-source project called WinAPILib that is now available on GitHub.

This project is the start of an attempt to collect useful Windows Declares (from WFS and elsewhere) and make sure they are updated to work with 64-bit and newer versions of Windows.

Why is it called WinAPILib? First, Microsoft no longer uses the term Win32 for their desktop framework since the API also works with 64-bit apps. It would be confusing to say you are using the Win32 framework for 64-bit apps, so Microsoft has switched to mostly using “Windows API”:

The Windows API was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows. The name Windows API is used in this volume except when comparing 32-bit Windows programming with 64-bit Windows programming. They are then referred to as Win32 and Win64 APIs, respectively.

This is informally just shortend to “WinAPI”. Combined with the popular macOS Declare project on GitHub called macoslib, I figured WinAPILib would be a consistent, familiar name.

I’ve started small with WinAPILib. Right now it just has a few classes for some system declares and other things. More will be added over time by me and hopefully by others sending pull requests up to GitHub.

To get WinAPILib, go to the GitHub page and click the green “Clone or download” button. Use the clone URL with your favorite GitHub client (I use SourceTree) or just download the Zip if you’re Git-shy.

WinAPILib on GitHub

For some tips on writing Windows Declares, visit Calling Native Windows APIs in the User Guide.

I hope you find this helpful and please share your useful Windows Declares!

• Source control webinar
• Getting to Know Git, part 1 webinar
• Getting to Know Git, part 2 webinar
• Saving your Sanity with Git for Source Code Management XDC 2015 session
• Using Git with Xojo
• Mercurial and Xojo

Source control tracks your changes, can serve as a backup and allows you to try new and different things without fear of completely breaking your code (because you can always go back to a prior, working version of the source).

Since we talk about why you should be using source control so much, I thought I would point out some companies that provide hosted source control and some tools to help you use source control with Xojo.

Now remember, you can use Xojo with any source control system, but you’ll want to use the Text Project format which is available in licensed versions of Xojo (Desktop and higher). The Text Project format is not available with Single Desktop or the Free version of Xojo.

Subversion

Subversion is an open-source version control system made by the Apache folks. It is widely used and relatively easy to understand, using a centralized server as the master repository (or repo) for your source code.

• BitBucket
• Beanstalk (free plan available)
• Assembla (free plan available)

You’re likely to want to use a Subversion client app to make working with Subversion as easy as possible. Here are some that are available:

• Xversion (Mac)
• Versions (Mac)
• Cornerstone (Mac)
• SmartSVN (Mac, Windows, Linux)
• TortoiseSVN (Windows)

Git

Git is a “free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency”. With a distributed system, the full repo is available at each user. You can commit locally before pushing changes up to a central server for others to see.

• GitHub (free plans available)
• GitLab (free plans available)
• BitBucket (free plan available)

And here are some Git clients:

• SourceTree (Windows, OS X)
• GitHub (Windows, OS X)
• Tower (OS X)
• TortoiseGit (Windows)
• SmartGit (Windows, OS X, Linux)

Learn how to Start and Open-Source Xojo Project on GitHub.

Mercurial

Mercurial is a “free, distributed source control management tool. It efficiently handles projects of any size and offers an easy and intuitive interface”.

• BitBucket (free plan available)

Which Should You Use?

There is no right answer to this question. I have used Subversion and Git (and others), but not Mercurial. In my opinion, Subversion is easier to learn than Git, but it is less flexible. These days my preference is to use Git.

Of course, there are lots of other source control systems that exist, but the above are the major ones. If you are already using another source control system with other tools, rest assured that it will also work just fine with Xojo.

Download MP3.

Show Links

• Penn State University
• Blast Image Config
• MacAdmins Conference
• Xojo JSON support
• Sched.org
• Open-Source Xojo Projects
• 5 Reasons to rely on Cloud services
• Git webinars
• XojoUnit
• System 76 Linux laptops
• ElementaryOS
• JackObud arcade cabinets
• Retro game webinar
• Pixel Space Wars

You can also subscribe on iTunes.

Download MP3.

Show Links

• Intelligent Visibility
• Mike Cotrone on Twitter
• Intelligent Visibility Blog
• FastSpring payment processing
• Calendar Time Chooser
• DropBox API
• Intelligent Visibility open-source Xojo projects
• Mike Cotrone’s AJHL (92-93) goaltending stats

You can also subscribe on iTunes.