Don’t Convert Your App to Xojo

New Xojo developers are often sorely disappointed with Xojo when first coming to the language.  Why?  The complaints are varied but they usually say things like “<insert part here> doesn’t work right.  In <insert old dev environment> it worked this way.”  I’ve heard this complaint so often that I ignore it.  Don’t convert your app to Xojo, rewrite it in Xojo.

Xojo attracts a lot of VB6 developers.  The IDE’s look a lot alike and the languages at first glance are pretty similar.  The problem is that Xojo isn’t VB6 and most of the things that take huge workarounds in VB6 are almost laughably simple in Xojo.

The first thing many people do is look at the VB Migration Assistant from Xojo.  It isn’t a perfect tool and does not convert any code for you.  Not converting code is actually a good thing because no conversion tool is perfect.  It’s very hard to convert the intent of the original programmer.  Sure, there are rules you could employ to convert code but in my experience the converters create more work for you in the long run.  It’s much easier for a human to look at the VB6 code, figure out the Xojo equivalent and use the Xojo-way of doing things.

At best, the VB Migration Assistant will convert your UI for you.  But given the huge diversity of 3rd party controls for VB6 you will have to work at converting them to standard Xojo controls.  And again, because VB6 doesn’t do some things well, like control subclassing, you might actually be better off rewriting the user interface from scratch in Xojo anyway.

In both cases I said rewriting Xojo.  Sorry.  There is no easy solution to get your VB6 application to work in Xojo.  While the two development tools use a BASIC language that’s about as close as they get.  VB6 is an ancient language by modern standards.  Xojo is updated 4 to 5 times a year and VB6 hasn’t been updated in a long, long time.  Control subclassing in VB6 is impossible and threads are very hard and because of these two things most VB6 apps tend to have huge workarounds to fulfill those needs.

In Xojo these issues just aren’t there.  Subclass controls to your hearts content.  Need a thread or two or a dozen?  No problem it’s a simple to use Xojo class.  Need a 64 bit version?  Want it to run on Mac OS X, Windows, Linux, and Raspberry Pi?  Xojo can do all that easily.  For VB6 that impossible.

If you are contemplating switching to Xojo do NOT look at ‘converting’ your application.  Think about rewriting it.  This means doing some legwork upfront to learn the Xojo particulars and only then writing code.

We’ve converted dozens of VB6 apps over the past fifteen years as Xojo consultants.  We’ve helped teach thousands of developers on how to use Xojo with our Xojo training videos and one-on-one training.  In the long run you’ll be much better off learning the Xojo way of doing things.  Perhaps then you’ll appreciate that Xojo did it better.

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 http://www.bkeeney.com/vb2rbconversion/

Happy coding!

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!

 

Visual Basic 6 on Windows 8.1

Not a month goes by where we don’t get a prospective client asking about the possibility of converting their old (but working) VB6 application to Xojo.  They always tell me that their project is working great in Windows 7 and Windows 8.  Then comes the but.  But, they feel that they’re living on borrowed time and it’s only a question on WHEN Microsoft pulls the plug on compatibility not a matter of IF.

Let’s face it.  VB6 Service Pack 6 was released in 1998 and official support ended in 2008.  I think it’s a testament to its power and popularity that developers are still using it five years after support was ended.  It may also be an indictment of how many felt abandoned by Microsoft in the move to .NET.

So the questions I end up answering for many are these:

Can we convert their VB6 application to Xojo?

The answer is generally yes.  I’ve come across few projects that can’t (or shouldn’t) be done in Xojo.  There are some caveats, though, because Xojo is a cross-platform programming tool.

If you’re looking for fancy grids that you rely upon in Windows you’ll be disappointed.  As a cross-platform tool some controls are the least common denominator simply because Mac OS X doesn’t support or encourage the same types of grid components.  Apple encourages simplicity which forces different design considerations.  Linux has differences too that force compromises.

Reporting isn’t nearly as robust in Xojo as in VB6 either.  While it’s true that Xojo has built-in reporting components most developers I know find it too weak for anything beyond simple reports.  There are a number of third party reporting tools (including BKeeney Shorts, our particular solution) but none of them are as easy, mature, and integrated as Crystal Reports.

Can we easily convert their project to Xojo?

This answer is a definite no.  I don’t care what anyone says, running your VB6 project through any of the available converters will not result in good Xojo code.  From experience, you’ll end up spending more time fixing the things that it didn’t convert properly than if you had just started from scratch.  In our opinion it’s much easier to rewrite the application in Xojo rather than convert it.

That’s not saying you can’t reuse major portions of the VB6 code in Xojo but, as a developer, I want to analyze it and choose what I want to port rather than having it bring over everything.  There are a couple of reasons for this.

  • This first is that Xojo is really good at subclassing controls.  VB6 was horrible at it and many developers have extensive classes and modules to work around this fact.  Little to none of the code that’s in those classes and modules is necessary in Xojo.
  • The second is that Xojo is pretty good at threading.  Much of the app.doevents code you’ve had to add in your VB6 project because of tight loops to avoid the UI from freezing you’ll do away with and put into a thread in Xojo.  There are some caveats with threads in Xojo but generally it’s a better way to deal with time consuming operations that might otherwise freeze the user interface.
  • The third is that the VB6 best way to do something may not be the best way to do it in Xojo.  A number of years ago we converted a simulation application from VB6 to Xojo (then called Real Studio).  The project used an insane number of control arrays  with various levels of overlapping controls.  The logic was very convoluted.  Rather than try to duplicate the exact same functionality in the same way in Xojo, we were able to greatly simplify the logic and put everything in simple classes.  The ‘unit’ in the simulation handled all of its own actions and generated events for the UI to respond to.  The UI simply passed the user action into the appropriate class instance.  Everything was encapsulated in the classes and in the long run they could have used the same UI front end for any number of different simulations.  It wasn’t the VB6 way and it took some convincing that it was a better Xojo way.  In the end they were happy with the results with a solution that ran on Windows and Macintosh (and Linux if they had requested it).

Windows 8.1

So why bring all this up?  For some reason a lot of people have hit a previous blog while searching about Windows 8 and VB6 during the past month.  I did some checking and while Microsoft has said Windows 8 would still have VB6 compatibility built-in, some developers have had issues in Windows 8.1  The workarounds seem to be fairly simple, but I think most people still using VB6 are wondering if this will be the last version of Windows that will still have that.  VB6 does work in Windows 8.1 but will this be the last version?  Only Microsoft can answer that but given their stated intentions of doing annual updates like Apple it seems likely at some point they’ll jettison some backwards compatibility.

Also a consideration for many of them is Mac compatibility and to a lesser extent Linux.  Ten years ago the Mac version was an afterthought for many of our clients.  Now, not so much, in that they need a Mac version to satisfy their customers or personnel.  The past couple of desktop projects have actually been Mac first and then Windows.  How times change.

Finding Xojo Developers

I’ll put a plug in for ourselves https://www.bkeeney.com/bkeeneyconsulting/.  We’ve converted dozens of VB6 projects to Xojo.  Contact us if you’d like a quote.  You can even put your application through our VB6 Analyzer (https://www.bkeeney.com/vb2rbconversion/) so we can get some metrics about what all is in your VB6 project.  The beauty of the analyzer is that we never have to see your project to give you a rough estimate of the cost to convert.

You can also request the Xojo Developers Network to get in touch with you.  Simply fill out the request at http://xojo.com/support/consultants.php and Xojo developers will contact you if they’re interested in your project.

Support for VB6 ended a long time ago but based on the number of contacts I get it is certainly not dead yet.

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?

Database Programmers: Do Yourself a Favor

[NOTE: ] As Jeremy points out in the notes below, this example really is BAD for web apps because of SQL Injection attacks. You should start looking at PreparedStatements if you have not done so already.

I get to see a lot of code from other developers and it seems that in the past couple of months I’ve seen a LOT of code.  Real Studio is a good database programming environment (we can argue all day long about binding but that’s another post) and is arguably very easy to learn and use.

But I can say, without any doubt, that between the code I’ve seen and the questions I’ve answered on the Real Software forums regarding database issues, people just don’t get how to use them.  In practically all cases the Real Studio developer could have easily solved their issue if they had just checked the database error bit and the error message.

We see a lot of code that does something like this:

dim s as string = "Select * from MyTable where fldLastName = '" + SomeCritera + "' order by fldLastName"

dim rs as recordset = db.sqlselect(s)

while rs.eof = false
   
   //do something with the data
   
   rs.movenext
   
wend

Pretty straightforward stuff except sometimes the recordset is nil and causes a Nil Object Exception.  Nil Object Exceptions are ‘bad’, right?  So what do people do?  Well, they tend to do something like this:

dim s as string = "Select * from MyTable where fldLastName = '" + SomeCritera + "' order by fldLastName"

dim rs as recordset = db.sqlselect(s)

if rs <> nil and rs.recordcount > 0 then
   
   while rs.eof = false
      
      //do something with the data
      
      rs.movenext
      
   wend
   
end


Slightly better as it won’t throw an error now but the problem still persists because we don’t know WHY the recordset was nil.  A better way to do this is to check for the error because we know, from experience, that the ONLY time a nil recordset is returned is when there is a database error:

dim s as string = "Select * from MyTable where fldLastName = '" + SomeCritera + "' order by fldLastName"

dim rs as recordset = db.sqlselect(s)

if db.error then
   
   msgbox "DB Error in " + CurrentMethodName + endofline + db.errormessage
   
   return
   
end

while rs.eof = false
   
   //do something with the data
   
   rs.movenext
   
wend


So perhaps that’s not ideal because you don’t want to end user to see the error but you should at least have this sort of error checking and handling to see what you did wrong (if anything).

I think some of this practice has come from developers migrating from Visual Basic 6 where exceptions are raised on a database error.  They expect REALbasic to do it too so don’t even think about it.  The other reason is that Real Software’s examples and documentation don’t check for errors like they SHOULD be doing (they might be now that Paul L is doing the documentation but for years this has been a problem).

We do a dozen or so big projects a year so this means that over the past ten years we’ve done hundreds of database projects.  Eventually we found ourselves doing the EXACT same code over and over and over and over again and eventually we got tired of it.  So we came up with our own methods for checking for and dealing with database errors.  One of those is our own SQLSelectRaiseOnError:

Function SQLSelectRaiseOnError(extends db as Database, sql as String) As RecordSet
   
   dim rs as RecordSet = db.SQLSelect( sql )
   
   if db.Error then
      
      raise new BKS_Database.DatabaseException( db, sql )
      
   end if
   
   return rs
   
End Function


So rather than calling the built in SQLSelect statement we use our own that will raise our own subclassed Runtime Exception.  It’s Constructor is VERY simple:

Sub Constructor(db as Database, sql as string = "")
   
   if db.Error then
      
      ErrorCode = db.ErrorCode
      
      ErrorMessage = db.ErrorMessage
      
      Message = Str( ErrorCode ) + ": " + ErrorMessage
      
   else
      
      ErrorMessage = "Unknown error"
      
   end if
   
   if sql <> "" then
      
      Message = Message + EndOfLine + "   " + sql
      
   end if
   
End Sub


We capture the error code, message, and hopefully the sql the developer used.  Then we can either use Try/Catch or handle the exception in a manner of our choosing.

At this point you can guess that we have our versions of SQLSelect, SQLExecute, and DatabaseRecordInsert.   Our initial (error handling) method then turns into:

dim s as string = "Select * from MyTable where fldLastName = '" + SomeCritera + "' order by fldLastName"

dim rs as recordset = db.sqlselectRaiseOnError(s)

//If exception it returns immediately!

while rs.eof = false
   
   //do something with the data
   
   rs.movenext
   
wend


This saves potentially 4 to 5 lines of code and over the course of a big database project this could mean thousands of lines of code.  We are lazy programmers – we don’t like to do more work than necessary and this is one way to accomplish that goal.

So do yourself a favor, always, always, ALWAYS check your database for errors.  It will make your life easier – I guarantee it!

If you’ve gotten this far I will say it again:

ALWAYS CHECK YOUR DATABASE FOR ERRORS!

Happy programming!  What other tips do you think would help people new to Real Studio?

 

[Edit:  Changed the code calling the new BKS_Database.DatabaseException.]

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