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

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.

Does this change with Windows 8?  I don’t know, but I’m already seeing an uptick in developers that are looking to convert from Visual Basic 6 to Real Studio.  Uncertainty is a bad thing and even the full-time Windows developers I know don’t seem to know what’s going on.  Some of them are even worried that .NET and Silverlight support is up in the air.

The only thing that’s been mentioned for Win8 is JavaScript and HTML5.  No mention of .NET, Silverlight, or even Win32.  It’s very uncharacteristic of Microsoft to be so secretive and up-in-the-air over a future product.  Are they trying to be more Apple-like?  Perhaps that’s why people are freaking out.

Do I think MS is going to drop support for .NET, Silverlight, or even Win32?  Not a chance.  They have way too much invested in each of those to abandon them.  From a corporate standpoint there would be a revolt since almost everyone has invested, heavily, in one or more of those technologies/platforms.

But are Visual Basic 6 apps still safe?  That is a very good question and from the research I’ve done it appears that the VB6 runtime will not be shipped with Win8 though some in the community suspect that a hack will be found before release.  Other comments I’ve seen indicate that Win8 will ship as only 64 bit.  The VB6 runtime is 32bit only so that will mean running in compatibility mode which adds to the possibility of it not working properly for all applications.

Microsoft, at some point, has to kill compatibility.  Visual Basic is an old development environment that doesn’t take advantage of many new technologies.  It’s also not a very good object oriented language – it just wasn’t designed to be that way.  If the MS dev tools of the future are Silverlight, .NET, and JavaScript/HTML5 (does anyone really believe that!?), then it sure seems that VB6 might be on its way out.

So while VB6 apps might work with Win8 using hacks and compatibility mode, I believe developers have every right to be worried.  They’ve invested heavily in VB6 tools and controls and now the (long) honeymoon is over and it’s time to look at alternatives.

If you are only interested in Microsoft then the options are easy with .NET or Silverlight (assuming they aren’t going away).  If you’re thinking of a Mac or Linux version than the options are limited.  You could do Java, but as a long-time Mac user I’m not a big Java fan and try to avoid them because their UI generally isn’t native (I’m a Mac snob, but then most of us are).  Qt is a possibility but it’s not a RAD option either.

I am a little biased but I think Real Studio is a good choice for those coming from Visual Basic.  They are very much alike in how they work though REALbasic is MUCH better at object oriented programming than VB ever was.  It’s newer and is on a regular update schedule.  And, with just a little work, you can easily make apps for Mac, Windows, and Linux that look the same on all three platforms.  And now that Real Studio can make Web Apps there’s a fourth platform that you could potential support (though making a web app involves different controls, editors, etc so it’s not as easy as clicking a checkbox).

Is it a quick and easy conversion?  No.  Don’t trust any conversion program and, from experience, any converter will be just as time consuming (if not slightly worse) as rewriting from scratch.  We’ve found that taking a look at the UI and making it a bit more object oriented to take advantage of the strengths of REALbasic is always worth the investment.  We like to say you’re writing the apps for the next ten years and not only for right now.  So doing the extra work now will pay off for years.

Is Real Studio perfect?  Absolutely not.  It currently is not 64 bit compatible either though I know of many developers that have no issues with running in Windows 7 64 bit.  I do know that 64 bit compatibility is the next big upgrade for Windows after Real Software finishes up on Cocoa builds for the Macintosh side.  If memory serves they are on track for late 2011 64 bit compatibility (though that’s always subject to change).

With Win8 on schedule to be released next year (does anyone really believe that either?), you might need to be proactive and start thinking about the alternatives now.  Waiting until Win8 is released might be too late for your product.  Do you really want to be under the gun from management to get something that works on the CEO’s new shiny Win8 laptop?

If you would like to get a rough estimate on cost to convert from VB6 to Real Studio, we (BKeeney Software) have a VB6 Analyzer Tool for you to download (written in RB of course) that analyzes your project and gives us some metrics on lines of code, controls used, numbers of classes, etc, that help us give you an estimate.  More information can be found at http://www.bkeeney.com/consulting/vb2rbconversion.

Yesterday I ran across a problem where my app was crashing immediately upon startup.  The crash log gave a very odd error message:

Dyld Error Message:  Library not loaded: /System/Library/Frameworks/user32.framework/user32

Wha?  User32?  That sounds like a Windows library and certainly nothing I’ve ever seen on Mac OS X.  I actually wrote the ‘bug’ up and sent it in via Feedback and then did some more research.  The answer wasn’t really all that surprising.

I have a lot of old code that I’ve developed, bought, and found over the years that make it into most of my projects.  It’s there and I don’t even think about it.  One of the pieces of code that I bought from someone works cross-platform Mac/Windows and so it has a ton of #if statements.  Things like this:

#if targetcarbon then

//Do Mac stuff

#else

//Do Windows stuff

#endif

See the problem?  If I wasn’t making a Carbon application, which Cocoa most definitely is not, it attempts to run the Windows code.  So now the crash log makes total sense.  I suspect that a lot of people will have a similar problem.

Check your projects for compiler switches like this.  If you’re developing cross-platform applications you’ll probably have this problem.  In the long run all I did was do a simple global search for #if targetcarbon and replaced it with the target for Mac OS.  That won’t work for all cases, but it should get you close.

Ideally I would love for the Real Studio compiler to give me a warning for this case but I don’t think that’s even possible.  Really, how many libraries are there in the world to know about for each platform?  Impossible I say.  At a minimum, however, I would think that it would be possible to get a better runtime error.  Sort of like how you get error messages if you don’t have the plugin libraries where the executable expects them (much more of a problem in Windows if you move the Libs directory).

What say you my fellow REALbasic geeks?  Have you tried Cocoa yet with 2011 R1.1?  Any major problems?

Real Studio is a cross-platform development tool.  It runs on Mac OS X, Windows and Linux.  In the Professional/Enterprise versions you can build for other platforms and debug on the other platforms as well while staying your native environment (using remote debugging).  It’s really an awesome experience running Real Studio on the Mac and running the executable via VMare (or even on another machine in the office) running Linux or Windows.

We see it time and time again (and we’ve been guilty of it ourselves a time or two) where someone does all their development on Mac OS X and tests on Mac OS X but their app looks awful once they get it into Windows.  Text backgrounds looks like crap and the flickering is atrocious whenever they resize the window or move controls around at runtime.

The reason?  Mac OS X and Linux have double buffered windows while Microsoft Windows does not.  Mac OS X and Linux always draw to a buffer first and then draw to the screen.  Windows does not which is the cause of much flickering.  Real Studio has some easy workarounds for a bulk of the flickering and some simple rules of thumb to reduce, if not eliminate, Windows flickering issues.  Among them:

• Canvas objects should have Double Buffering turned on
• Do not erase the background of Canvas and Container Controls
• Be wary of using Refresh – perhaps Invalidate is a better choice
• Layering of controls will almost always get you into trouble.  Putting anything over a Canvas control (that draws anything) is almost a sure way of getting into trouble

So the lesson is that you really should be testing your app in all of the environments you plan on supporting early in your development process.  If you wait until you’re about ready to ship it’s too late.  You might have some fundamental assumptions in the project that’s hard to fix now that you’re almost done.

Cross platform development is easy using Real Studio, but that doesn’t mean there aren’t differences.  You need to test for those differences early and on a regular basis.

Since I spend most of my time on the Mac side I’m assuming Windows and Linux RB developers have the same issues going to the other platforms.  What are some of the issues you see?  Did I miss any reasons for Windows flickering?

For many people, using Real Studio is a Love-Hate relationship.  Mine is no different.  I’ve been using it for over ten years and while I find it easy to use and very powerful, there are times I feel like putting my fist through the monitor due to frustration.

Real Software releases a new version of Real Studio roughly every ninety days as part of their Rapid Release Model.  From one aspect it’s nice since I know when a new version is going to get released and plan for it.  I know that there will be some new features and a whole bunch of bug fixes.

Unfortunately getting a new version is often an exercise in futility because new releases can sometimes break existing functionality.  Since I work on so many projects I’m often waiting on a particular bug fix in the next version so I’m forced to upgrade.  The frustration of finding yet another bug upon trying the new release is sometimes too much.  If you find me grousing about Real Studio (see last summers Windows rants) it’s generally after one of these types of upgrades.

I’ve been very critical of RS in past because of new features that just plain don’t work.  Rightly so, in my opinion.  New features don’t get tested in the beta process because there’s usually no documentation and usually no example projects showing how it’s used.  Either case is bad and it has to get better.  The perception that Real Studio is buggy, wether right or wrong, has to improve.

Look, I know that every release has significant bug fixes and only a few new features.  I know because I’m part of the beta program and have been for a long time.  But as a beta member I don’t feel like the program lets me help Real Software very much.  I can’t tell you how many times I report a bug, it’s gets marked as fixed and then I have to scour the release notes looking for bug reports that look like mine.

The feedback system and releases aren’t designed to help me verify the fix.  I feel that a bug isn’t fixed until the bug reporter has verified the fix.  From my aspect it’s very inefficient and I wish it was better.  But since it’s not my system I can’t do much about other than offer suggestions.

The future on Mac OS X is Cocoa.  I expect that in the next release or two, the Mac OS X IDE will be built for Cocoa.  When that happens, you’ll know that Cocoa is really ready.  Building for Cocoa will give RB users the ability to harness some of the Cocoa goodies that Mac users come to expect from their applications.

Unfortunately, Cocoa isn’t going to help Windows or Linux as it just makes the platforms that much more different.  However, I do know that much of the work that has gone into Cocoa has involved rewriting major portions of Windows and Linux to fit the newer event models rather than the old Carbon/Classic model.  I don’t know the specifics but it wouldn’t surprise me if almost all of the frameworks was rewritten accomplish this.

I’m not sure where Windows is heading in the future.  Real Software is a Mac heavy company and it’s hard to know how serious they are about Windows.  Last summer there were some very easy and very serious Windows bugs that bit me very hard (because of the upgrade cycle) that very nearly cost me a big project.  I just don’t see much going on for advanced Windows support but perhaps that is just a byproduct of the march to Cocoa.  After ten years they still don’t have full COM support and without it there’s just a bunch of stuff that Real Studio won’t be able to do.  It’s also unknown when 64bit support is coming and when Microsoft will switch over to a full 64 bit OS.  I think this is as every bit as important as the switch to Cocoa on the Mac side.

I have reservations about Linux support.  I wonder if the time and effort is worth it in sales for Real Software.  As a consultant I get no one asking for Linux apps but perhaps that’s anecdotal evidence since I’m heavy into Mac and Windows development.  Also anecdotally my blog and website just have a few percentage points of Linux users that visit on a regular basis.

We know that a User Interface change is coming.  Geoff demoed it at the Atlanta Summit but no pictures have surfaced yet.  From what I can remember, it should reduce mouse clicks as the Project Tab will be easily accessible all the time.  Unused events will not show in the Events list until you add them (I believe the most common event(s) will automatically be added).  A new tool palette was revealed that reminded me very much of xCode/Interface Builder.

I would also expect a lot of the Web Edition editor features will make it into the new IDE.  The in-line editors are generally okay but I’m not a huge fan of them.  I really hate the new Tab Order Editor as it’s confusing once you get more than a dozen controls on the window.  I’m also not a big fan of the object handles (that allow you to resize controls) since they’re a major pain to use – they disappear when you’re resizing.  This means that controls have to have special visual modes to show their sizes unlike the current Window Editor where controls have a visible outline.

One feature that I do like is the pasteboard that is automatically populated at the bottom of the WE page editor when placing non-visual objects (like timers).  This probably means that Dialogs will be rewritten to act just like the new WebDialogs.  One can hope that they will retain the existing methods.  I also expect the Radio Button control to be replaced by the RadioGroup – again, similar to what Web Edition did.

Some of these changes make a lot of sense from a beginner perspective.  They are common questions from new users and are a solution to aid them.  From a power user perspective I’m trying to be as open as I can to the changes.  Some will grow on me I’m sure with usage.  Others, I’m just as sure, will make me pine for the ‘old days’.

We can only hope that Real Software has a feature complete IDE when it makes it into the beta program and lets hope that they’re not adding major functionality to it during the beta.  Otherwise I expect a chorus of very vocal naysayers and boo birds.  A User Interface change is a big deal and should not be taken lightly.  I hope they do their own (very strenuous) internal testing on it before foisting it on us.

Eventually, Real Software will switch the back-end compiler to LLVM.  RBScript is already using LLVM and while that was a significant step, it’s probably going to be a lot of work to switch over all of Real Studio to it.  If my sources are correct, they’re going to writing their own linker for Windows which I have no doubt is more work than they expect (Cocoa was only going to take 18 months remember?).

Will LLVM lead to Real Studio being able to compile for iPhone and other mobile devices?  My answer is a big maybe.  I have a hard time figuring out the marketing for including mobile devices in the current product other than to saying you can reuse much of the same code, but just like with Web Edition you really have a separate product with separate editors and separate compilers.  I have no problem with a mobile optimized IDE that leaves the cruft of desktop and web apps behind.  I think it could be brought to market faster that way too.  Like much of the rest of this post, it’s pure speculation on my part.

One thing I wish was improved was the Real Studio debugger.  Anyone that’s come from the Visual Basic and .NET world understands what I’m saying.  The Real Studio IDE debugger just isn’t easy to use.  No watchpoints and always having to refer to the listbox to view variable values is huge pain (wouldn’t it be nice to hover your mouse over a variable and get the value in a tooltip?).  Many Real Studio users don’t even realize that you can view the call stack since it’s a popup menu (poor UI choice, in my opinion).  Many also don’t get the whole breakpoint and exception handling either.

There is still a bunch of essential controls missing from the standard control list.  After ten years there’s still no date, time, or calendar control.  While the standard listbox is fairly powerful, it’s a beast and you just get to a certain point where it’s too slow and cumbersome to use.  For those needing them, they’re forced to use a 3rd party set of controls.

I think much of these limitations is all based on how Real Software uses the tool themselves.  The IDE has absolutely no need for grid, date, time, or calendar controls.  You could certainly argue that the reason why the TextArea RTF support is so weak is because the IDE has no need for it.  The same with the lackluster support for TextField masks.  Likewise, to the best of my knowledge, the IDE does not use the built-in reporting tool and, it too, suffers from having no strenuous use from the company that designed it.  Modern toolbars?  Need I say more?

I’ve argued for years that RS could really use a consulting group that bids and works on projects just like the rest of us consultants.  A lot of the projects I work on run into the same constraints time and time again and I’m forced into less that optimal solutions.  I can submit Feedback reports until my fingers bleed, but until RS has to fulfill a need for themselves it probably won’t happen.  Personally, I’d welcome them into the consulting business.  Sure, it means more competition for me personally, but I’m okay with that as it will make the product better.

Sorry for the rambling post as there are lot of things that I’d love to see RS do a better job at and improve in the product.  I really do appreciate the work they’ve done as it pays for my, and my employees, salaries.  As a professional user my needs are vastly different than a majority of Studio users but as someone who spends a considerable amount of money on yearly license updates and the referral program, and spend a lot of effort selling the product to clients I feel that my needs should be aired publicly.  My time with ARBP has shown that many of you agree to varying degrees.

Those are some of my wants, needs, future predictions, fears, worries and gripes.  What say you?

Regardless of the marketing terminology, after spending some time this week working with a beta of REAL Studio Web Edition, I think I can fully jump on board the band wagon.  I have several reasons for doing so.

First, it really is that easy to use.  Instead of creating a desktop application you create a web application.  The editors are mostly the same.  The controls are similar to their desktop counterparts.  The frameworks, for the most part, are the same ones you’d use in the desktop apps.  All the knowledge I’ve gained creating desktop apps for myself and clients over the years isn’t going to waste and can be reused quickly.  No need to learn a new language, IDE, and framework.

My second reason is purely selfish and it involves George Washington and Abe Lincoln.  A lot of them, in fact.  I’m a consultant and when I first heard about Web Edition I was relatively impressed, but wasn’t sure about it.  When existing clients started asking me about it and when I started fielding inquiries from potential clients I got real excited.  The bottom line is that if I can sell more consulting time I make more money.  Period.  Do I really need to explain more?

Add in that I can now offer web apps using the same developer using the same development environment with only minor changes makes REAL Studio that much more attractive to potential clients.  I don’t have to hire a web developer or sub-contract the web portion out.

Now, with all that said, there are still a lot of questions to answer.  We don’t know, yet, what the drawbacks are.  It looks like a number of controls will be fairly basic to begin with – I wouldn’t expect less from a 1.0 product.  Browsers are notoriously fickle beasts.  What browsers will work 100% of the time and which ones will have issues?  It’s still too early to tell, but if I was a betting person I’d bet that Safari, FireFox, and Chrome will be pretty solid.  Internet Explorer 7 and above will mostly work but anything earlier will suck big time have issues.

The other issue we yet to have any definitive answers yet is installation on a web server.  Will FastCGI work and will it work on shared web hosts?  How good/bad is performance on a shared server?  How well will it scale with a limited number of users versus hundreds or thousands of simultaneous users?  How well will Web Edition apps handle security attacks like SQL injection attacks?  How well will it work with mobile browsers?

The potential for a huge hit is there.  If it proves to be a solid product and gets people excited about using it, it will create a buzz not only for REAL Software but consultants like me that are already familiar with the product.

• Name any control you reference in code.  It needs to make sense to you.  If you have a bunch of Pushbutton1, Pushbutton2, etc. pushbuttons you are causing yourself grief in the long run.  You’re coding not only for right now, but for 5 years from now when you’re not intimately familiar with your UI and you want to make a change or fix a bug (or hand it off to a consultant).
• If you find yourself copy/pasting code over and over again you should think about a global method or perhaps a subclass.  I’m talking about the MessageDialog alerts, the ComboBox helper code, etc.  The reason this is a problem is that if you have the same code all over the place and you have to change it, you then have to change it everywhere.  The chances of missing one hase big bug implications and your clients/customers may not appreciate the bug.  This is called, by the way, refactoring and it’s not a bad thing to do.
• Big, huge, monolithic methods/functions are not good.  My general rule is that if my method is over a screen length I start looking at ways to break it up into smaller chunks.  This makes it easier to debug too since the runtime exception doesn’t have line numbers on where a bug occurred.  All it can give you is what the error is and where it occurred (and even sometimes that’s not reliable).
• Name your variables something that make sense to you.  You need to come up with your own guidelines, but the reason is the same as naming your controls.  You should, at a glance have some level of understanding of what the variable is for.  I don’t name loop variables (i, j, k, x, y, etc) unless I have nested loops.  Some would argue that prefixing your variables is a dumb idea because RB is very strongly typecast and if you change the type you then have to change the prefix.  Um…sure…that’s what global search and replace is for.  But I can tell at a glance what type the variable is.
• Name your methods/functions something that make sense.  Same reasons as above.  If you can’t figure it out at a glance what it does, then you might need to rename it.
• One that keeps haunting me (in other words I haven’t always learned the lesson on this) is to use a thread whenever there’s a tight code loop.  It always seems that during testing I have far less data than I will in real life so that tight loop that only takes a blink during development takes seconds in production and causes the app to ‘freeze’.  Threads are a natural way to solve that problem.  I urge you to not use refresh statements in your loops – instead use a thread.  Of course threads aren’t perfect in that you then have to worry about how you update UI but if you have the Thread in the window you’re generally pretty safe.
• Test your cross-platform apps on each platform.  Don’t assume that your Mac OS X application created in RB will look good on Windows and vice versa.  Trust me on this one.  Depending upon what you’re doing, Windows can be hugely different performance-wise than the Mac and Linux.  Double-buffering is standard on Mac OS X and Linux but NOT on Windows so that really great looking custom control on Mac/Linux looks just awful on Windows because of flickering.
• Project organization is important.  As your project gets bigger and more complicated having the big monolithic list of objects becomes harder to find things.  I generally start with Application, BKS, Others, and Assets folders in my projects and put everything in those folders.  The assets folder is icons and any other graphics for the projects.  The application folder has all app object, all the windows and application specific objects.  The BKS folder contains my own toolset of classes, subclasses, extensions, etc that I’ve written and use in most projects (I generally try to retain rights to any code in this folder).  In the others folder is my toolset of objects that are from others and I don’t claim that I wrote.  Some of these are encrypted and others are not.  Keeping your project tidy is a good thing.
• Code first for functionality and once it’s working you can test for efficiency.  I’ve found that some things I thought would be slow weren’t and some things I thought would be ok weren’t.  Get it working first and THEN worry about it.

Those are mine off the top of my head.  What guidelines would you share with someone new to coding and/or REALbasic?

Geeze.  How many levels of wrong is this rumor?  You think Apple is going to trust Microsoft with the keys to their iPhone/iPad kingdom?  I don’t think so.  Apple has worked too hard building xCode and Cocoa Touch to let a 3rd party develop for iPhone/iPad.  If this does happen, then Apple might as well give Adobe a call and let them know they can restart their iPhone/iPad programs too.  And we all know where that feud isn’t over yet.

Where this might make sense is desktop applications.  Microsoft, while doing all that work to write Microsoft Office for the Mac in Cocoa, wrote their own Cocoa libraries and other Mac GUI editors and put it into Visual Studio.  Seems like an awful lot of work with minimal gain for Microsoft unless they’ve decided to make a push in REAL Software’s corner.  They certainly have the knowledge and resources to do such a product.

While I don’t think this rumor has legs it does make you think.  No doubt Microsoft is feeling the pinch of developers learning Cocoa which does nothing for Microsoft.  If they developed a cross-platform Visual Studio it stems the bleeding because now developers don’t have an either/or decision to make.  Learning a new development tool and frameworks suck and letting all those Windows developers develop for Mac and Windows using their tool keeps Microsoft in the game.  It doesn’t help them with iPhone/iPad development (now) but in five years who knows.  If it does happen it will generate some serious buzz which is something Microsoft wants (needs?).

What does this do, if true, to our favorite development tools company located in Austin?  I don’t think it would be good news.

We have over a hundred videos and around 20 hours of training videos.  Our Journal Entry project, a simply diary application, goes through the process of creating a REALbasic database application from start to finish.  While we do all of the development on Mac OS X, we regularly go into Windows and Linux and explore the differences between controls and how to workaround those differences.

If you’ve ever wanted to see how other people use REALbasic, this is an excellent opportunity.  We have around two hours of free video (with registration).  Subscriptions are available and if you’re a student or educator, contact us to get up to 40% off full price.  ARBP paid members can get a 20% discount.

So far we’ve been getting excellent reviews!

[Updated]  Part of my motivation to moving to H.264 was to view the videos on my iPad.  The iPad is a really good medium for video training because it can run beside the desktop/laptop computer and you can do the same things in REALbasic while I’m showing it to you in the video.  Video on the iPad is gorgeous!