Change is the Only Constant

No one likes change.  I know I don’t.  It introduces an unknown element and unknown equates to scary.

Back in college (granted, this was decades ago) the language dejour was Pascal and C was an upper level CS course (being an electrical engineering student I never had to take it).  Visual Basic wasn’t heard of and Xojo wasn’t even a wet dream yet.  Since then C++, C#, Java, Javascript and a myriad of other languages have come.  And some have gone too.  Then came the frameworks that made life much easier because no longer did we have to reinvent the wheel on every project.  The only constant in software development is change.

Xojo has been around for over fifteen years.  I think anyone that’s been using the product for any length of time can say it is not a static product.  It supported 68k Mac’s back in the day, then PPC Mac, then Universal Mac apps, then Carbon, and now Cocoa.  For Windows there’s been a bit more stability but things have changed from Windows XP to Windows 8.  Linux, well, it seems that there’s a new Linux distribution every month that are slightly different from each other.

Xojo introduced the ability to create web apps that ran on Mac, Windows, and Linux and introduced a new framework for the controls and for web specific things.  Overall, however, the web framework was exactly the same as the standard framework even when it didn’t make much sense (e.g. web controls having drag events when there’s no way they’d work like the desktop version).

And now Xojo is working on an iOS version (due out soon) which uses an entirely new framework.  iOS is a completely new beast.  It most definitely is not a Mac, Windows, or Linux desktop or console app.  When you think about it, making web apps is really just a console app so it wasn’t a big stretch since Xojo has been doing console apps for a while.

iOS is very different.  It uses a completely different processor which requires new system calls.  Heck, there are no ‘windows’ but has ‘views’ that are sort of, kind of, like windows.  The metaphors between mobile and desktop (and web) are completely different.

For 15 years the Xojo framework has had a lot of new stuff bolted on.  Different Xojo developers did different things but for the most part it’s just worked.  It was wildly inconsistent and every developer, like myself, that has spent a lot of time working with the language still has trouble remembering which framework calls used zero or a one index.  Names weren’t always consistent and some things were simply harder than they needed to be.

So Xojo is making a new framework that eliminates the confusion.  All indexes are zero based – no exceptions.  Methods and properties are consistently named so (theoretically, at least) if you are using an object you’ve never used before you should be able to make reasonable guess at what the method you want is.  Obviously, there will be exceptions to this rule but the goal is to make it easier on us developers in the long run.

In the long run…That’s that key phrase.  What we’re finding out is that it’s generating a bunch of concern amongst Xojo developers.  I get it.  Change is hard and it’s scary.  But it’s not that bad.

Here are the facts:

1.  The existing framework isn’t going away.  It will be around for many years (if not forever).  Xojo has said the existing framework will be 64bit and will be released sometime in 2015.

2.  The new framework is only required with iOS.  There are zero Xojo iOS customers right now.  All desktop, console, and web applications, are okay and need zero modifications in Release 3 to work.  NO CHANGES REQUIRED!

3.  You will be able to intermingle the new and old framework.  Xojo has introduced a Using keyword that allows you to use both at the same time.

Xojo isn’t forcing you to use the new framework in Release 3.  Your apps will still compile and work just like they used to (the compiler does find new types of bugs so don’t be surprised if you have to fix a few things).

Should you start looking at the new framework?  Absolutely!  Should you start converting code over to the new framework soon?  Well, I would hold off a release since the new framework is still in some flux (I think).

Porting code to the new framework isn’t all that difficult.  Is it work?  Yes – especially if you have extensive code libraries that are shared between console, desktop, web, and iOS.  Co-mingling new and old frameworks will be painful for a while but the nice thing is that the new framework (that parts that exist, at least) will work on all platforms in Xojo 2014 Release 3 and beyond.

The new framework is different.  You might have to looking at every line of code.  I personally won’t do this with existing code but certainly all new code will probably use the new framework.  It is the future and I hate coding things twice.  The biggest problem is legacy code and that the new framework is not backwards compatible.  As a 3rd party controls and library developer this has the potential to mess up development for a while.

The new framework is coming and it’s not all that scary – really.  iOS users will bear the brunt of the changes, at first, but everyone can start using it now and I encourage you to start looking at it.

Styled HTML Field 2.0.10

picAppIconWe updated Styled HTML Field today to version 2.0.10.  The StyledHTMLField is a set of classes for Xojo that allow you to export HTML from StyledText in a native TextArea control.  The classes also allow you to create HTML emails.

This maintenance release has the following changes:

  • Added ConnectionType for secure connections with ability to choose SSL2, SSL23, SSL3, TLSv1 and TLSv11, TLSV12 for R3 when it’s released.
  • Added Paragraph Alignment to the demo application
  • Removed PWEmbedImageSMTP. Now uses TCPSecureSocket but secure set to false for non-secure connections.
  • Fixed deprecated items with current Xojo replacements.
  • Fixed items found in project check
  • Fixed old BKeeney URL’s in the demo app

Demo, pricing, downloads, and other details at

Spell Checker 1.0.1

picBKS_SpellCheckerToday we released version 1.0.1 of our cross platform spell checker for Xojo.  This Xojo plugin works on Mac and Windows and will use the system spell checker where available (all Mac OS X and Window 8+).  Otherwise, it will fall back to the popular Hunspell spell checking dictionary.  On systems that can use both you have the option of either the system or Hunspell dictionary.

The BKS Spell Checker plugin is designed for use with the Formatted Text Control but also works with the native Xojo TextField and TextArea controls.

This version fixes an issue in Windows XP.

More information, demo, and pricing at

The Power of Face Time

Face time is very cool. No, I’m not talking about the video conferencing technology that Apple is pushing. I’m talking about sitting across the table from someone and being able to see their body language and see what they’re pointing to. If a picture is worth a thousand words, being in the same room with someone is worth a couple of hundred thousand words.

Most of our consulting projects are small enough and simple enough that email and phone calls are usually good enough. However, I’ve come to believe that the more complex projects need something more. Complex projects take consulting to a new level. Complex business requirements almost always mean more complexity in the design, coding, testing and debugging which in turn brings more complexity in interacting with the client.

There is something powerful about being in the same room with the client. You make a connection that emails, phone calls and video conferences just can’t accomplish. It’s been my experience that these clients trust you more because they’ve spent time with you. As social creatures we pick up on little things that either lead us to distrust or trust the other person. You miss most of it when you are using electronic means.

In late April 2015 the Xojo Developer Conference (XDC) will be held in Austin, Texas. Xojo developers from all over the world will come together and talk all things Xojo. More information can be found at The early-bird special will expire the end of November so sign up for the conference now to save $200.

Xojo will be spending a lot of time talking about iOS, what’s new in desktop and web apps. Hopefully we’ll get news on 64 bit apps, the LLVM compiler, the new framework, and whatever else they’re cooking up.

If this conference is like past conferences the real value isn’t the stuff talked about in the sessions (though that’s usually really great info!), it’s the connections with the people. People looking for a Xojo developer can sit down with several potential developers and discuss their projects and look them in the eye.

Developers can share their successes and horror stories with each other and talk about what works and what doesn’t. The conferences are a great way to network. You never know exactly how those connections will work. Consulting referrals happen all the time. I’ve received leads from developers that are too busy to handle work or on projects outside of their expertise. Likewise, I’ve given leads to some developers because of the conference networking.

Email and forums are handy for storing solutions but are awful mediums because intent and body language are missing.  People that I felt were complete jerks in emails and in forum posts turned out to be really nice when talking to them in person!  Now, the next time I see their brusque or insensitive comments I can just shrug it off because I know the person. I’ve had face time with them and that’s a pretty powerful thing.

XojoTalk Podcast

I just wanted to bring attention to the (relatively) new XojoTalk podcast.  The third edition was released this week with guest Eric Gibbon.  Paul Lefebvre, from Xojo, and Eric talked about the UK Xojo Developers Conference (being held this week!), XDC 2015, widescreen displays, and a whole lot more.  It’s not just about Xojo!

I was fortunately enough to be guest number 2 for the October edition.  Last month I talked about the trials and tribulations of working from a home office, XDC 2015, working in an RV, and the Mavericks and Windows 10 releases.

I have really enjoyed these podcasts.  Paul has done an excellent job of organizing them and keeping the discussions lively.  I’ve found it interesting to hear how other developers use Xojo and how long they’ve been using the product.  I highly recommend that you check it out and give it a listen.

More information on how to subscribe to the podcast at

App Wrapper 3 [u]

Xojo makes developing Mac OS X apps very easy but getting those apps ready for distribution can be a daunting task. Apple has had the option for a while to not open applications from unknown developers using a security option that Apple calls Gatekeeper. Gatekeeper, in effect, restricts which apps a user can run on their computer. This theoretically helps protect users from installing malicious applications.

Gatekeeper has 3 settings: Mac App Store that allows only applications downloaded form the Mac App Store. Mac App Store and Identified Developers that allows Mac App Store and applications signed by certified Apple developers. Anywhere that allows any application to be launched. The default in Yosemite, is the 2nd option (Mac App Store and identified developers). Since Apple only recognizes its own developer certificates they have more control over the entire process.

To pass Gatekeeper you need to have a verified Apple Developer Account. Then use Keychain Assistant to request a certificate from Apple through the Apple Developer portal. Setting up this account costs $99 a year and it isn’t too difficult – Apple has some nice instructions for the novice developer to figure this out. However, signing your Xojo app isn’t the most straightforward thing to do, but we’ll get to that in a minute.

If you are trying to distribute your app on the Mac App Store you have to worry about a myriad of things that Xojo doesn’t automatically give you. The first is code signing your application. Other issues include Retina display settings and Retina image sizes, how you interact with the system via the App Sandbox, and if you are using iCloud or other Apple online services, Push Notifications or Game Center.

That’s a ton of stuff to figure out how to add on your own to your project. For several years we had our own postscript build that called a bunch of command line utilities that did the code signing, set the proper plist entries and so on. It was a pain to maintain and move to different projects for a variety of reasons – one of them being that finding out the cause of a script error wasn’t always straightforward!

AW Open

Enter App Wrapper from Ohanaaware. We’ve used App Wrapper 2 for a while and have been extremely happy with it. It takes the guess work out of configuring your Mac OS X distribution because the utility remembers the settings you’ve used for each application. This includes remembering which code signatures to use. Since we create apps for ourselves and for clients this is particularly useful.

App Wrapper 3 has five panels to choose from. The Report tab gives an overview of everything in the application along with reasons why it may be rejected from the Mac App Store. In the example below I’m showing ARGen, our ActiveRecord utility, that is NOT in the Mac App Store. If I did try to submit to the Mac App Store it would be rejected for three reasons: first, it uses the Sparkle framework, and the eSellerate libraries – both of which are rejected by Apple and are unnecessary in Mac App Store applications. The second reasons is that CubeSQL references QuickTime in the plugin (which is surprising since it’s a database plugin).

AW General

The General tab lets you set a number of variables needed by Apple. What’s the Category, minimum Mac OS X that can run the application. The copyright information. The version information, high resolution mode (Retina), which code signature to use, registering an Apple help file, and how the app should be packaged for you (to name the highlights). This is, by far, the panel you’ll need to pay close attention to.

One thing that was less than clear to me when setting up my app in App Wrapper 3 was the About Info credits. In version 2 there was checkbox to include this in the build. In version 3 it gets put into your application. The solution is to simply clear the text field but it’s not obvious. The default text is using my name and information. If I’m creating client builds I will now have to deliberately clear this out before I send to the client. Otherwise, there will be a Credits.rtf file in the Resources directory of the bundle.

For the Mac App Store the code signing certificate will automatically set the Packing for you. For non Mac App Store distribution you have the option of no packing, zip file, or Apple Installer. For us, we distribute via disk image (DMG) so we leave it to none.

The Capabilities panel is all about the App Sandbox and how the app interacts with it. There are a number of things with Sand Boxing that will make your development life a joy. All that fun stuff is beyond the scope of this review but if you’re going to submit to the Mac App Store you should really do some research!

The Info panel is all about setting up the info.plist properly for your app. The top list is what changes App Wrapper will add to the plist and the other sections are for Document Types, URL Aliases, and Uniform Type Identifiers. Some of these are set from Xojo and others are not.

AW Wrapping

The Other panel lets you clean up the application bundle. You can remove subversion remnants, DS_Store files, language files, and whether or not to clean up some of the architecture such as removing any old PowerPC code, or restricting it to Intel 32 bit or 64 bit. You even have the ability to fine tune the files and ignore them, delete them, delete them for the Mac App Store and so on.

To actually wrap your application you have two options. The first is to do it all manually. Drag your built executable on to App Wrapper 3, set it up all up, and simply hit the Wrap button in the upper right corner. You’ll want to do this manually a time or two to make sure there are no major errors.

The second, and probably preferable way, in my opinion, is to hit the Xojo Script button and drag the script file into the Finder and then into your project and put it under the build steps for Mac OS X (supposedly you can go direct from the App Wrapper to the Xojo IDE but I couldn’t get this work). Then it’s just a matter of hitting build in the Xojo IDE. The application is built and the script will use the executable and run App Wrapper in the background. Voila! You have a code signed application that’s ready for upload to it’s final destination (assuming no errors).

In App Wrapper 2 we used the command line option with our own Postbuild script. Version 3 doesn’t appear to allow this so we’ll have to modify our workflow a bit to use it but it doesn’t appear very onerous of a task (at this point). The benefits of using App Wrapper far outweigh the chore of setting it up.

Once your application is wrapped there are a couple of options for testing. The first is to test the application with Quarantine or RB App Checker Lite. Quarantine lets you start an application as if it was downloaded from the internet. This is handy because applications built on your machine are automatically considered ‘safe’. RB App Checker Lite from Rainer Brockerhoff lets you verify the certificate and check the entitlement settings before submitting it to the Mac App Store. Both of these tests are useful.

App Wrapper 3 has three purchase options. First is the 30-day Single User “Pay As You Go” option for $9.99 that runs for 30 days but can no longer be used at the end of the 30 days. The 1-Year Single User plan costs $20. The 1-Year Small Team plan costs $199.99 and lets App Wrapper be used by up to 10 developers. Both the Single User and Small Team options have free upgrades for a year after purchase and allow you to use the application even after the time period is up (no usage expiration).

The Pay As You Go option seems very odd. For a mere $20 you can get the Single User plan and can use it forever. I see no advantage in the Pay As You Go option and, to me, is more of a software rental plan.

[Update:] The 1-Year Single User plan is normally $49.99 but is $29.99 until the end of November.  Sorry for the error.

If you haven’t already checked out App Wrapper I recommend that you do. It is by far the easiest way to get your app ready for Gatekeeper and the Mac App Store. Without it, you may spend a lot of time figuring it out on your own. From experience I can say that Apple’s documentation assumes you’re using xCode so figuring it out for Xojo makes it that much harder.  Ohanaware has already done it for you!

For more information on App Wrapper 3 please visit


For years we’ve been doing some basic checking in the WebSession.Open event of our Xojo web apps. First, we check to see how many open sessions we have and if it’s over a preset number.  The second check we do is to see how many open sessions we have for the current IP address. We set it to something low like 10 because when some joker decided a few years ago to prove that Xojo web apps suck. He opened up our training app, and then hit refresh 150 times and then complained about how unresponsive the app was (thus proving his point that Xojo web apps suck, I guess).

In our apps, if either of those conditions is met we use a ShowURL to redirect to one of the webpages on our regular website to show the user that the app is either too busy or something bad happened. It’s worked decent enough that I’ve never revisited it until this past weekend when several users alerted me to the redirect never clearing. Since I couldn’t login to my own app I restarted the server and everything was fine again.

I tend to use a log file on my web apps to track certain conditions and this morning I added more information so I could track this more. I just happened to be monitoring the app (in my browser) when my session count spiked to around 50 in just a few seconds. Looking at the new information in the log file the IP addresses were all over the place.  An attack?  I dunno but it sure seemed like it.

Unfortunately, the session count didn’t go down immediately like I expected it too and, in fact, it didn’t go down even up to an hour later. I had over a hundred open sessions before it stopped (did Xojo Cloud security close the port?).

When that happened I started looking at code. Some of this code I hadn’t looked at in a year or more. Basically the code did the two checks in the WebSession.Open even and if the function returned true I immediately tried to call WebSession.Quit.

Guess what happens when you do that? If you guessed nothing you’d be wrong. It generates a Nil Object Exception first with the following stack trace:

Function WebSession._WaitingForSync() as boolean


Sub _SessionShutdownThread.Event_Run()

And after that then it does nothing. The WebSession never quits – ever – until something kills the app.

My solution was to put a timer property into the Session and if I meets my quit conditions start the timer and in the action event (using AddHandler) quit the Session. Seems to work as expected now.

This is filed in Feedback <feedback://showreport?report_id=35794> and it appears that it’s been verified. There are some additional details on their response. They know why it’s happening at least. Let’s hope this one gets fixed sooner rather than later.

I’ve seen various people have issues with WebSession.Quit over the years. This might be the root cause of some of those.

Subclassing vs Extends vs Containers

Xojo is really powerful because it gives you multiple ways to create really powerful controls.  Today I’ll discuss subclassing, extends, and containers.


First, subclassing a control is really easy to do.  Create a new class and set the super to the control you are extending.  A great example of this is the Xojo ListBox.  In its raw form it’s powerful, but limited, in its functionality.  To have those awesome alternating row colors we subclass the ListBox and put our code in the CellBackgroundPaint event.

One of the things that people forget to do when subclassing the control is to repeat the events that that they are using.  Because I’ve used the CellBackgroundPaint event it’s not available to any instances of the class.  Sometimes this is desirable, but sometimes you want the control to still have those events.

The solution is simple.  Define a new event named CellBackgroundPaint and use the same properties and return value.  This means that you, the developer, can have the alternating colors in your listbox but also still have the opportunity to override those colors if you need them.

The other powerful thing about subclassing is that you can continue to subclass them all you want.  In one of our projects we have the following Listbox hierarchy:  ListBox -> AlternatingRowListbox -> CustomCellListbox -> RecordsetListbox.  Each one is still a Listbox, but each gets all of the events and properties of its supers so this means that the RecordsetListbox automatically gets the alternating rows even though it specializes in loading the listbox by using a Recordset.


Sometimes, though, you only want to add a single method to a class.  Creating a subclass to do this might be overkill, especially if you have to go back and and retrofit this change in a lot of places.  A good example of this the PopupMenu where you often have to set the text of the PopupMenu to some value.  The code is often like this:

for i as integer = 0 to pm.ListCount-1
   if pm.list(i) = sSomeValue then
      pm.ListIndex = i

It’s not hard but after you’ve done this several dozen times you come to the realization that this should be automated somehow because it’s a lot copying and pasting and if you find a better way in the future you’ll hate yourself (trust me, I’ve done this).  You could easily subclass the PopupMenu and go through and change the Super of all existing popupmenu’s, but there is an even simpler way of doing this:  Extends

Extends lets you create your own method that acts like it’s part of the class.  If we were to take our code above for the PopupMenu and put it into a module (it won’t work in class objects like Windows) our code would look like this:

Sub SetText(extends pm as PopupMenu, assigns s as String)
   for i as integer = 0 to pm.ListCount-1
      if pm.list(i) = s then
         pm.ListIndex = i
End Sub

Same code, just using the extends.  What’s great about this is that using it super easy.  It becomes part of the AutoComplete list and is a ‘dot’ extension (just as if it was a subclassed item).  So calling it is like this:

pmFont.setText = sTheFont

I don’t remember when the Extends method was introduced but since it was introduced the number of Subclassed items in our projects has dropped dramatically.  Using Extends fails in one area and that’s Properties.  If you need a property for the additional functionality, you’ll still need to subclass the control and add the property to the subclass.


This final method may confuse some people.  Using a container control isn’t a subclass nor using the extends.  Containers are incredibly powerful controls in Xojo, though, because they allow you to create combinations of controls (and their subclasses) in unique and reusable ways.  A great example of this is a typical Save/Cancel pair of pushbuttons on a dialog or window.  On Macintosh OS X the Save button is on the right and the Cancel on the left.  On Windows it’s opposite.  In Linux, it’s the same order as Windows but the buttons have a different height.

There’s nothing stopping you from adding code to every window that has this Save/Cancel combination so that they’re in the proper location and height.  But why?  This is Xojo, a modern object oriented language!  Plus, I hope you’re as lazy of a programmer as I am because that’s a lot of work.  Use a container!

Create the container, add the pushbuttons.  I named my buttons Left and Right because their function is determined at runtime depending on the platform.  I add an Open event and in that event I add code like this:

#if TargetMacOS then
   btnRight.caption = kSave
   btnRight.Default = true
   btnRight.cancel = false
   btnLeft.caption = kCancel
   btnRight.Default = false
   btnLeft.Cancel = true
   btnRight.caption = kCancel
   btnRight.Default = false
   btnRight.cancel = true
   btnLeft.caption = kSave
   btnRight.Default = true
   btnLeft.Cancel = false

The kCancel and kSave are dynamic constants holding the proper strings.  In the ActionEvent of the buttons I have code like this to raise an event to tell the parent container (a window or another container) what happened:

Sub Action()
   #if TargetMacOS then
      RaiseEvent Action false
      RaiseEvent Action True
End Sub

Sub Action()
   #if TargetMacOS then
      RaiseEvent Action true
      RaiseEvent Action False
End Sub

And finally the Action event which I’ve defined is:

Event Action(bSave as boolean)

It’s really as simple as that!  No matter which platform I’m on the Action event from this container tells me if the user pressed save or cancel.

Why did I include Containers in this article?  Good question!  It’s because you can think of Container Controls as a way to subclass Windows or WebPages without it being a window/page.  You can reuse Containers as many places as you want and when you change the original it changes the children (be aware though that there are some caveats with this statement – especially with WebContainers).  And even better is that you can dynamically add and remove containers at runtime.  Adding them is simple by using the EmbedWithin commands and to remove them use the Close method (I always set their visibility to false first).

We use a LOT of containers in our consulting work.  We find that it tends to simplify the code (remember being a lazy programmer isn’t a bad thing).  We’ve had windows/pages that have thousands of control and hundreds of controls visible at any given time but with a UI that complex we like to break them out into Containers.  So rather than having a Navigator with a listing of thousands of controls (and their labels!) we break it out logically into containers and the Navigator has maybe a dozen containers instead.

Each container has Save, Load, Validate set of methods (sometimes this is using an Interface) and whatever other methods are required but the point is that the overall window/page doesn’t need to know, or care, what the individual controls are and how to load, save, and validate their data – it only has to know enough to call the Load, Save and validate methods in each container.

With Xojo for Web, containers are even more important because you can create ‘repeating rows of controls’ that are very complex.  We wrote an entire accounting application for a client in using Xojo for Web and as you can imagine creating an Invoice Line Item row that needs Qty, Price, Amount, Sales tax and the necessary UI to add and delete the row, void a row, make it non-taxable can be complex.  Sure, we could have come up with a UI that doesn’t have that in a list, but frankly, it’s not that hard using WebContainers.

Containers are very powerful things and a great way to combine controls into one unit.  It’s also a way to create a dynamic control that can easily be added a runtime.  Rather than using a ControlSet (i.e. control array) and cloning an existing control (and having to keep track of the index) you can dynamically place your container that holds your one control.  We don’t use this technique very often but it does come up every now and then.


Subclassing a control in Xojo is pretty easy but sometimes overkill.  Using the extends method works great if you’re adding methods to a class/control and don’t need to add any properties.  Containers are powerful constructs that let you combine controls into a reusable object that have their own events and that can be added dynamically.  As a Xojo programmer you should be familiar with all three methods.

Did I forget anything?

New Video: ServerSockets

As a companion piece to the video from earlier in the week we added a new 38 minute video today on using a ServerSocket that allows your Xojo application to communication with multiple client apps that are using TCPSockets.  It turns out that it’s incredibly easy to use if you understand TCPSockets (which hopefully you know better now with that video).

I was chatting with an old developer friend this morning that I wish I had made this video a number of years ago when I was beating my head up against the wall on a big project that was using TCPSockets and ServerSockets.  Hopefully this gets you over the hump and you get some use out of it.  My pain is your gain in this case.

In this video we create a TCPSocket subclass on the ‘server’ that handles all of the communication details with the client apps.  The ServerSocket is a pretty dumb object (since it knows nothing about about our communications protocol with the client apps) but it is a pretty powerful class since you don’t have to do much to communicate to the clients other than provide a socket.

Our client apps can send a command, a single file, or a folder full of files.  Each client could potentially send a file with the same name and it would keep track of it properly.  We wrap up the video with having the server app send a message to all of the connected clients.

Direct link for subscribers:

New Video: TCPSockets

Today, I added a new video to our Xojo training area. This new video guides you through the steps to using TCPSockets in your Xojo applications. In this nearly 90 minute video we create a sender application and a receiver application and by sending some simple data (a command and data) to the receiver to make sure we’re processing everything properly.

Then, we send a file (of any size) from the Mac sender app to the Windows receiver app. We do some basic file metrics to make sure the file we receive is the same as we sent. In the video I forget to unpack part of the data properly and it’s this file checking step that finds the problem (sometimes doing something wrong is instructive in these videos)!

Screen Shot 2014-10-08 at 10.16.38 AM

After that, sending a folder full of files is no big deal and in the video we clearly see that the sender has a queue of files that it’s going to send in multiple data segments, and the receiver only has a few of the segments yet.

Finally, we create an acknowledge message that gets sent back to the Sender application proving that we can have two way communication between the applications.

We now have over 55 hours of training video of Real Studio and Xojo.  Since we rewrote the training area using Xojo for Web we’ve served up over 8,700 hours of streaming video to thousands of developers around the world.