Implicit Instance is Evil

Xojo has had Implicit Instances of Windows and WebPages from the very beginning and I was so happy when they gave us the option of using it or not.  I can tell you from experience debugging newbie apps that Implicit Instance is evil because it often leads to subtle and hard to find errors.

The implicit instance lets us do some very simple things like:

Window1 is shown.  No big deal.  For simple apps this is no problem and fast and easy.  That simplicity comes with some perils because window1 loads whenever any control or property on that window is checked.

For example, a lot of developers will do something  like this:

window1.close //close the window

if window1 <> nil then
   //Window is open.  WTF!  I just closed it!

The problem is that simply by doing this comparison, window1 is loaded into memory and depending on the other window settings it may become visible.  It drives developer crazy.

Setting ImplicitInstance = false forces the developer to make a new instance of Window1 if they want to use it:

dim w as new Window1

I think this is the preferable approach because it’s safer.  It will never give you Window1 by accident.  In fact, if you attempt to do this with window1.implicitinstace = false:

if window1 <> nil then
   //Do something.

The Xojo compiler will give you an error that says:  Expected a value of type class Window1.Window1, but found a static namespace reference to class Window1.Window1.  This is a roundabout way of saying you can’t call window1 directly since that’s the class name when in reality you need to be checking for an instance of the class. That class instance cannot be named Window1 (because that’s the class name).

So how would you check to see if a Window is already open?  That’s easy.  The Window and WindowCount methods are there for you to do just that.  Iterate through the window listing and when you use the ISA method to ask if it’s of type Window1.  If it is, then do something.

  for i as integer = 0 to WindowCount-1

if window(i) isa Window1 then
   //Do something with the Window1 instance.
   //You have to cast it as Window1 from the Window method
   dim w as window1
   w = Window1(window(i))
   w.someproperty = false //set a public property
   w.LoadNewData //call a public method //brings the window to the front


A common thing to do is close all instances of a particular window.  Using the above code might fail if you have multiple instances of a window open.  Here is the code that closes all instances of a type of window.

  for i as integer = windowcount-1 downto 0

if window(i) isa Window1 then

In this case we must iterate backwards through the array.  Think about it if you are confused as to why.  Better yet, test it yourself.

Web apps have a similar property in the WebSession.PageCount and WebSession.PageAtIndex methods.

  for i as integer = 0 to session.PageCount-1

dim w as WebPage = Session.PageAtIndex(i)

if w is a WebPage1 then
   //do something with WebPage1


The drawback, if you can call it that, to having Implicit Instance = false is that as you call new windows or web pages you haven’t done anything to the old ones.  Depending upon your application this may cause long term memory issues especially as the app gets a collection of pages that are no longer used.   For short lived apps this usually isn’t a problem.

To solve this you can either iterate through the existing windows/pages to find the one you’re looking to reuse or simply close it as you open your new one.  Either way, I don’t think the burden is too high.

It is my not-so-humble opinion, that leaving ImplicitInstance = true is bad for you as a Xojo programmer.  Simply put, Implicit Instance is evil and you should avoid using it – especially in larger applications.

What say you my Xojo developers?    Do you like to turn Implicit Instance off or do you even care?

Listbox and Tag Options

The Listbox is a very powerful control, in my opinion.  Out of the box it doesn’t have a lot of capabilities but it’s easily extendable and it’s possible to create some complex grid-like applications using the standard Listbox.  Is it perfect?  No, but it’s more than adequate for most developer needs.  There are a number of options for showing and storing data.

A new user to Xojo recently asked me about the various tag options in the Xojo Listbox.  She wasn’t sure when you’d want to use RowTag versus ColumnTag versus CellTag.  It was a good question – I hadn’t given it much thought.  I like questions like this because it forces me to think like a new Xojo developer.

Most Tags in Xojo are the Variant datatype and that means they are very good at storing whatever you want in them.  We often say, “just stash the data in the tag”.  Since you can put practically anything in a variant it’s very convenient to use it.  I suspect that whenever the new framework makes it into UI elements the tag will turn into an Auto variable (which will lead to interesting problems but that’s a post for another time).

When it comes to the Xojo Listbox, I know some Xojo developers like to make columns of zero width and put data in these hidden cells.  I dislike this approach for several reasons.  One, it limits what the listbox GUI can do.  A zero width column means that you probably don’t have column resizing on (and if you do the columns are accessible to the user).  Two, it’s not how the control was intended to be used.  Three, we have Tag options to eliminate the need to do this.

We predominantly use the Listbox.RowTag property to store our data.  A vast majority of our projects are database driven and since we use ActiveRecord a lot we almost always have a class object (the ActiveRecord object) that has our record stashed away in the RowTag property.  The listbox may only have 2 or 3 visible columns of data but the ActiveRecord object might have dozens of properties (which reflect the fields in the table).

This gives us the advantage that we only have to query the database once and that’s to load the listbox.  Subsequent edit/update and delete operations simply use the object that’s already in the RowTag.  The user selects the row, we get the object out of the RowTag property and then pass it on to whatever method needs to work with it.  This fits 95% of everything we ever do with a Listbox.

The CellTag comes in on projects where we’re not using ActiveRecord.  Things like preferences come to mind where it’s data but not database related.  We load the Listbox cell data with what the user can edit.  Then, in the CellTag property put a copy of the visible data so later on we can compare the Cell text to what’s in the CellTag.  Even in this case, though, we still use the RowTag property for identification purposes.

Using the CellTag and comparing it to the Cell text is convenient when doing inline-editing of the Listbox data.  The comparison can happen at the Cell Lost Focus event or in a generic Validate method before saving the data.  Either way, the CellTag data is ‘hidden’ and the user can’t mess with it.

The ColumnTag has been around a couple of years and I can’t say we’ve used it much.  I can see the benefit of using it, however, to make things like Pivot Table using the Listbox.  This isn’t a trivial task, mind you, but I would treat it like the RowTag.  It’s there for use and I’m sure someone out there has a reason to use it.

If you find yourself making zero width columns to store data in your Listbox you should look at the various Tag properties.  Trust me, it will make your application work better and be safer with your data.

What interesting things do you use Listbox tags for?

Using UI to Store and Manipulate Data Is Not a Good Idea

I’ve fielded a number of questions from developers over the years asking about the Xojo Listbox.  They question is if it’s a good idea to store and manipulate data in the Listbox.  While it’s possible, I say the answer is no, the Listbox is NOT a good place to store and manipulate data.  It’s also a poor place to put your business logic.

The Listbox is a user interface element.  It’s job, if you will, is to present data to the user in a grid.  Along the way you get the added advantage of resizable columns, sortable columns, the ability to do things in the cell with text, checkboxes, and even doing your own custom drawing and handling.  It conveniently allows us to stash data in row, column, and even cell tags and therein lies the delicious dilemma for users that need to manipulate data.

It’s common to see Xojo developers load a listbox and while it’s loaded manipulate all data in its cells and cell tags.  Their listbox events are filled with code to do things to other cells, and tags, and there is often a lot of code for business logic in them.  Then, when it’s all done, they save it off in whatever format they’re using.  This is all fine but it’s a royal pain to debug because most people don’t think about using a constant value, say kAverageValue, but instead say me.cell(iRow, 5) = str(NewAverage). To be honest this works well until you add a new column.  Then, all of your code for the cells to the right of the new column is wrong and you won’t know it until you test.

Another thing that I’ve seen happen is conversion errors.  The developer stashes a numeric value in the listbox cell and formats it.  Then has to go through the process of converting it back to a number for use in the database or file.  This often leads to issues that, again, can be tricky to track down.

Instead, we recommend using a data class that represents each row of data.  The whole list of data can be thought of as an array of data and we store each row in the row tag property.  What it boils down to is that when you’re start working with the data you manipulate the data in the data class rather than in the UI.  Then you update the UI from the data class.  The heart of it is your data class and it’s there you should put your business logic.  If cell 5 can’t be a negative number if cell 1 is greater then 100 it might make more sense to put the validation code in the data class rather than in the listbox itself.  That way you can do validation logic based on class property names rather than listbox row and column values.

If iAverage > 100 and iSetPoint < 0 then

is easier to understand than

if me.cell(row, 1).val > 100 and me.cell(row, 5).val < 0 then

The other thing that’s bad about depending upon the UI to store your data is now you are tied to that control.  I know developers that have invested a lot of time using the StyleGrid and when it wasn’t updated they spent a lot of time rewriting it for the listbox.  Some rewriting is inevitable, but if you can uncouple your data and your UI it’s much easier to move to another control later on.

We use ActiveRecord a lot and whenever possible we put our business logic in it rather than the listbox.  Does this mean that we get rid of all logic in the listbox?  No!  If column 0 can’t be negative, ever, then by all means put that logic in there.  But if the value in column 0 depends on another column we try to put it in the ActiveRecord data class.  The listbox simply becomes the input and display mechanism for the class.

Am I suggesting your go rewrite your listbox today?  Absolutely not, but perhaps the next time you want to make your listbox jump through hoops, perhaps you uncouple the data and put your business logic in a data class rather than in the listbox.  You might like the results.

Thoughts?  Do you agree or disagree?

VB6 and Windows 10

It looks like the Visual Basic 6 holdouts can breathe yet another sigh of relief.  Visual Basic 6 seems to work with Windows 10 as do VB6 apps, though not without some caveats.

I’ve been reading a few threads in various forums where most people have had few to no problems developing VB6 apps or running them in Windows 10.  I’ve seen at least one VB6 developer that claims they’re OCX laden application has issues when loading.  They say that some of the controls simply fail to load at runtime.  Funny enough, it happens only on 32 bit Windows and 64 bit Windows 10 works fine.  They gave no information if these were new installs or legacy upgrades.

Another developer claims to have problems installing VB6 Service Pack 6 on Windows 10.  They tracked it down to two Registry keys not being written.  This website gives a process to install VB6 in Windows 10.  The fact there is now a procedure to install an old app on a new operating system should be pause for concern.

The only way to get hold of VB6 is to have a MSDN subscription.  The subscription is $500 so that doesn’t seem like a huge burden.  But then again, remember that Microsoft is not supporting VB6 though the VB6 runtime is shipped with Windows 10.

There are a boatload of VB6 applications still out there so I think support for VB6 will be around for a long time.  In April, 2014 an InfoQ article  stated there were hundreds of VB6 developer positions listed on Dice and Monster.  VB6 officially went out of support in 2008 so good luck finding entry level and even junior developers to fill those spots – no one is learning VB6 any more.  One of my old clients has had a revolving door of VB6 developers for several years now and it’s getting harder and harder to find competent VB6 developers, and developers that wish to work with it.

As a Xojo consultant we’ve converted quite a few VB6 apps.  Well, convert is a strong word, really it’s a rewrite.  Despite both using a BASIC-like language, the two languages are diverging rapidly (not that they were ever really all that close to begin with).  Many issues that we spent a lot of time working around in VB6 just don’t happen in Xojo.  In our experience entire modules and classes just disappear because we don’t need them in Xojo.

Xojo is updated several times a year while VB6 isn’t.  Xojo is about ready to release a new version that creates 64 bit versions of Mac OS X, Windows, Linux for desktop, console, and web apps.  iOS will also be 32 bit and 64 bit.  VB6 is stuck building only 32 bit Windows apps.

Is Xojo a perfect alternative for VB6?  No.  It is not perfect for every application.  Because its strength is really cross platform applications there are compromises all over the place.  If you look at Mac and Linux applications they just don’t have the complex controls that Windows does.  For some this is a deal breaker because their application demands it.  However, if you want a Mac OS X or Linux version of your application you’ll want to redesign the UI anyway.

Ten years ago our clients came to us for Windows apps first and if we could do a Mac version for the graphics geek that was great.  Now, they come to us for Mac apps first and if we can do a Windows version for the accountant in the corner that’s great.  Xojo does web apps now and that’s become an increasingly larger portion of our business and VB6 just doesn’t compete in that area.

The Xojo universe is full of VB6 developers and the Xojo forums are full of them.  The developers that have found and started using Xojo usually go through a short learning curve and a few WTF moments.  And then, after they stop trying to make Xojo work just like VB6, they embrace the tool and enjoy life again.

Windows 10 is yet another bullet dodged for VB6 hold outs.  At what point do you start to panic and find an alternative?  I guess if you’ve waited this long you’re hoping that Microsoft keeps supporting the VB6 runtime forever.

I am biased, naturally, but Xojo really is a good product and a good solution for many applications.  If you would like to find out some rough costs of moving your application to Xojo we have a utility that will give us some metrics on your VB6 project.  It can be found at

Happy coding!

Having the Same Object Handle Multiple Tasks

It’s often tempting to write some code to do a task and make it generic enough to handle similar but different tasks.  A great example that we dealt this this week was a picker dialog that was used generically for people, organizations, and skill sets in a Xojo web app.

It made sense.  The dialog is called from multiple places and it does the exact same thing in each place (displays a list and the user can filter on the list).  What’s different is what data we pass into it for initialization and what data it loads for display.  We wanted the exact same UI in all three cases.

We all want to write as little code as possible.  That’s what’s great about being a lazy programmer.  Do more with less.  That works until it doesn’t and, to be honest, we’ve learned, the hard way, that sometimes the best approach is to make your objects do one thing and one thing only.  Why?  Because inevitably the client will say, this is great, but we want to filter for ‘x’ on people, and ‘y’ on organizations, and neither of those things are interchangeable UI-wise and neither x nor y make zero sense for skill sets.

The first approach is to put lots of if-then-else blocks into what was once a very generic picker dialog.  Now it’s a complex UI that has three distinct code paths.  This complicates testing since every time you make a change it now has to be tested in all three areas.  What worse is the code becomes complex and if you’re in a hurry (and who isn’t?) it’s easy to change the WRONG bit of code.

Our solution was to write the first dialog, get the UI working properly, and then duplicate the entire object and customize it for its new task.  <Gasp>  I know, bad OO programming, right?  We disagree and that’s coming from the school of hard knocks.

The end result is that we have specific pickers for people, organizations, and skill sets.  It’s now simple for a developer to make a change for the picker in question.  No longer do they have to think, “gee, which datatype am I fixing this time,” and possibly get it wrong.  Keeping it simple reduces accidental coding bugs and it reduces unintended bugs due to code changes.

Testing also becomes easier because if we’ve done something to the employee picker, we don’t have to test organizations or skill sets.  Likewise for the other two areas.  Simple is good.

The one area that it does become a bit messier is if we have to do general user interface overhaul.  Now you potentially have three places to do it.  However, since we have WebStyles with web apps this becomes trivial unless you’re rearranging UI elements.  Xojo Desktop apps are a little harder since there are no styles but in those cases it’s actually fairly easy to copy/paste UI from one form to another (assuming that’s possible).

Call me cynical, but I would gladly work on UI for an hour to ensure they’re identical to futzing around with code in three separate code branches that are nearly identical.  I am a lazy developer after all.

Our experience says that generic, reusable objects, often lead us into trouble, so we tend simply not to do them.  But how do you teach that to a new developer and one that’s trying to do their best to use good OO conventions?  And when do you reach that breaking point where the generic way makes it harder than its worth?  Good questions that I don’t have good answers for.

Happy coding!

New Xojo Framework Thoughts

I don’t think application development is very hard. It is however complex and this, I think more than anything else, makes it appear hard because people equate complexity with being hard. Xojo does a pretty good job of making things less complex for us and I honestly truly appreciate that.

The new framework that we’re really seeing for the first time in iOS has some good things in it. Database errors throw an exception. I like that that because that’s what we (BKeeney Software) does with our own SQLSelect and SQLExecute extends methods (name SQLSelectRaiseOnError and SQLExecuteRaiseOnError). Not everything I agree with though.

In the existing framework we would do something like this to get the integer value of the aTextField.

dim i as integer

i = TextField1.text.val

We’ve been using this for close to 15 years. Works great. Now, in the new framework we have to use different converters and use code like this:

dim i as integer

i = Integer.FromText( TextField1.Text)

Seems pretty straightforward, no? Well, no, because in their infinite wisdom, if there is no text (i.e. a blank string) an “InvalidArgumentException” is thrown. WTF?!

Instead, you will have to do this instead.

Dim i As Integer

If Not TextField1.Text.Empty Then
   i = Integer.FromText(TextField1.Text)
End If

But even then, if there text there that can’t be converted to an integer it throws the exception. I sort of agree with that change.  But, I don’t see this change as being ‘better’ or even simpler. If anything it’s more complex and it’s getting away from the strengths of BASIC that made many us use it over other languages in the first place.

So really what you’ll need to do is something like this:

Dim i As Integer

   If Not TextField1.Text.Empty Then
      i = Integer.FromText(TextField1.Text)
   End If
catch e as InvalidArgumentException
   i = 0 //if that’s what you really want.

You really want to do that several thousand times in a big accounting application?  When I suggested that I’ll just create my own extends methods to match current functionality the response was “Not doing so is a great opportunity for silently doing something really wrong.” Well, I guess at that point it’s MY problem, no?  If something goes wrong, and I did my own method, it really *is* my problem.  Or are the Xojo Programming Police going to take away my license?

Xojo is trying to make a complex process idiot proof. I appreciate the effort, I really do, because Lord know I can be an idiot at time. All they did, in my opinion, was make this simple process more complex. I think they may hinder adoption of the new framework. My guess, though, is that they’ll force it down our throats for console, desktop, and web when the time comes.

What do you think, my friends? Is the new framework helping us or hurting us or is this just a “this is different so I hate it” reaction?

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

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.

Data Paging Control

A lot of Xojo developers don’t give too much thought to how much data they’re loading into a listbox. For many desktop apps a couple of thousand rows is not uncommon and, frankly, not a big deal. Push that to ten thousand rows and things start to get dicey and when you get to a million rows you’re talking some serious wait time for all million rows to get added to a list box.

For web apps it’s even worse. When the server gets the request to load a WebListbox with a million rows it has to build all of the HTML, first, on the server, push it down the internet connection to your browser, and THEN the browser has to reconstruct those million rows of HTML into a display. Any time you deal with strings there is a performance penalty and needless to say a million rows of data is huge hit to performance.

Trying to show the user a million rows is bad on multiple levels. First, your application is slammed with unnecessary string handling and second, the user can’t possibly handle a million rows of data. The listbox scrolling alone would be a nightmare! Just don’t do this!

Web apps have been using paging controls for years to limit the amount of data the user sees. I’ve seen some web sites limit this data to 100 rows and some to even less unless the user specifies more. That way the onus is on the user for the webpage being slow.  And more recently I’ve seen more desktop apps limiting the amount of data too.

Data Page Control

Today we released a new 48 minute training video showing you how to build your own paging control in Xojo desktop and web apps. We build the Paging Control using a Container Control and standard controls and then use it control a listbox. Then it’s a matter of using the SQL keywords LIMIT and OFFSET to control which records are returned. Of course the video comes with a desktop and web project file with source code you can use in your own projects.

The running example of the web app is at

This video is available to subscribers at

If you’ve not looked at our training videos you might find some interesting things. I invite you to take a look!