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?

Being that busy is always a good thing-bad thing proposition.  My backlog of Real Studio training videos just gets bigger by the day.  Oh well, they’ll wait until I’m slow or want to do something completely different for a few days.

I’ll admit that I have been very critical of Web Edition – especially when it first came out.  I felt that it was released too soon with obvious bugs and holes in the frameworks, wasn’t adequate testing, and was without features that were necessary.  A lot of that has changed recently (though WebMoviePlayer still burns a hole in my stomach) and we’ve found that most projects these days have some sort of web component in them.  Web Edition fills that need for us and while it may not be the best, fastest, scalable, or comprehensive web platform to deal with it has increasingly become a part of our standard package.

I mention this because all three of our developers are working on projects where Web Edition is used to some extent in conjunction with the desktop apps.  I think it safe to say that about 1/4 of all our Real Studio work is using Web Edition.  Not bad considering it wasn’t really usable until mid-Summer 2011.

Web Edition is much like Real Studio desktop apps.  You have limited options and there are a bunch of compromises that you might not be able to live with.  If you can live with the compromises, development is very fast.  While deployment can be kind of a pain it seems that most of them revolve around three or four issues (FTP transfer, file permissions, 32 bit compatibility libraries, and the .htaccess file).  The fact that you can reuse much of your code between desktop and Web Edition is icing on the cake.

Anyway, that’s what’s up with us.  How is 2012 starting for you?

I get their anger.  I really do.  I’ve been using Real Studio for ten years now working on a commercial products for clients all over the world.  Some of those are private apps, some are vertical market commercial apps and some are mass market  commercial applications.  I have probably been bitten by a bug in nearly every release and on every project.  It sucks but thankfully I’ve been able to find workarounds to most and come up with alternatives to others.

Don’t get me wrong, I’m not happy about bugs.  As a developer dealing with bugs is part of the job.  When I was an electrical engineer I dealt with hardware and software bugs ALL the time.  Try explaining to the client why a 1500 degree furnace stopped working because of bad firmware or why you stopped an automobile assembly line because a PLC glitch  When I was doing Visual Basic 6 development my code was a masterpiece of workarounds.  There is no excuse for bugs but they happen.  It’s part of my job to identify them and work around them.

One Real Studio user sent ME an email explaining how crappy Real Studio is.  It was reasonably intelligent email from someone who felt very passionately about the subject.  It was obvious he had a history of using Real Studio as a consultant.  I disagree with him on most every part of his email but I can sympathize.  Am I becoming to ingrained to ‘just dealing with it’?  I dunno.

Part of the problem, I feel,  is that Real Studio is geared for beginners and hobbyists.  That’s great and it’s how many long time users started.  Beginners don’t stay newbies very long if they stick with the product.  Soon enough they get past the initial learning curve and figure out how to ask the questions they couldn’t even formulate before and this is where the experience sometimes falls apart for many Real Studio users.

It feels sometimes that RS is solely interested in getting new users (and hobbyists at that).  New users are not a bad thing (in fact they are critical to any company).  However, isn’t retaining existing customers even more important?  You’ve already done the hard work in getting them to buy into the platform.  All you have to do is find the way to get them to stick with the product and ideally find ways to get them to upgrade to a higher priced product.

The Personal license is so cheap it’s practically giving it away at $99.  The Professional version is $299 so for every Professional license you have to get three Personals.  The Enterprise Edition is $995 so for every one Enterprise license you need ten Personal licenses.  Now, I don’t know what the renewal rate is among the licenses but I would suspect that Pro and Enterprise users renew more often Personal license users.  I know from a business standpoint my toolset is part of the cost of doing business so why NOT keep upgrading until I no longer use the tool?

My point is that Pro users are valuable and Enterprise users should be the most valued customers.  Instead, many of us feel abandoned for a variety of reasons.  As an Enterprise user I really like being able to use Web Edition, and use the product on all three platforms.    IDE Scripting, Build Automation are nice, but I could live without them.  I use the Profiler maybe once a year so it’s a feature that is wasted on me.  What makes the Enterprise edition worthy being an Enterprise product?  What are the compelling features for people to upgrade to Enterprise?  Not much at this point.

I’ve been doing this for ten years and I’ve been asking for the same things over and over again:  a grid component, a calendar control, date and time controls, less flickering in Windows, and finally reporting.  I lobbied hard for reporting and I feel like a fool for doing so since the reporting tool in Real Studio isn’t what I need (nor can use).  Instead I feel like I got a checkmark on a marketing page.

Granted, there are alternatives to many of the things I mentioned.  That’s not the point.  Instead of giving me the things I could use, today, in selling the product to my clients, I’m getting a new User Interface that will probably have some major bug when introduced that will make it less than ideal to use.  Did I ask for a new UI?  No.  I could think of a dozen things I’d like to see BEFORE a new UI comes down the pike.

So my hope for 2012 is some focus on features that Pro and Enterprise users need.  You can debate all day long on what those features are but the fact no one from RS has ever seriously asked me (or any other pro developer that I know of) what I need.  That says what they are focusing on instead.  Perhaps with some true Enterprise features more people would purchase Enterprise.

Well, but then again, I’m a long time Enterprise user and probably a bigger pain to support than those ten Personal licenses.  Happy coding!

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!

I have created a Shared Folder in Feedback where you can put your “Top Time Wasters” Feedback reports into for the world to see.  The Feedback link is <feedback://subscribe?folder_id=34>.  There currently about 20 reports in the shared folder that are worthy of your perusal.  A few examples:

• Plugin compiling glacially slow (currently ranked 768th)
• The compiler repeatedly prepares plugins.
• Edit Code button should jump to exact position
• Add version identifier to plugins
• Debugger:  Visually mark values that have changed
• Debugger:  Watchpoints (currently ranked 264th)
• Debugger:  Show variable values as tooltip when hovering over it (currently ranked 11th)
• Add Debug Run Default per project (currently ranked 1360th)
• Standardize Format should be automatic

These are really good ideas that could make my use of Real Studio more efficient.  Feel free to add your own productivity enhancement ideas.  With a new IDE user interface coming there’s no guarantee that RS will use any any of these ideas but you can at least give them some feedback on what you want to see.  The fact that some of these are ranked already says that some already agree with the user who posted it.

My own personal feeling is that the debugger is woefully incomplete.  It needs some redesign and some features added to make our lives easier.  An old ARBP survey asked about things that people wanted and the debugger was a very high want after more powerful grids.

Feel free to add your own in the comments section below, but what would be better is creating a Feedback report and putting it in that shared folder.

The DynaPDF plugin is very powerful and lets you create PDF’s and in the Pro Edition lets you display PDF’s in your Real Studio application.  The plugin is pricey but will worth if if you need it.  Here’s a way to save some cash.  From now until December 24th all DynaPDF plugins are 15% off.  More info on the DynaPDF plugin at http://www.monkeybreadsoftware.de/realbasic/plugin-dynapdf.shtml

Monkeybread is also having a raffle this week where you can win one of ten prizes:

• A MBS Real Studio DynaPDF Lite license (retail price $669)
• A MBS Real Studio DynaPDF Starter license (retail price $219)
• One 30% discount coupon for next order from Real Software.
• One 20% discount coupon for next order from Real Software.
• Six Real Studio Developer Magazines coupons for three free issues.

The first significant change in R4 is that it no longer compiles for PowerPC (PPC) which means that Universal Binaries can no longer be built.  Mac OS X versions 10.5 (Leopard) and better are now supported.  I have not tested this premise but your app might run on older versions of Mac OSX, please let us know your experience.

The R4 release sports a huge number of Cocoa fixes.  Cocoa is now mostly usable but there are still bugs and oddities in this version.  Drawers, StyledTextPrinter and MoviePlayers do not work in this release.  Drawers are not used (much) in Mac OS X any more and not many use StyledTextPrinter but the MovePlayer could be a significant problem for quite a few RB developers.  However, if your app makes use of these controls and classes you will not be able to upgrade and will have to wait for a future release of Real Studio.

You REALLY need to start testing your apps in Cocoa (if you haven’t started already).  You are bound to find something that RS hasn’t fixed yet, or, at a minimum, requires some additional optimization.  One bug that has hit us particularly hard in trying to port one of our apps to Cocoa happens when trying to access a toolbar with a separator.  When accessing it an un-trapped exception occurs which means your application goes “poof” and there is nothing you can do to catch it.  <feedback://showreport?report_id=18971>

Another Cocoa bug that’s affecting some of our projects is the graphics object.  If you use FillRect or ClearRect on a picture that ISN’T new it is extremely slow.  So, for example if you have an overall picture and you’re just updating a section of it, it will be very slow.  <feedback://showreport?report_id=18915>

Cocoa really is different than carbon and some things that appear to be bugs aren’t necessarily so.  For example, all fonts in carbon apps can be made italic.  In Cocoa not all fonts have an italic version so it won’t render it in italic’s regardless of the setting.  Carbon just happened to force an italic version regardless of the font whereas Cocoa won’t.

Web Edition has changes too.  The first is that all Web Edition projects now require the app.ApplicationIdentifier to have a value.  The IDE will no longer allow it to be blank and if it’s not filled in when opening an older project one is added for you (so be aware of it).  This is important because the each Web App running on the server must have a unique identifier.

The WebListbox received some much needed attention in this release.  Column widths now work properly (yay!) and no longer shows an extra column.  A new boolean property, called Multiline, was added to match desktop listboxes more closely and when set to true, each row will expand automatically to fit all the text.  If false, text is truncated to one line with ellipses if it’s larger than one line.

The WebToolbar has some new style options available.  These are not documented but You have control over the WebToolbar background, button, disabled button, item, toggled style and toggled disabled styles.  You can make some interesting combinations with these new style options.

Dynamic Constants in Web Edition can now be retrieved by language.  The WebPicture class now has 3 new constructors.  Unfortunately, you still can’t use dynamic constants like you can in the desktop editions so you have to code this manually.

Lest our Windows brethren feel left out there are a number of significant bug fixes in store for them as well in this release.  A number of memory leaks were fixed.  Drawing of primitives (rects, ovals, etc) are no longer off by a pixel (yay!).  When GDIPlus is enabled, Windows apps can now draw anti-aliased.

One of the biggest changes in R4 is that pictures and colors now support alpha channels and allow you to set their translucency.  This is a big deal for any plugin authors that deal with pictures as they will have to rewrite their plugins to check for the alpha channel or lack thereof.  It promises to be a nightmare for them since older versions or Real Studio won’t support it but newer ones will.  Be aware of this change if you rely upon 3rd party plugins that use, return, or otherwise manipulate graphics.

Be aware that the database plugins included in R4 are NOT backwards compatible.  Like many Mac developers I have multiple versions of Real Studio in the same folder so I can have the same plugin set across versions.  If you try to run an older version of Real Studio using the R4 database plugins Real Studio will fail silently.  I expect numerous reports of older versions of Real Studio to suddenly start ‘failing’ because of the change to the plugin format.

I’ve been using R4 since practically the first alpha.  I am converting my training videos to work in Web Edition and I’m fast approaching release.  It wasn’t until this weekend that I found a bug when saving using the version control format.  If you use the WebToolbar and assign icons to a button the changes will not get written out properly <feedback://showreport?report_id=19231>.  This really sucks because I have to go back to binary format – again.  Sadly, Web Edition has been rife with version control format bugs since the very first release and these woes continue.  It is obvious that the RS developers do not use version control format when testing Web Edition features.

Unlike many Real Studio releases, Release 4 is a huge bug fix release (well over 200).  The number of Cocoa changes is significant and developers should start porting and testing their apps in Cocoa.  It is really important for you to do so.  As with many releases there are some changes you might not be able to live with and some changes have been made in the background for future changes.

At the Real Studio Database Days training in Frankfurt Germany in early November, Geoff Perlman, CEO of Real Software, said that 2012 Release 1 would probably be the first release where Cocoa would be enabled by default.  What went unasked was whether or not the IDE itself will be a Cocoa application or not, but I would presume that it will be.  Regardless, the march to full Cocoa support goes on and you should be preparing for it sooner rather than later.

Happy coding!

[Update:  The WebToolbar styles are now in the online Wiki]

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!

• Updating the Real Studio Documentation
• Interacting with customers via email, live chat and social media
• Maintaining & Updating Real Studio example projects
• Creating training videos
• Giving Weekly “Intro to Real Studio” Webinars
• Updating & Maintaining the Real Studio curriculum