Xojo 2017 R2.1 and Updated Roadmap

I’ve had a hellacious travel schedule the past six months so I apologize that I’ve not been up to snuff on Xojo news. Last week Xojo 2017 Release 2.1 was made public and earlier this week Xojo CEO, Geoff Perlman, penned a blog post about the short-term roadmap for Xojo. Let’s dig in!

First, the 2.1 release has a mere 16 bug fixes in it. This dot release fixes some critical Linux, and Windows bugs. A few IDE bugs were addressed and the PostgreSQLDatabase plugin was updated. Many of these bugs won’t affect everyone but it’s definitely worth upgrading from R2 if you have not already done so.

Now on to Geoff’s short-term roadmap. You can read the entire blog at https://blog.xojo.com/2017/09/19/the-short-term-xojo-roadmap/. To summarize it in a nutshell: 64-bit is taking them longer than expected.

To this I say, ‘Duh’. Anyone who expected 64-bit to be done by this time hasn’t been around very long. Xojo has consistently blown their estimates for most (all?) of their big projects. The transition to Cocoa from Carbon took a lot longer than originally announced. iOS took longer than expected. The introduction of the Xojo IDE from the Real Studio IDE was also delayed (as a side note I’m still amused at the accusation that I personally caused a 6-month delay in the Xojo IDE due to a blog post).

The point isn’t, ‘Oh my gosh, Xojo has yet another delay’ it’s that Xojo is very bad at estimating this stuff. Some of this is on them but some of it is beyond their control. Supporting mac OS, Windows, Linux, iOS, Raspberry Pi, desktop, console, and web apps is a mammoth undertaking. I am constantly amazed at the magic Xojo performs without my knowledge. To me it ‘just works’.

Apple, bless their hearts, changes things on a whim every year at a minimum (sometimes even more often than that) and causes Xojo to play catch up. And they usually do this with little notice. The current change being that the iOS Simulator will no longer support 32-bit apps so guess who has to scramble to make it work now?

Linux distributions seem to change daily. Xojo has to scramble to catch up with those changes too. They recently updated Xojo to use GTK3 and that was a big deal. They sort of had to do this upgrade because GTK2 was pretty long in the tooth. I can only imagine the internal efforts they did for testing.

Windows doesn’t change much for better and worse. The technology from ten years ago still works but that’s not necessarily the best ‘modern’ approach for Windows. Many users complain about flicker when windows are resized. This is a valid complaint but because Windows does not double-buffer their windows like Mac and Linux the older Win32 controls flicker like mad under many circumstances.

Regardless, 64-bit is the roadblock for other things. If you were hoping for Android, interops, or plugins compiled in Xojo to be released in 2017 you’re out of luck. This is what happens with a small development team. There simply isn’t enough man-hours to work around delays in some projects. This happens in ALL software development products but with a small team this impacts everything.

The only bit of good news from Geoff’s blog post is that the Windows framework is getting a big update. This update will ‘dramatically’ reduce flicker according to Geoff. No word on what exactly they’re changing though a thread on the forums from Aug 9 might give a little clue. Changing transparency seems like a little thing but perhaps they plan on implementing a double-buffering scheme. Until we find out more it’s not worth speculating. It seems like this new scheme might make it by the end of this year. So either this has been in the works for a long time or it’s not huge from a coding standpoint.

Promising services based on a product feature that doesn’t yet exist is dangerous. If you were promising Cocoa, iOS, or 64-bit versions before they were actually released you did your customers a disservice. I remember one XDC where a database ORM (Object Relational Model), similar to ActiveRecord, was shown with a lot of interest by those attending. I’m still waiting on it. The lesson is to not depend on vaporware!

So what are your thoughts on R2.1 and the Short-term Roadmap?

Xojo 2017 Release 2

Last week Xojo 2017 Release 2 hit the download servers. This release has the usual mix of new, changes, and bug fixes. At first blush it doesn’t seem like there is a lot to mention but there is, but I’ll get to that in a minute.

Before we get into the highlights it’s worth mentioning, again, that R2 does not have 64-bit debugging for Windows. As Xojo mentioned in their blog post (http://blog.xojo.com/2017/07/26/the-best-laid-plans-64-windows-debugging/) the LLVM compiler and toolset just wasn’t ready to be included in R2.

Despite the lack of a 64-bit debugger for Windows a number of things were corrected in 64-bit Windows builds. Icons are now applied correctly and they also show the correct version information. The 64-bit MS SQL Server database plugin now works when compiled on the Mac. Game Input Manager also works in 64-bit now. Images assigned to an ImageWell are now drawn properly.

Also related to 64-bit builds, the Split and Join functions for Unicode strings is much faster and Replace and ReplaceAll behaves like the 32-bit versions. Exceptions no longer leak memory. Virtual Volumes now work. Copying a picture to the clipboard now works. XojoScript is now available in 64-bit builds.

Linux GTK3. See Xojo blog post (http://blog.xojo.com/2017/08/15/goodbye-gtk-2-hello-gtk-3/) detailing some of the changes. The switch to GTK3 was necessary for HiDPI support and now scales automatically on integral scale factors (i.e. 1x, 2x, 3x, etc). This also lets child controls clip properly on parent controls whereas they did not always clip properly in prior versions.

Be aware, though, that this switch may affect how your controls draw. While it’s always been true that default control sizes are bigger in Linux you could sometimes cheat and use the open events (or subclass the controls) and make them slightly larger in Linux and perhaps make the system font a little smaller and things would look good enough to not require a bigger UI change. With this switch to GTK3, however, it seems like some controls, PopupMenu and Pushbutton come readily to mind, in that their caption location is definitely lower than the prior version thus making them look odd without more work. For me, what worked in R1.1 just doesn’t look good in R2.

This change begs the question that if we could make a Xojo theme for Linux that would make control heights smaller, text sizes smaller, and change the caption locations to make this a non-issue. Perhaps someone with more knowledge about Linux themes could answer that.

A few other things that might ruin your day in Linux is that not all Linux distributions now allow you to remove the border of TextFields. It wouldn’t surprise me if additional issues are found in GTK3 as time goes on.

iOS has a couple of important changes. The first is that the AutoLayout Priority property in prior versions was calculated on its own. In R2 new constraints get the ‘Required’ priority. Any existing projects should get thoroughly tested on multiple sized devices to make sure nothing needs to be fixed. In our own testing we had to simply change the priority to Required to fix any issues.

Another iOS change that may affect you is that setting the CopyFileStep to the “Frameworks” destination now properly creates the Frameworks folder inside the iOS package and puts the files there. Before you had to create a manual directory for it to work properly.

Another nice fix is that a numeric suffix is no longer added to copied iOS controls unless they need it. This was an annoying bug. Not hard to fix but annoying nonetheless.

The web framework received some attention in this release as well. The WebPage width and height properties are now correctly updated before the Shown event is fired. A number of WebMapViewer errors were fixed including an annoying JavaScript error on the first refresh and where it would fail if there was more than one instance used in the app at a time.

The Session timeout now takes touch events into account when figuring out the last interaction with the app. In addition to that, web apps now try to reconnect if they’ve lost connection to the web app and will continue to do so for three minutes or until the user navigates away from the disconnect screen.

The Listbox control received some updates. For Linux, HelpTags are now positioned properly and in Windows they disappear properly when the mouse leaves the control Also in Windows the endcap is drawn correctly and headers no longer flicker when hovered over by the mouse or when clicked on.

A regression was reported for R2 that affects dragging items to the Listbox. In Windows the X & Y coordinates are incorrect. This was reported in Feedback 49190.

New Drag events were added to the Listbox. Except for a jumbled paragraph in the release notes I’m not sure anyone would notice. I would spend more time talking about it but as far as I can tell these are not documented in the Language Reference, either local or online and there is no example. I find it inexcusable to have a major change to such an important control not be documented. This seems like it should automatically make it into the documentation. Do better Xojo!

The IDE received a bunch of bug fixes and changes. New items in the Menu Editor no longer ‘fly in’ and arrow keys work now. Long error messages are wrapped and row heights adjusted in the error reporter are adjusted as needed (as a side note does this forebode variable height list boxes?) Recent Items in the Project Chooser now show size, date created, and date modified when possible. Pressing the Escape key now acts as a “Revert Now” to changes.

It also appears that a regression bug was introduced in Raspberry Pi. Button.Action events don’t fire if using a touchscreen. They appear to work properly when using a mouse. Feedback 49221.

As always, look through the release notes to see what else has changed. It’s also a good idea to test your applications thoroughly when upgrading to a new version.

Xojo 2017 Release 2 was chock full of new things and changes. I hope a dot release is issued to fix some of the bigger regressions. Up next is 64-bit debugging and remote debugging, the new plugin format, interops, and Android. Think they can get it all done in 2017?

Sorry for the delay in getting this out. Those pesky clients sometimes want on-site help and the last thing I feel like doing is writing after a long day of coding.

 

Windows Printing Broken in Xojo R4

We’ve done a lot more testing with Shorts and R4.1 this week.  Wow.  Where to begin.  I guess the first thing to say is if you need to print in Windows stick with Xojo Release 3 for now.  R4, with its switch to Direct2D has completely messed up printing.

Using Shorts, and Xojo R3 this is what a normal print looks like.  (Forget about the colors and stuff, I’m testing things out and the ugly colored blocks help).  Looks like it should:

Exact same code in 2016 R4.1 and this is what it looks like.  Note:  the picture makes it worse than it is, it’s not slanted like that on the page, my camera angle is just weird.  But, you can clearly see that while the lines and rectangles printed properly, there’s no text!

It’s obvious that the Direct2D from GDI+ in R4 were not properly tested.  Part of that is on us, the beta test community, but it seems, to me at least, that Xojo didn’t do enough vetting themselves.

The good news is that the Shorts display works fine as well the output to PDF.  So if you don’t actually print directly from your Shorts application you’ll be okay.

I expect better of Xojo.

The Xojo Community is Awesome

Have I told you how much I love the Xojo community?  I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more.  I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product.  It’s a big deal.  Really!

If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey.  Programming is hard.  Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard.  Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.

Even Xojo pros, such as myself, have need of help.  Xojo covers Mac, Windows, Linux desktop, console, and web apps.  It does iOS apps for iPhone and iPad.  It now does Raspberry Pi for heavens sake!  It works with dozens of different databases.  There is simply no way any one person is going to know everything there is to know about Xojo.  It just can’t happen.  So yes, I go to the forums, all the time, and ask for help.

Just the other day I asked for some help with WooCommerce.  Not Xojo related, really, but certainly related to a project we’re working on for a client.  Within a few hours I had half a dozen developers private message me saying they might be able to help.  Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.

I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years.  I think I’d be hard pressed to find such a friendly community.  I call many on the forums my friends even though I’ve never physically met them.  The few that I’ve met in person have lived up to their forum reputations and are really friends for life.

So maybe this is my belated Thanksgiving post.  I am thankful that so many years ago I jumped both feet first into the tool.  I asked questions – many of the silly and redundant.  I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.

So if you are in need of a cross-platform development tool I highly recommend Xojo.  It ain’t perfect but no development tool is.  If you jump in I think you’ll love the community.  I know I do.

What say you fellow Xojo developers?

Xojo Windows Application Runtime Requirements

One of the strengths of Xojo is that it creates a no requirements executable package.  For Mac OS X it puts all required libraries and resources in the application bundle and for Windows and Linux it puts all the necessary files into the Libs and Resources folders.  This makes installing your apps on Windows and Linux pretty easy because you did not need an installer (however it’s highly recommended you use installers!).

Screen Shot 2016-04-20 at 2.58.37 PMXojo 2016 Release 1, however, has a new requirement that is biting some users fairly hard.  Some Windows 7 and 8 users get an error staying that it can’t start because it’s missing the api-ms-win-crt-runtime-l1-1-0.dll.  This error is because Xojo Windows framework was updated to use the latest Microsoft tools which means the “Universal C Runtime”.

This new runtime is shipped with Windows 10 and should be part of a fully updated Windows 7 and Windows 8 installation and because of this Xojo is not distributing the DLL when they build an application.  The past few months have shown us that many people do not automatically update their systems.  It’s pretty easy to replicate this behavior in a VM environment.  Simply do the base install of Windows 7 or 8 (doesn’t matter if it’s 32 bit or 64 bit) and without doing the hundreds of updates required to bring that version of Windows up to date, run a Xojo application.

There are three solutions to this problem.  First, have the user do all of the available Windows Updates which should install the runtime.  The second, is to have the user download the runtime installer from Microsoft.  The third option, is to add it to your installer.

Screen Shot 2016-04-20 at 2.59.02 PM

We use InnoSetup for creating our Windows installers.  Xojo has conveniently added the redistributable to the Xojo download package so we can use it.  Look in the Extras/Windows Runtime/Installers/ directory to find these installers.  Adding this into your installer is relatively painless.

In the [Files] section of your Innosetup script, add the following line:

Source: “VC_redist.x86.exe”; DestDir: {tmp}

Then, in the [Run] section, add this line to have it installed automatically:

Filename: {tmp}\VC_redist.x86.exe; Parameters: “/install /quiet /norestart”; StatusMsg: “Installing 32-bit runtime…”; Flags: waituntilterminated

This is a no fuss way to add it to your installer.  It only adds about 14 MB to your installer.  Most users will never see it because they’re up to date.

I highly recommend that you peruse the PDF provided by Xojo on this topic at Documentation/WindowsUniversalRuntime.pdf.

In our testing installing the new runtime has not caused any issues.  The clients that have had this added for them have reported no issues either so I think it’s pretty safe.  Some Xojo forum users, however, have reported that their Windows installation will hang when trying to install the Runtime.  Have you experienced any issues with the runtime?

Xojo Desktop vs Xojo Web App Development

The question comes up every now and then on what’s the best target to develop for:  desktop or web.  The answer is sometimes pretty straightforward but, in reality, the answer should be “it depends.”  You see, each target has some very good strengths and also some bad weaknesses that you need to evaluate before you start coding.  Let’s go over some of those issues.  Let’s start with desktop apps.

Xojo has been making desktop apps for it’s entire history.  Thus it is very stable and mature and there are a lot more 3rd party libraries and plugins available.  You get most, if not all, of the goodies that come along with the desktop environment and this can mean your desktop apps can have most of the buzzers and bells that modern users demand.

With desktop apps, if you need 10 more copies, it’s as simple as installing them on new machines.  These days there’s not a lot of issues deploying to Mac OS X and Windows and most versions of Linux, but still, you need to test on all supported platforms.

The major downside to desktop apps is deployment.  Each user has a copy of the software and depending on your needs/requirements you might need to ensure that everyone be on the same version.  Example:  You’ve created a desktop app for a veterinary clinic that handles everything from pet checkin to billing.  All of them connect to the same database so when you introduce a schema change in the database you need all the clients to use the newest version.    For a small organization this might not be so bad but scale that up to a corporation with several hundred copies of your software.  A good organization might have a good IT department and can deploy your software to everyone at once, but my experience says that most organizations don’t handle this well.  So your software has to be programmed to be cognizant of database versions and check at startup and complain if it’s not what it’s expecting.  From experience it’s a pain to deal with.

Desktop apps that are part of an n-tier system also need to be programmed differently.  You can program each client with all the logic it needs, but then you have to worry about record locking issues (i.e. who wins if two users are editing the same record at the same time).  You also have deployment issues, again, since you’re back to the issue of updating every client every time there’s a little change in logic.  The better solution is to have a middleware application that handles the business logic and is the go-between between the client apps and the server.  The middleware app does all of the business logic and handles the transactions between the database and the client apps.  It’s a fair bit of work and is not what I would consider a simple undertaking.  But at least you generally only have to update the middleware app most of the time and the clients can stay the same.

Web apps, on the other hand, have several advantages over desktop apps.  First, they are n-tier by design.  Each client has its own set of logic via Xojo WebSessions even though there is only one application running.  The user runs in a browser and everything is processed on the server.    So when you need to update your web app you shutdown the old one, replace the executable and the next time someone hits the URL the newer version is there and running.  Having only one instance to update is really nice (and quick).  Web apps eliminate many deployment challenges.

Web apps aren’t perfect though.  Since they are generally exposed to more random user interaction via the web you spend way more time dealing with security and making sure nefarious users don’t get into your system or abuse it.  All of your database operations should use PreparedStatements to make sure SQL injection attacks cannot happen.

Web apps run in a browser.  That’s both good and bad.  Users can access your app as long as they have internet access.  In some areas this is no big deal and for others it’s a huge deal.  Browsers also have a lot of built-in security to keep bad things from happening on your computer.  This security also limits what your browser can do in terms of file handling local.  Xojo does not currently support drag and drop operations with the browser.

Xojo web apps are also not as stable and mature as the desktop side simply because it’s younger.  That’s not the same as unsafe but it does mean there are not as many 3rd party options for Xojo web apps.  Some controls, in particular the listbox, are vastly inferior to their desktop counterparts in terms of capabilities and may not be good enough for your needs.  Web Containers go a long way towards solving this issue but it’s not ideal.

Not all web browsers are created equal.  Some perform better than others and all of them have gone through tremendous growth in the past ten years as the internet has become ubiquitous.  This means there are a lot of different browsers, and versions of those browsers, being used by the general public.  Testing the various browser type and version combinations is critical and despite all the efforts of Xojo to get it all right, the speed of new browser releases does mean issues pop up now and then.  Mobile browsers have their own set of issues that you might need to take into account as well.

Desktop apps have a huge advantage in that they don’t have to convert text to UI like web apps do.  For example loading 1,000 rows in a desktop listbox, while slow is blazingly fast compared to doing the same thing in a web app.  1,000 row list boxes in web apps are SLOW simply because the server has to create all that html data, send it through the internet to the browser, and then the browser has to reassemble it for the user to see.  To get around this most websites do data paging where they only show you 25 to 50 records at time.  Again, not hard to do but one more thing to develop.  Also keep in mind that mobile browsers try really hard to minimize data connections over cell connections so what seems fast on your desktop might be incredibly slow on a mobile phone.

Perhaps the biggest issue with web apps (not just those made with Xojo) is scaling.  Your app will react differently when accessed by 1000 simultaneous users than when it has 10.  The way around this is to do load sharing and balancing using NgInx and works well on Apache web servers.  Finding a good web server to host your web app can be challenging too.  Until Xojo releases their 64 bit support for web apps it will be increasingly difficult to find and install 32 bit compatibility libraries that work with Xojo web apps.

As you can see, there’s is no right answer.  Both desktop apps and web apps have their place in the world since they each have strengths and weaknesses.  Before you start development work you need to think through the implications of doing each.

Happy coding!  Was there anything I forgot to mention in the debate of desktop vs web apps?

BKS Spell Checker 1.0.2

picBKS_SpellCheckerWe released a new version of our Mac/Windows spell checker plugin today.  Version 1.0.2 works better with foreign language Hunspell dictionaries that are in different encodings.

The Spell Checker plugin has two different spell checking modes.  In the first mode it  works with the native spelling dictionaries on each platform.  On all versions of Mac OS X (that Xojo supports) and Windows 8 and above it uses the built-in spell checker dictionaries.  If you can’t, or don’t want to, use the native dictionaries you can use the Hunspell dictionaries.  There are hundreds of Hunspell dictionaries available for use in a variety of languages and speciality industries.

There is no Linux version at this point due to lack of interest.

More information, including downloadable demo, pricing, and usage is available at http://www.bkeeney.com/allproducts/bks-spell-checker-plugin-for-xojo/

Offline Xojo Training with Xojo Trainer

BKeeney Software announces offline Xojo Training Video application.

Xojo developers have had the ability to stream many hours of video from our Xojo Training web app at http://xojo.bkeeney.com/XojoTraining/ for years.  Thousands of Xojo and Real Studio developers have streamed well over 10,000 hours of training video from BKeeney Software.

Now, for the first time, Xojo developers can purchase the videos and watch them on their own computer without an internet connection and with no expiration date. Xojo Trainer is available for Mac OS X and Windows and is shipped on a 32 GB flash drive. The drive comes preloaded with all of the videos and Xojo project files.Xojo Trainer

Xojo Trainer allows users to select training videos by section (matching the online version) and to search videos by keyword.  Videos can be resized to practically any size.

Xojo Trainer comes with two complete desktop projects and one complete web app project.  The projects all start from nothing and Bob shows you how to test and debug the applications.  Of course the complete projects are available for you to peruse and the source code is there for you to use in your own projects!

Pricing and additional information can be found at http://www.bkeeney.com/allproducts/xojo-trainer/

Debugging Your Xojo Applications

Your customers and clients expect your Xojo applications to be as bug free as possible.  What mechanisms do you have in place to handle an error and report it?  Bugs occur – that’s a fact of life – and even the best error handling in the world can’t prevent bugs from occurring.

Thoroughly testing your application is your first and best line of defense.  However, it’s very time consuming and without good testing procedures it may even be a waste of time.  I would also add the it’s very hard for the developer to be a good tester of their own code.  You programmed it to do a certain task in a certain way.  Someone else will have a different set of expectations.

Regression testing is the only way to really make sure that changes in one part of your code doesn’t change other parts of your application (or a new version of Xojo doesn’t affect you either!).  An excellent way to do regression testing on your software is to use the open source unit testing module called XojoUnit (it’s now part of Xojo).  It allows you to test your code with known inputs and test them against the actual output.

A common question from the forums is that people get an error message saying, “The application has encountered an error and must now shutdown,” and they have no idea what the error is or where the error happened.  They need to learn as much as they can about the Exception class and in particular the Stack property.  The stack was introduced way back in 2006 and is a string array that contains the methods that have run from the entry point into your code until where the exception occurred.  Be aware that the Include Function Names property has to be true in your application for the stack to be human readable.

Use the UnhandledException event in the application class to capture any errors that weren’t handled elsewhere.  The exception stack allows you to determine where the error occurred and from there it’s a simple matter to send an email, post to a web form or write the error out to a log file that includes important details such as platform, operating system version and the version of your application.

Some applications will require files be in a specific location and when debugging your application those files might not be in the proper (final) location.  Use the DebugBuild constant along with conditional compilation, #If,  to handle things differently at debug time and runtime.  For debugging purposes you can have the required files in the local project directory for convenience sake.  A feature added in 2007 allows you to place your debug build in a particular location which eliminates the need to have non-project files in your project directory.

Cross-platform applications require additional handling but now that Xojo with (or without) a desktop license can do remote debugging and it’s very easy to do.  I run the Xojo IDE on Mac OS X on an iMac and use VMWare running various versions of Windows and Linux so I can debug my applications in those environments.  The remote debugger works exactly like the regular debugger except that the debug application is running in another environment.  It’s a little slower to initiate since the app has to be transferred to the other environment but otherwise it’s the same process.

I highly recommend testing early and often on the other platforms you’re developing for.  Don’t wait until the end to do extensive testing.  While Xojo does a great job on cross-platform applications there ARE platform differences you need to be aware of.

New developers coming from Visual Basic 6 are often irritated by the perceived lack of database error in Xojo.  An incorrect SQL statement when opening a recordset results in nil recordset objects instead of a throwing a runtime error.  The unexpected nil recordset then causes NilObjectException errors.  You must get in the habit of checking your database object for errors after every database operation.  Once you catch the error you can at least be more graceful on how to recover from it.

That’s a lot of information so do your research.  Debugging your application isn’t as hard as you think.

What things do you do to make your life easier hunting down or preventing bugs?

Classic Visual Basic Is Truly Dead

Developers love Visual Basic.  The site http://www.classicvb.org/petition/ has received well over 14,000 signatures since its inception in 2005.  In the user forums for Microsoft Visual Studio there is a place where developers can make suggestions.  This one http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3440221-bring-back-classic-visual-basic-an-improved-versi wants to bring back class Visual Basic.  Since December 2012 it had received over 7,400 votes.  Microsoft essentially told VB6 developers to kiss off this week.

The only bit of good news, in my opinion, for VB6 developers was that the VB6 runtime will continue to be supported through 2024.  So, VB6 users, you’ve got 10 years to figure out what’s next.

The VB6 runtime it is still a component of the Windows operating system and is a component shipped in Windows 8.1. It will be supported at least through 2024.

The 1100 (and growing) comments to this post are pretty much what you’d expect.  There are a lot of frustrated VB6 developers that feel Microsoft has abandoned them, at best, and, at worst, actively screwing over one of the most vibrant developer communities on the planet.

Many VB6 developers feel that .NET is inferior to VB6 but yet Microsoft is confident that VB6 developers will somehow migrate to .NET.  I just don’t see this happening.  Oh, I’m sure some will bite the bullet and learn .NET but the prospect of learning a new language and rewriting their apps does not make many happy.  VB6 was effectively killed 10 years ago and yet there are still lots of VB6 developers out there.

Many will be looking at alternatives because Microsoft is not the 95% market share behemoth it once was and VB6 was, after all, Windows only.  I you have to go to the trouble to learn a new language and rewrite all of your apps why not look at something that can work on Windows and Mac and possibly Linux as well?

I spent many years working in VB6.  I liked the language, I liked the IDE.  It had some awful quirks that drove us nuts but they were well documented quirks and were relatively easy to work around.  When I first encountered Xojo (then REALbasic) I felt like I found VB’s kissing cousin.  The IDE’s were similar, the language was similar and it was relatively easy to convert code and community was outstanding.

After twelve years of using Xojo I can say it’s superior in some ways.  First, it’s kept up to date and gets roughly 4 updates a year.  This is both a good and bad thing.  Good because when Apple (and to a lesser extant Microsoft and the Linux Distro’s) change things you’ll know that it’s just a matter of a few months, usually, before a new version of Xojo is released.  Unfortunately this makes Xojo a moving target which is part of the reason why there aren’t any books on Xojo.  It gets written and by the time it’s published it’s already out of date.

There are a number of things that VB6 was just not good at.  Subclassing controls was impossible and we never got threads to work right without causing serious crashing issues (I believe I recently saw a post where they got threading working properly in VB6).  But that still leaves all the other things that were feeling their age in VB6.

I’m biased for Xojo.  I think it’s worth taking a look at if you’re a VB6 developer.  Is Xojo perfect?  Hell no.  The developer community is much smaller and there aren’t nearly as many control options.  And some of the controls, the grid in particular, are inferior to what many are currently using in VB6.

Xojo is, in many respects, a compromise.  All of those fancy grids you see in Windows apps usually don’t exist on Mac OS X and Linux.  Mac OS X apps are generally built with a different UI mindset so the the grids aren’t nearly as busy.  If you planned on doing the same thing in Xojo you will be in for a rude awakening.  Not that you can’t make a complicated grid, but you’ll spend a lot of time getting it to work and even then I’m not sure you’ll be happy with the results.  Plus, Mac users are a finicky lot and if it looks like a Windows port they might reject your app.  But then again, does the utility you wrote for your company really need a fancy UI?

Xojo is very cool sometimes.  The ability to remote debug applications from my Mac to a Windows or Linux computer is very handy.  And the fact that a Windows machine can build for Mac OS X and Linux, for console, desktop and web apps, is also very nifty.

Take a look at Xojo (it’s free to try!).  It might be a good solution for you.  My advice is to not try to ‘convert’ your VB6 app using The Migration Assistant or any of the conversion tools available.  There are just too many language and control differences to make this feasible.  From experience, you’ll spend more time fixing code than if you had just started from scratch.

My other bit of advice is to not assume Xojo and Xojo made apps work just like VB6.  They don’t.  Take the time to read the documentation, look at the example apps, and visit the forums when you have questions (you’ll have many).  The Xojo community is very welcoming and eager to help.

Finally, I am a consultant and if you need assistance getting into Xojo we can help.  My team has rewritten dozens of commercial VB6 apps over the years.  If you’d like a quote feel free to download our VB6 analyzer tool at http://www.bkeeney.com/vb2rbconversion/.  We also have over 50 hours of Xojo and Real Studio video tutorials available to subscribers at http://xojo.bkeeney.com/XojoTraining/ where we’ve helped thousands of developers get a handle on Xojo.

If you are a VB6 developer, Xojo might be for you.  Welcome to the Xojo community!