2018 Was a Weird Year

I hope everyone’s holiday season was good.  We’re approaching the end of 2018 and I find it nice to reflect on what’s happened and what we’ve accomplished this year.

Looking Back

Let’s start off with the blog posts.  I did 41 (well now 42) blog posts in 2018.  Five were about Xojo releases.  Four were BKeeney Software product releases.  Four posts were about the Xojo Developers Conference.  The rest were a variety of Xojo related topics.

The most highly commented blog post was from June called Chasing Xojo where I lamented that Xojo, at least until that point, seemed to be a less stable when it came to Windows and Linux due to major revamping of the drawing systems on both platforms.  In Windows, Xojo doesn’t flicker as much but the struggle to get speed was a concern for all of 2018.  In Linux, the switch to GTK 3 wasn’t as smooth as we could have hoped.

The most viewed blog post was from August called Xojo 2018 Release 2 where I did my usual review of the most recent release of Xojo.  I heavily criticized Xojo for their poor documentation in that release.  I received plenty of blowback on that one.  But I think the end result is that R3 and R4 documentation was much better.

We released two new products with BKS Report Studio and BKS Tab Control.  Report Studio is our reporting utility meant for end-users for macOS and Windows and it was built using the award winning Shorts reporting classes (also a blog post).  The Tab Control is a canvas subclass that replaces, and extends, the built-in Xojo tab control in many ways and was our attempt at replaced the old CustomTabControl that many use but is unusable for HiDPI apps.

The other major release of the year was ARGen 3.0.  ARGen is our utility to create Xojo projects that creates ActiveRecord objects.  Among the many changes was the ability to generate ActiveRecord objects for iOS projects, supporting GUID primary keys, and the ability to include Audit Trail, Localization, and Database Update modules that help in many products.  We use ActiveRecord in practically every project and having the ability to generate some basic desktop and web UI is a huge time saver.

2018 sure seemed like a mixed bag for Xojo.  The Windows drawing issues took up a good chunk of the year and I think R4 was the first solid Windows release (although I still have 2 client apps that won’t remote debug in R4).  I can’t imagine the amount of effort that Xojo and the community put into getting Windows drawing fixed.

64-bit remote debugging became a reality for all targets this year.  64-bit compiling isn’t the huge gain that many in the community hoped for but then we always want more.  We just have to remember that 64-bit doesn’t necessarily mean ‘faster’.  At least the debugger works and that’s not nothing.

Dark Mode came soon after the release of Mojave.  The IDE works in Dark Mode and we were given many of the tools to implement it in our own projects.  Dark Mode only works in MacOS but some are already clamoring for it in Windows too.  It’s still to early to tell if Dark Mode is a hit on Mojave much less in xojo.

Looking Forward

What is 2019 going to bring us?  For one, we’re almost finished with a fairly significant update to Formatted Text Control and after that’s released we’ll start with an even bigger version 4 update to the venerable word processing control to bring it up to date and extend its capabilities to make it even more powerful.

We have a number of large consulting projects that have been in gestation for many months and years.  It will be nice to have a big project or two to keep us busy.

With the release of Web 2.0 I will redo all of our Xojo training videos related to web.  They’ve been outdated for a while but it’s not worth redoing the videos until Xojo releases Web 2.0.  If they release Android I’ll start on at least some intro videos for that too.  This might finally be the year that I redo the remaining Real Studio videos.  No doubt I’ll redo them just before a major IDE change.  🙂

What do I expect from Xojo?  That’s a tough question to answer since they’re so damn secretive now.  I expect Web 2.0 to show up in time for XDC (so maybe release 2?).  I think it will be pretty solid in the first release but it wouldn’t expect it to be good until the following release.

I also think that at XDC we’ll get an alpha of InterOps but not anything other than another dog and pony show for Android.  Targeting another platform is long and tedious process and involves some serious IDE work.  How much of the iOS editors can they use?  I can only guess but at first blush I say not much.

Some of Android’s success may hinge on getting iOS to use the global framework and away from the Xojo Framework.  Nothing like rewriting an entire framework while keeping backwards compatibility.  The more I think about it the more I think the iOS rework is put on hold until Android is released.  

Which leads to API 2.0 in general.  We’ve already seen some of the first new controls to use API 2.0.  URLConnection was introduced in 2018 R4 with mixed success.  I would expect more API 2.0 controls to show up.

So what do you think?  Was 2018 a successful year for Xojo?  What do you see happening in 2019?

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?

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!

 

Protect Your Most Valuable Asset

If you own a house, most likely you have insurance in the event of a disaster.  You might even have a safe box somewhere in your house to protect your valuable objects and you might even have a safety deposit box at the local bank to protect your most valuable items.  Why do many developers not use a Source Code and Version Control System for their source code? After all, your source code is the most important business asset you have and until you hand it over to the client it’s yours to protect. Even if it’s your personal code, why not protect it?

Real Studio doesn’t make this easy, in my opinion, with their binary (rbp) file format. The binary format is very fast and very portable single file in comparison to the version control (vcp) file format that creates a text file for each object in your project. The binary format, in my opinion, gives users a false sense of security. Bugs happen and hard drives fail.

Version control systems can not read the binary format and track code changes. They check in a binary file as a whole unit regardless of how many Real Studio objects are in it. So it doesn’t matter if the code in Window1 has been changed or not because all that code gets sucked into the server.

In my ideal world I’d love to have a format that works with the source code systems but is also as easy to package up and move around as the binary format. Apple’s bundle format would be ideal but as far as I know there is nothing built-in to Microsoft or Linux distro’s that does this automagically.

Subversion servers (and their like) tracks source code changes down to the line of code. Change the capitalization on an RB keyword in Window1.open event? It’s a change that’s noted in the object file (window1) and even to the line of code. When you check in the changes to the server it knows who did it and assigns a version to it.

We’ve used a variety of systems over the years. Many years ago we used Visual Source Safe, CVS, and we currently use Subversion. There are a lot of developers that are using GitHub with a lot of success. Regardless of what you use I believe you should be using some form of source code and version control system. It’s the smart thing to do as it’s the only safe way to store your source code.

Have you every lost code because you failed to keep a copy of it, deleted it accidentally, your hard drive failed, or your computer was stolen? There’s nothing worse than knowing you had some source code that you can no longer find and use. That’s an asset that you’ve now lost – forever.

I know I’m not the only developer that’s worked on a piece of code for a few hours only to realize that it’s crap and I have to revert to the pristine version (because it’s impossible to undo all the changes you’ve just made). You can do this with the binary format if you are really, really good (or paranoid) about making copies of your project but that’s a lot of work. The source code and version control systems are designed for this!

These systems let me save incremental changes, create snapshot copies of the entire project and even compare files across versions so that I can see exactly what’s changed. With multiple developers on a project this is nice to see who changed what and when. When the developer commits a change we all add a note on what we were working on. This is important for us on large projects.

These systems just aren’t for teams, though. Tracking your individual changes is important because sometimes you’ll just be wrong when you change some code and you’ll have to check out an earlier version. These features are very important on projects and teams of any type of size.

Subversion and GitHub can be done on a local computer (not necessarily a server) and from what I know they are not exceptionally hard to install and setup. We chose a commercial host for a variety of reasons. First, I don’t want to purchase and maintain a server with all of the security nightmares that can come with it – the commercial host keeps up with security issues and we all connect via SSL so we know our code is as safe as our passwords allow.

While we do backups of our important files the commercial host is an offsite backup for us.  They do offsite backups of their servers. I know that if my office were to burn down, get hit by a tornado or flood, I would be down as long as it would for me to get a new computer from the nearest Apple retailer and hook up to our Subversion server. That’s a huge peace of mind for me.

We use a Subversion client that is cross-platform simply to make it easier for training purposes. We use SmartSVN which has versions on Mac OS X, Windows, and Linux. While we spend 99% of our time developing our Real Studio applications on the Mac we occasionally need to compile or debug natively in Windows or Linux. The standard UI across platforms with SmartSVN makes this easy and we do not have to copy files across development environments.

We also use a bug tracking system. Unfortunately our version control and bug tracking aren’t tied together but there are plenty of commercial hosts that have both. We tend to commit based on bug reports or, at a minimum, clusters of bug reports. Have a single bug in a class? That’s one commit with the bug ID noted in the commit report. Have a couple in a set of related classes? That’s one commit with all the bug ID’s noted in the commit. At a glance I can tell what bugs were fixed with each commit.

So regardless of the reasons that appeal to you the most, you should be using some form of source and version control system. Protecting your source code assets should be a part of your practice. If you aren’t protecting your most valuable assets your playing with fire. A disaster on your development computer could put you out of business. Protect your source code and yourself.

What about you?  What do you do to protect your source code?

Has Microsoft Already Lost?

I say this with no malice when I say that Real Studio is a fairly small player (development tools-wise) when compared to Microsoft and Apple.  Those two behemoths have much bigger pockets and drive the development environments on their respective platforms.  It’s also fair to say that each has little interest in supporting the other platform.

Real Studio is a good cross-platform development environment that lets a skilled developer create nice Macintosh OS X and Windows applications using one code base.  Most things ‘just work’ and the language makes it easy to take into account the occasional (and sometimes not occasional) platform specific API calls and differences.  Sometimes the differences are a royal pain but rarely have we been stymied in a project as there always seems to be another option available.  And sometimes the trick is know which things to avoid when working on cross-platform apps.

When I started doing Real Studio consulting a decade ago most of the clients who found us were hard-core Apple users.  They had to satisfy their corporate bosses by developing mainly for Windows and if they could get a Mac OS X version as a side benefit that was great.  For the past couple of years it seemed that the clients who contacted us were the corporate IT folks that had legacy Visual Basic projects and didn’t want to convert to .NET (and yes, the boss wanted a Mac version too).

In the past year, however, we’ve been contacted – a lot – by clients invested in .NET and needing a Mac version.  This isn’t just for their internal business apps either – they’re talking about commercial applications.  What’s even more interesting is the number of calls we’ve fielded by existing .NET development shops needing help.

So it begs the question:  Has Microsoft lost the battle of mindshare?  Has Apple now wedged their way into consumer and corporate America to the point where not having a Mac version of your software is a detriment to marketing and sales?

Don’t get me wrong.  Microsoft isn’t going away any time soon, but I can remember a time when if you mentioned Apple (or any non-Microsoft technology for that matter) you were derided for your obvious stupidity.  I can’t tell you how many times I was laughed at for being an Apple developer.  Now, it’s hard(er) to find diehard 100% Microsoft-only IT person.

I decided to write this post after yet another phone call with a .NET developer.  They want Mac versions and they’ve already decided on Real Studio.  But, and this is always the catch, they’re good at .NET and know next to nothing about Real Studio and nothing about Mac development.

That’s where consultants like us come in as we can help bridge the gap in knowledge.  If you’re interested, we have 36 hours of training video’s (over 100 individual videos) available to subscribers at http://www.bkeeney.com/RealStudioTraining/realstudiotraining.cgi including several projects that start from scratch.  I’ve had experience Real Studio developers tell me they’ve learned a few things even by watching the 6 hours of non-subscription video.  Perhaps your .NET developers would get something out of the training?  Perhaps some one-on-one training would helpful?  Contact me – we can help.

I digress (sorry for the shameless plugs).  Have you Real Studio developers been seeing similar trends?  Does .NET seem to be losing its luster?

Increased Demand for Cross-Platform Applications

It’s been a busy couple of weeks so I haven’t been posting much.  I have a number of things going on:  New and updated products, Real Studio training, and consulting projects are eating up a lot of time.  Free time?  What’s that?

It’s always nice to be quoted in someone else’s press release.  Real Software issued a press release last Friday about an increase in leads for cross-platform projects.  I was quoted a number of times about our experience as Real Studio consultants.  This one, perhaps, is the conversation I have the most often with our VB6 conversion clients:

According to Keeney, many of his clients have made the decision that sticking with Microsoft for another 10 years is not in their best interests. It means learning a new development environment (.NET) and still not being able to support the Mac. “The only other alternative is to have separate projects — one in .NET and one in xCode, and take their chances,” Keeney added. “Most desire to have the same code base for both platforms and deal with the same developers for each one.”

Mac support is a huge reason why people are looking at Real Studio and coming to us to do the work.  It’s a good time to be a Real Studio developer in my opinion.

Despite my initial misgivings on Web Edition, I think it’s a good addition to our toolkit.  We’ve done a number of projects in Web Edition that we would have turned down a year ago for lack of experience in web technologies.  It’s nice to be able to leverage our decade of experience in Real Studio into a new area.  That’s lead to some very fun and interesting projects.

Anyway, that’s my quick thought for the day.  What’s been your experience?

Visual FoxPro to Real Studio Converter

There was a point when Visual FoxPro (VFP) was one of the best development tools out there.  Some would argue that it’s still one of the better ones.  Unfortunately, Microsoft has decided to move on and no longer update Visual FoxPro so this means that handwriting is on the wall and it’s time to find a new development tool.

CULLY Technologies has released a Visual FoxPro to Real Studio converter.  More info can be found at http://cully.biz/2012/03/05/visual-foxpro-to-real-studio-converter-0-1beta/.

This converter is open sourced so you can tweak it to suit your own preferences and fix any bugs you might find.  It converts VFP forms to Real Studio forms.  Converting the User Interface can be a huge time waster so I’m sure many will find this useful.

No converter is perfect and neither is this one.  It does not convert reports, menus and a few other objects.  It also does not convert any code.

We’ve looked at converters over the years and, honestly, I don’t think code conversion is worth the effort.  You could spend a ton of development time in coming up with a halfway decent converter only to still have to tell the end user they’ll have to go line-by-line to modify the code to suit the Real Studio frameworks.  At that point why not just rewrite from scratch to begin with?  The new to Real Studio developer will have to learn and use the framework anyway and I think giving them a crutch to help them bridge whatever language they’re coming from to Real Studio does them no favors in the short-term or long-term, in my opinion.

Kevin Cully of CULLY Technologies spoke about Migrating from Visual FoxPro to Real Studio (members only to view) at the 2011 Atlanta Summit.  It was an interesting topic as I have never done development in VFP.  I would love it if Real Software added some of the features of VFP into Real Studio.  Kevin is also speaking the 2012 Real World conference.

Conversion tools, while always flawed, are a good thing as they make some aspects of converting from one language to another easier.  This one from VFP to Real Studio should be fun to watch.

Are you a fan of Visual FoxPro?  What do you think its strengths are over Real Studio?  What about the other way around?

 

Bugs Are In The Eye of the Beholder

The other day someone on the NUG list posted a somewhat lengthy message on Web Edition bugs. They were asking “why was Web Edition so buggy after a whole year?” Here is my response (mostly the same but with some changes).

Sure, Web Edition has more than its share of bugs. Like all bugs, however, it all depends upon the beholder.  What bug causes the most pain for RS’ is the one that gets fixed first.  I’ve seen a lot of the same things the community has discovered and have just worked around them (where I can).  I was using WE in a commercial project during the first beta ( a year ago) and while we got it to work it wasn’t very good.  That one project probably generated over a hundred feedback reports.  In my opinion WE really hasn’t really been usable until 2011 R3.

Part of the problem, in my opinion, is that RS has NOT created enough Web Edition applications for themselves.  If you don’t thoroughly exercise the framework you just don’t see the things you’d see in a big, complex application (like we are creating).  There is ONE real world example of Web Edition on their website.  While I don’t know how many examples are ‘enough’, I know that one is definitely not enough.

Web Edition exposes the same problems that we all see in Cocoa, Carbon, and in the IDE on a regular basis.  Unless RS experiences the pain it won’t get fixed in a timely manner because it’s not as important to them.  The Reporting editor and generator and the database editor are but two examples of things in the IDE that RS doesn’t use in ANY of their products. It shows because there are gaping wholes in usage that make them unusable for many developers.

RS takes pride in saying they eat their own dog food because they use Real Studio to make Real Studio.  Admirable, but they tend to be on a restricted diet since they don’t eat everything on the menu.  They rarely change the menu’s for the IDE so the Menu Editor hasn’t seen many changes or enhancements.  As far as I know, they don’t use a database in the IDE so I see no reason why they’d be using the database editor on a regular basis.  They don’t do much with StyledText or Movies so its no surprise that those classes are minimalistic (at best).

Since the IDE has no need for date pickers, they have never provided one.  Likewise, the Listbox is good enough for the IDE while we’ve been asking for a more powerful grid component for years.  Full RTF support?  Forget about it because StyledText is good enough for the IDE. A better toolbar control? Well that one’s a bit of a mystery since the IDE is obviously using something different than what they provide to us.

My point is I’m not sure why anyone would be perplexed about long standing bugs.  Sure, they’re painful to you and me (and my clients), but they’re not (as) painful to RS.

Lobbying the community to get Feedback reports higher in the list is about the only way to realistically get a bug fixed. But even that is a crap shoot as there are quite a few bugs (not feature requests) very high on the list that have been there for a long time. So the only thing conclusion that I can come up with is that the bug that all the rest of us are seeing isn’t painful to RS so therefor it isn’t a priority for them.

This is my opinion as a ten year Real Studio consultant.  I know and respect most of the engineers and staff at RS and I think they do a remarkable job.  However, I think as a company they mostly ignore those like me (an Enterprise user that ponies up thousands of dollars per year) and focus, almost exclusively, on the hobbyists (that bring in a hundred dollars a year at best).  If they could make me happy(ier) the hobbyists would come along anyway (see history of Visual Basic).

Bugs happen in every software product. I remember grousing about Visual Basic bugs when I was a big VB6 user. I know that my code back then had plenty of work arounds for bugs in their API. There is no doubt that Microsoft had more developers working on the product (as a whole) than RS has working on Real Studio. There’s also no doubt that VB6 has a considerably larger user base than Real Studio. I feel that this resulted in more workarounds being posted and more alternate solutions.  The reverse is that our smaller community doesn’t have as many solutions and documented workarounds so it feels worse but I feel that it isn’t.

Anyway, that’s enough on my opinions about bugs and such.  Have a good New Year and be safe. Happy coding!

Visual Basic 6 TIOBE Index

The TIOBE index for programming languages is an interesting visual perspective on programming languages.  Take a look at the graph for the trend of Visual Basic since 2002.

Visual Basic seems to have taken a big hit at the end of 2004.  I’m not entirely sure of why this happened because .NET had been released in February of 2002 in Visual Studio.  Visual Studio 2003 was released in April of 2003 and the next update was Visual Studio 2005 which was released in November of 2005.  Vista was released in January of 2007 so I don’t believe it has anything to do with the operating system either.

Perhaps what’s interesting is that it nearly regains its former popularity in about two years.  Could this have been a reaction that people found .NET to not be as easy to use as VB6?  I know that some people were dismayed that VB.NET wasn’t much like VB6 and abandoned it – especially since Microsoft operating systems weren’t breaking their old VB6 apps.

Since the midway point of 2009 it seems like the bottom has dropped out in VB6 popularity.  Could it be because Microsoft officially ended support for VB6?  Again, speculation on my part, but that is about the time that I started seeing an influx of requests for quotes from people wanting to convert their VB6 apps to Real Studio.

Another huge drop happened in early 2011.  Was this due to the confusion of whether or not Windows 8 will support VB6 applications?  Perhaps.  I have seen another increase, in the same timeframe, of people looking to convert from Visual Basic to Real Studio.

Is Real Studio (i.e. REALbasic) the right choice for your Visual Basic 6 application?  The answer is a qualified maybe.  If you want one code base that works the same on Macintosh OS X, Windows, and Linux and perhaps a similar code base for a web app (Web Edition has separate UI classes than the desktop) then Real Studio might be a good fit.

If you’re looking at converting to Real Studio please do your homework.  Learn a little bit about the language (<shameless plug>Like my training videos<\shameless plug>) and work with it a bit.  Do NOT depend upon any VB6 to RB converters working – there are simply too many things that REALbasic is better at.  You’re better off rewriting your app to take advantage of moderns things like subclassed controls and threading rather than try to force a Real Studio app to behave like a VB6 app.

My final bit of advice is to forget about your ActiveX controls you’ve spent so much money on.  They probably won’t work and they won’t work on the Mac or Linux anyway.  Find and switch to an equivalent, if possible, but you’ll probably create some of your own subclassed controls.  In the long run you need to think in RB-speak rather than VB6-speak.

Real Studio, in the long run, is pretty inexpensive compared to Visual Studio, in my opinion.  I know people that thought of nothing of dropping over $1000 per year per developer on control suites.  Real Studio is much cheaper from that perspective since subclassing controls, canvas controls, and container controls eliminate the need for much of those expensive suites.  The drawback is that you end up doing the work yourself rather than some other developer.  And some things just can’t be done in RB that you might have come to expect in VB6 (like specialized controls in a grid cell) simply because on the Mac or Linux there is no equivalent.

If you want to convert your VB6 app to Real Studio, you can take a look at our conversion page at http://www.bkeeney.com/consulting/vb2rbconversion

Will VB6 Apps Continue to Work in Windows 8?

Will VB6 Apps Continue to Work in Windows 8?  That single question has driven more traffic to this website in the past month than nearly any other question.  I believe VB6 still has a very large user base so it’s very pertinent question for many organizations and developers.  Perhaps Real Studio is an option for them, but we’ll get to that at the end of the post.

Visual Basic 6 is 20 years old.  It’s stood the test of time and it while it’s showing its age it still functions and apps written on it still run in Vista and Windows 7.  To its credit, Microsoft has made sure that this venerable product still runs on modern computers.

But the question of Windows 8 compatibility has hit the fan, so to say, in the past month or so with Microsoft saying that apps can be written in html and javascript.  That threw many developers into a tizzy.

I don’t believe for a second that Microsoft is abandoning .NET, Win32 or COM simply because those are the foundation for nearly everything ever written at Microsoft.  It simply doesn’t make sense for Microsoft to move to another set of API’s even if you believe that Microsoft moves to a new technology every now and then to make themselves a moving target.  If anything, I believe that this might simply be a new way to develop apps but not replace anything.

While doing research for this post I ran across an unattributed quote supposedly from a person in Microsoft Support:

“We can’t make an official comment on our Windows 8 plans yet but it would be a likely outcome that VB6 applications will continue to work. “

I believe that statement but it’s not exactly a definitive statement.  The real question, I think, is how bad will it suck?  VB6 apps work in Windows 7 but without some work they look like they’re from the 90’s.  Most app developers I know don’t want their apps to look that dated.

Microsoft has stated that the Visual Basic 6 runtimes will not ship after Window 7.  This presumably means Windows 8 and beyond.  I have heard that Windows 8 will be 64 bit only and that means that the VB6 runtimes will either not work at all or will have to be run in some sort of compatibility layer.  So this means that existing apps MAY work, but only after jumping through hoops to install the runtime libraries and making sure the compatibility is set.

Let’s face it.  VB6 is an old, old development environment.  It was written in an age where computers didn’t have much memory and only one processor.  Threading isn’t impossible, but the few times I tried to get it working in a VB6 app the result was instability and crashes.  Threading is such an important thing in modern applications.

VB6 is object oriented – somewhat.  For the time it was state of the art but since subclassing controls is impossible it makes for interesting workarounds and wrappers.  Frankly it makes life more complicated than it needs to be.

Twenty years ago, VB6 was the cats-meow.  The Macintosh was around but it was considered a toy (I disagree but that’s not the argument) and few cared about it.  Microsoft was pretty much the only game in town.  Linux hadn’t been invented yet and the internet was for a few hard core geeks.

This is where Real Studio starts to look more attractive.  It works the same on Mac, Windows, and Linux.  Web Edition brings some of the same ease of developing desktop apps to the web.  In Real Studio I can subclass controls and objects (for the most part) all day long.  It’s a modern object oriented programming language.  Is it without foibles and inconsistencies?  Certainly not, but it’s way more powerful than VB6 in many ways.  Threading isn’t perfect, but it’s still light years ahead of VB6.

We’ve seen an uptick recently with people asking us to convert their VB6 application to Real Studio.  Our VB6 Analyzer utility (found at http://www.bkeeney.com/consulting/vb2rbconversion) has been downloaded a lot recently.  It allows users to scan their VB6 project and sends us a simple report detailing the number of forms, classes, libraries and OCX’s in use and lines of code and some other simple metrics.  It’s no substitute for seeing the whole project but it gives us a nice way to guestimate the costs of rewriting the app in Real Studio.

Notice that I said rewrite the application.  The only thing that Visual Basic and RealBasic have in common is that they have ‘basic’ in the name.  It’s like comparing a computer from twenty years ago to a modern computer.  Real Studio does things so much easier, better, and faster than Visual Basic that it’s really not worth trying to convert it line by line or even form by form.  Believe me we’ve tried – the end result is that you end up spending as much time fixing VB6 code that has a better equivalent in RB than it would be to just rewrite it from scratch.

Is Real Studio a suitable replacement for every app?  The answer is simple:  no.  Real Studio makes a really good cross-platform app, but that doesn’t always mean it will have all of the buzzers and bells available in development environments meant for each platform (grids in Windows come come to mind).

We are Real Studio consultants.  That’s what we do and we’ve been doing it for ten years.  Most of us spent a fair amount of time in Visual Basic before moving to Real Studio.  If you decide to do the transition yourself you will hate it at first because Real Studio is different than VB.  We all went through it and for a while you want Real Studio to be just like Visual Basic – trust me it’s not – and after you stop trying make Real Studio function like VB6 you’ll start to like it and get it.  Transitions are never easy.  For training videos, we have over 30 hours available at http://www.bkeeney.com/realbasic-training-section plus you could always hire us to come on site for training.

If you have VB6 project you want to transition please drop us a line and we can talk.  If you want to get multiple Real Studio developers looking at your project, make a post at http://www.realsoftware.com/support/consultants.php which gets sent out to the Real Studio developers network.