s = “Select field1, ” _ //1

+ “field2, ” _ //2

and so on but it’s still a pain.

Anyway, Christian S. posted a comment that got me thinking.  He said:

idxField is good. It can speedup applications a lot.

Is that really true?  I have never tested it so I created a little test application using an actual query from the project I’m working on.  I run the same query twice.  The first time I loop through the recordset using nothing but idxField and the second time I use nothing but field which uses the field name.  The results are interesting and confirmed my suspicions.

If I run my two functions just once and bring back only 1 record and do one read in the function the idx field is indeed faster by about 50%.  However my testing differences range from 6 to 300 microseconds faster and while I didn’t average out all the results, I’d say most times it was around 60 microseconds faster.  I ran this test a lot to see if I would see a wider variation but did not.  My 300 microseconds difference happened just once out of about 25 runs.

I changed my query so that instead of bringing back 1 record it brings back over 700 and I loop through the recordset and then do the same same test.  IdxField comes back about 15% faster.  When I loop through the same row 10,000 times there is no statistical difference which means that while Field is slower it’s a one time hit since my tests show that even doing the same pull 10,000 times the total difference between the two functions is still only about a 10-15% difference in overall speed.

My conclusion is that yes, idxField IS faster than using Field but to say it speeds up an application “a lot” is an exaggeration.  In 10 years of Real Studio consulting work I have rarely done an application that requires that much speed from the queries.  If you have any sort of graphical user interface I think it safe to say that updates to the controls on screen are significantly slower than pulling data out of the recordset.  That’s NOT to say that the query itself is fast because often times that is the most limiting factor.

I won’t discourage you from using idxField.  If you do, though, I really encourage you to use constants named after your fields.  So perhaps you create a constant named kField1 and the value is 1 for the first field in your recordset.  The only drawback to this approach is that you (or the developer after you) will change the SQL query and all the code using idxfield no longer works because your field order is different.

I much prefer the explicitness of using Field because I never have to worry if I change my field order.  It’s very readable.  It’s not perfect and there are plenty of reasons why it’s not the best (there’s a reason why we use ActiveRecord in a lot of projects).  Use what’s best for you and what’s best for the five years from now.

What say you, RB developers?

OPC is our internal slang for Other Peoples Code.  I’ve talked about this before but just in case you’ve never been here before, OPC projects are always the most dangerous kind of projects to work on.  They can quickly become a rats nest and cause no end of grief mainly because you have to figure out what the original programmer (or programmers) was thinking.  Because it’s a Friday afternoon and I’ve been up to my elbows in digging through your OPC project all week here is my list of complaints:

• Poor variable names:  Variables such at ‘tmpd’ and ”bDbDl” don’t tell me anything.  Long variable names aren’t going to kill you and using Real Studio’s autocomplete will (usually) make this a non-issue.
• Three Letter Acronym (TLA) Variable names:  Stop being lazy and use some real words.  Obviously you didn’t expect someone else to read your code in five years.  If I ever find you I promise I will mock you.  I hope you are doing a better job of naming variables in your new job than your last one!
• Poor method names:  Methods named “SelAcc” and “DoWork” don’t give me any type of clue on what it does – especially when you have no comments in your code.
• Nested If-Then Blocks from Death:  There are times you need to do this but it’s been my experience if you’ve got more than 2 or 3 at any given time your method is too long and should be broken up into smaller methods.  Keep it simple.  Complexity kills.
• Multiple nested loops from death:  See nested if-then blocks from death above.
• Long methods:  This kinds of goes with the previous two.  If your methods scroll and scroll and scroll you have a problem.  If you had a problem in that method (i.e. it throws an exception) good luck finding the problem.  Break it up into smaller chunks of code.  Perhaps you can take the 100 lines of code you have the first part of your IF statement and break that out?  Just sayin’.
• Controls using the default names:  Really, you expect me to figure out the difference between TextField1 and TextField11 by making me look at the UI?  Next time, please use a name that will mean something to you in code.
• Controls using generic names:  On the flip side you used a name different than the default one.  Good for you.  Perhaps next time you can use something other than ‘s’ for its name because it took me a while to figure out it was damn text field rather than just a plain string.
• Constant names versus property names:  Quite ingenious the way you used the same constant name as a property name so that the IDE doesn’t help me in autocomplete.  Thanks.  That’s ones special.
• Stop trying to be fancy:  I get it.  You went to whiz bang college and learned some cool programming tricks and techniques and you’re pretty smart.  Remember, you’re writing for your boss/client/person who signs your paycheck so don’t forget that you’ll eventually move on/get fired/hit by a bus.  Be nice to the poor bastard that has to learn your code after you.  Assume they do not have your skill set.
• No comments/documentation.  Of course given all the previous bullet points this one isn’t surprising.  Would it have killed you to put a sentence – ONE SINGLE &*^!@% SENTENCE – describing what a method does?  If you hadn’t done all of the above items too that’s all it would have taken but instead you have ZERO comments in 10,000+ lines of code.

But, I must say thanks for reminding me why I don’t like working on OPC projects.  You’ve taught me that just saying “no” in future projects will make my life easier and less complicated.  My wife, kids, and dog will like me better if I don’t take another OPC project.

I think if I had any advice for programmers just starting out.  Spend six months fixing Other Peoples Code (OPC) and see what drives you absolutely bonkers.  Then, and only then, can you start writing your own code.  You’ll hate it but it will give you some very valuable experience early in your career, on the things not to do.  Being kind to the developers that come after you is just as important and by doing this you’ll know.

Ultimately I’m a lazy programmer.  Not that I don’t do the work I just don’t want to work that hard at figuring out old code.  If you name your variables and methods properly and consistently, keep your methods short, and if you write minimal comments it’s not that hard to figure it all out later.  Having to guess at someone else intent makes my head hurt.

Sincerely,

Bob

So dear readers what OPC foibles drive you crazy?

This method or property does not exist.

The first initial response is, “Of course it !$#^ exists!  I just coded it!  Stupid Real Studio.”  I totally understand the reaction because I’ve been there and done that and have the t-shirt to prove it.  It’s frustrating because the compiler message doesn’t really give you the real reason for the error.

The error is misleading but I’m not sure there’s a way for the compiler to come up with a, “You cannot call methods or properties of a base class without an instance,” message.  There are times when you can call a Shared Method or Shared Property of a base class but those are fairly rare (so far) in the Real Studio framework.

It sucks that the IDE code editor auto complete lets you call methods and properties from the base class rather than the instance.  For all of the times that auto complete is good, this is an instance where relying upon it can be a misleading and lead to poor decisions when writing your code.

I also blame the way Real Studio names their controls and classes by default.  Class1, Class2, Button1, Button2, etc are really poor ways to name your objects but that’s the way Real Studio defaults their names.  I would almost prefer a GUID name so it would force developers to come up with meaningful names.  If nothing else, it would certainly help if, when adding a control or class, the first thing to get the focus is the name in the properties list.

This poor default naming conventions is part of the reason why we, at BKeeney Software, name everything we reference in code (and many things we don’t call either).  The names of our classes, controls, methods, and variables are consistent across our three full-time Real Studio consultants so that when one of the other three has to look at code we’re constantly not having to look back at the Window Layout Editor or base class to find out what the object does.

It seems overkill, but we work on about two dozen big projects a year an we’ve been doing this for ten years.  There’s no way that I can remember what I did ten years ago much less six months ago.  So we try to be consistent with how we name things.  You should too because as your project grows there will be portions of your project you won’t see for months and even years.  Why not make life easier for your future self?

Happy Coding!

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

We answer most posts that potential clients add at the Find a Developer Page and while we don’t get an answer from everyone we do talk to quite a few.  What amazes me is how few developers are responding to referrals.  A potential client told me today:

You were the first (and so far, the only) to reply.

This was a fairly straightforward project that was for a cross-platform app.  The client even knows what technologies they want to use.  How hard can that be?

The Developer Referral Program cost $495 for 12 months and $295 for 6 months.  This isn’t a lot of money (it used to be a lot more when it was bundled with priority support plans) and it can easily be made back on a single project.  If you’re looking for Real Studio development work, this is a good way to get into it.

What’s great about the Referral Program is that the people asking for developers already believe they need Real Studio.  There’s no selling them on the benefits of Real Studio – they’ve already decided on it!  Talk about shooting fish in a barrel.

Anyway, I just thought I’d share this with you.  Every Real Studio consultant I know (and I know more than a few) is busy.  There is enough work for more Real Studio consultants.

Malformed header from script. Bad header=App.Open

What was in my open event?  Well, I was connecting to the database and upon success opening  a web page and that’s it.  Simple, right?

I was also doing some logging and was calling a method called PrintAndLog which would append whatever string I passed in to a log file and it would send the same message to the console via the Print command.

After much tearing out of hair (and those that know me surely will recognize that I’ve done this a lot!) I commented out ALL the code in App.Open and ran it on the server.  It worked!  So I then started uncommenting code line by line.  Eventually I got to the PrintAndLog call and sure enough that was it.

I then did the same thing in the PrintAndLog method and discovered it was the very first line in the method:

print s

Crazy huh?  Comment out that line and it works again.  What makes it weird is that I’ve used this in multiple places AFTER app.open and it works fine.  So I can only conclude that it has something to do with the application initializing and that print isn’t recommended at that point in time.

Yeah, I agree, it’s a stretch but stranger things have happened. This has been reported <feedback://showreport?report_id=17388> with an example project (the project is private, sorry).  Oh, and this still happens in the R3 beta’s.

So hopefully this might help someone in a similar predicament.

Real Studio doesn’t have database binding like Visual Basic 6 but it’s not a real big deal.  If anything, the lack of binding makes the code more explicit (i.e. easier to read) and you don’t have to go hunting through control properties to find table and field names.  The Real Studio database classes are generic so it doesn’t matter, generally, what database you’re connecting to.  The drawback to the lack of binding and the generic classes is that it does lend itself to creating the same code over and over and over again.

Because of the nature of Real Studio many users tend to put their db code into the form (window) and tie it to controls.  This leads to spaghetti code with the database specific code all over the place and makes changes to your database harder.  Seth has done two presentations at ARBP conferences 2009, 2011 and introduced attendees to ActiveRecord that we’ve used for years now.

Active Record is a very simple, and limited Object Relational Model (ORM) system.  It allows us to create REALbasic classes that the IDE knows about.  It’s not exceptionally strong with the relational data, or large blobs, but it can be programmed to handle it.

In a new project we’re converting an existing Visual Basic 6 project with roughly 25 tables and several tables have over a hundred fields each.  Using conventional means it would mean having a database editor open so I can copy and paste field names all the time.  However, using ActiveRecord we created the classes (we have a utility to do this) and now the IDE knows the table and field names.  This makes coding very fast and they’re is no worrying about spelling errors and there’s no longer any issue of what the data type is because the class knows what it is.  This is nice since the compiler will pick up any many errors that may not usually find until runtime.

The client was ecstatic after the conversion since he figured that would have taken about 20 hours to convert the VB6 code into something useable in RB.  Instead, between our utility and ActiveRecord it took me less than 4 hours.  So now instead of spending all the time getting classes ready, we’re doing the real work of connecting up the UI to a set of data aware classes.

Another feature that was added was to flag the developer if a field is in the database that isn’t in the class.  How many times do you add a field to the database (or a coworker does) and you forget to hook it up.  This doesn’t happen using ActiveRecord.  You can have class properties that aren’t a field, but if you delete a field property that’s been used in the application the compiler will flag you on it and that’s very useful too.

ActiveRecord makes extensive use of Shared Methods so that all of the database code for that table is access from that class and that class only.  It has a number of methods built-in such as getting a list of rows (in array form) and finding a record by the primary key.  It’s easily extensible.

Like I said earlier, it’s not perfect.  It doesn’t handle relational data at all, but it can be modified to do so.  Large blobs can slow it down, but in the few times this has been a big deal we’ve implemented ‘lazy loading’ where we don’t load that particular field until we ask for it.

We have a single tutorial page up for it now at the main website.  We’ll eventually turn this into video tutorials and we’ll demonstrate it in more video’s.  It’s an MIT style license so feel free to use it.  If you have additions and suggestions, please don’t hesitate to contact us.

More information, and downloadable classes can be found at http://www.bkeeney.com/realbasic/activerecord

Like most developers I’ve had to mock up user interfaces for a lot of projects.

In the past I’ve used two approaches for this: a) Get everyone in the same room and share a whiteboard or a piece of paper or b) use Real Studio to create an interface that doesn’t have any code behind it. I’ve even scanned hand drawn mockups and sent those in an email.

I hate using Real Studio (or any other IDE, it’s nothing against Real) to mock up interfaces. The problem is that the end result looks like it’s a real program, so if I don’t make it look nice then it looks like a program that sucks instead of a mockup of a nice program. The whole point of mockups is that nobody is sure exactly what should be on a window or how different parts of a program should fit together so polishing the UI is a waste of time.

Another problem is that a mockup that looks like a finished program is easy to mistake for a finished program by a non-programmer. This is a point I first heard made by Joel Spolsky over at Joel on Software. Unless the goal is to actually design the final interface for a program I would stay away from this approach.

The advantage of the whiteboard and paper approach is that nobody looks at a freehand drawing and thinks that the end program is going to consist of blue lines that aren’t quite straight. But the end result is usually kind of disorganized and it’s hard to store much less revise it in the future.

Enter Balsamiq Mockups. This is a very slick program written by Peldi Guilizzoni (originally written during nights and weekends while he worked at Adobe). It’s basically a wireframe drawing tool with a bunch of standard UI components like buttons, windows, scrollbars, and many more that look like they’re hand drawn. You can drag things around and change labels pretty much like a designer in an IDE except without any real limitations on where things can go since it’s all just a drawing.

The end result is a surprisingly attractive design that could never be mistaken for a working program or an actual UI. Mockups is developed using Adobe AIR and as a developer of native apps for Mac and Windows, I wasn’t sure it would feel quite like a native app and it doesn’t, but it also turns out that it’s been so well designed that it’s actually fun to use and there’s not really any learning curve to speak of. Overall, I highly recommend mockups to anyone who develops software for a living.

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.

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?