Bugs Are In The Eye of the Beholder

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

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

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

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

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

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

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

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

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

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

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

Google search and Web Edition

If you use Real Studio Web Edition right now the contents of your app are invisible to Google. I think a lot of people are using WE for internal projects or for apps that need a user to log in before anything useful is available. This isn’t a problem for that kind of project but for some web apps it would be nice to have certain areas show up in Google’s search results.

This isn’t just an issue with WE, other AJAX based web apps have the same type of issue and Google has a document that describes how to make AJAX web apps crawlable:

The basic idea is that you have special hash tags for the parts of the your app that should be indexed. When Google sees those it asks your app for snapshot of what the app would look like after the JavaScript has been evaluated.

One approach that Google suggests for getting snapshots is to use something like HtmlUnit. HtmlUnit is a program that acts like a web browser but doesn’t have a user interface. It executes JavaScript just like a browser would and then you can extract the contents of the page.

I did a little bit of experimentation and found that this approach works for simple cases. I ran into a some problems with a real application but they probably have solutions. It seems like the best solution, though, is for WE to support Google’s approach itself. I’ve created a feedback report requesting this as a feature.

If there are parts of your app that could serve as entry points and you want to be able to drive search engine traffic to them, please sign to this report:

Time Waster Feedback Reports

Someone on the beta list asked a good question the other day about things that cost you time when using Real Studio.  It’s a really good topic because some really good ideas come out of the brief discussion.  We were kindly reminded that there was no current beta and the topic is more general so I’m bringing it out into the light of day for those not on the beta list.

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.

MonkeyBread Software Sale and Raffle Quiz

I know a lot of Real Studio developers use the Monkeybread Software plugins.  We use many of the plugins in our projects and consider them to be part of our standard toolbox.  We use the regular plugins, Chart Director, CURL and depending upon the project the DynaPDF plugin.  We also use the Auto Update toolkit.

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.

Real Studio 2011 Release 4 [u]

Real Studio 2011 Release 4 was released this week by Real Software.  This release marks a number of significant changes that might affect how your application behaves so take care when making the decision to upgrade (as you should with all new releases of your development environment).

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.

I find this to be a common problem for new people to Real Studio.  They will try to work with an object and rather than using the instance of a class they use the class name itself.  The resulting error is:

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!