BKeeney Briefs

REAL Software announced yesterday that REAL Studio 2010 Release 4 will no longer be actively supporting the PowerPC (PPC) framework.  This really means that only major bug fixes will be done to the PowerPC framework and nothing new will be added to it.

At the 2005 World Wide Developers conference Apple announced the move to Intel and many people were shocked that they would give up the PowerPC line of chips they spent a decade promoting as being better than their Intel counterparts.  Intel was the future and blah, blah, blah.  Many people said the Reality Distortion Field was on full blast.

In retrospect it seems so clear.  One could certainly argue that Apple’s resurgence is, in part, because of their move to Intel.  With a growth rates in the 30% range in year to year quarterly sales growths it’s not very hard to come to that conclusion either.

It’s been five years.  Most consumers have an Intel based Mac and most businesses will probably be phasing them out in the next couple of years if they haven’t already.  On BKeeney.com, only 10% of visitors are running a PPC Mac.  BKeeney Briefs and the ARBP site are both less than 2%.  When 90+% of total visitors to your websites are on Intel it’s safe to say the Intel transition is nearly complete.

The reaction to REAL Software’s announcement has been calm, I think, mainly because no one is shocked by the move.  Most developers are most likely on Intel Macs and I think a vast majority of software buying consumers are on Intel now as well.

Since Cocoa is Intel only and the IDE will eventually be built using Cocoa this presumably means that the IDE will no longer run on PPC machines.  This is probably not a big deal for most REAL Studio developers.

It might be a big deal for developers serving the education market, however.  But since they’ve said they will not remove the PPC build option for several years that market should be relatively safe for the foreseeable future.

Transitions can sometimes be painful.  The fact that Apple pulled off a major transition with very few problems is a testament to their engineering staff.  For companies that feed off of Apple this transition wasn’t always easy and REALbasic had its growing pains.  The transition to Cocoa has been painful but in the long run it will allow REAL Studio to grow with whatever is coming up next for Apple.

What do you think?  Do you still work on a PPC machine to do development?  Do you still serve PPC users?

I ran into a problem with REAL Studio this week that was annoying.  The IDE hard crashed on me and it had tried to save the project (this is a good thing!).  When this happens you get a dialog the next time start REAL Studio that says:

“REAL Studio has found unsaved changes from a previous session.  Would you like to recover these changes?”

However, in this particular case I didn’t care about the changes so it was no big deal.  I clicked No and worked on the project.  Usually you never get the message again but I was every time I restarted REAL Studio.  Again, not a big deal, but it was annoying.

The fix was relatively simple (thanks to RS staff on this one).  On Mac OS X, REAL Studio puts files in the ~User/Library/Application Support/REAL Studio/RB2010 AutoSave Projects/ directory.  Sure enough when I looked in that directory there were some files that shouldn’t have been there.

I simply deleted them, restarted REAL Studio and the problem went away.  Voila!  Hopefully someone else will find this useful.

The official press release will go out soon and will go through the official REAL Software distribution channel but I couldn’t contain my excitement any longer.  It’s almost (but not quite) as exciting as announcing to your friends and family that you’re going to have a baby.

Mark your calendars and start making plans to attend the REAL Studio Summit 2011 in Atlanta, Georgia.  The event takes place on March 19th and 20th, 2011 and is sponsored by the Association of REALbasic Professionals and REAL Software!

We are very pleased that REAL Software is participating.  They will be sending a couple of people and will most likely present a couple of sessions.

Speaking of sessions, the call for speakers will go out soon as well and with the advanced notice I think we’ll get some really great speakers on a variety of topics.  We will be targeting some people in the RB community based on their contributions on the RB Forums and NUG list and we hope to get some commitments soon.

I was always a big fan of the old REAL World events – not because of the sessions (though those were important) but because of the relationships you developed (no pun intended) with other REALbasic developers.  Let’s face it, many of us don’t know another REALbasic developer that lives near us.  I feel lucky that I found six in Kansas City and when I get together with them there’s a kinship that’s hard to explain.  I’m energized about the platform and I get inspiration from them when they tell me what they do with REAL Studio.  To me, that’s what the REAL Studio Summit is all about.

The official conference page is at http://www.arbpmembers.org/real-studio-summit-2011 and the Call for Speakers page is at http://www.arbpmembers.org/real-studio-summit-2011/call-for-speakers.

It’s not too soon to think about 2012.  Pacific Northwest? MidWest?  Europe?  If you have a local group of RB users you might want to start thinking about it and contact me if you’re interested in being the contact team.

Official word from REAL Software about Cocoa.  2010 Release 3 will include the option to build for Cocoa.  Officially this will be labeled as ‘beta’.

I think this will generate a LOT of Feedback reports for them.  Sure, it’s ‘beta’, but will users really take that into account when they start bitching about it not doing something?  I guess only time will tell.

The Serial communications saga continues…. Never say die when it comes to serial communications because, like so many things in programming, there are multiple areas where the problem might lie.

Here are the facts as I knew them this morning.  Given a hardware configuration (serial port to fiber optic converter to fiber optic converter to Serial to USB converter), I could reliably talk to my device in Mac OS X and Windows XP.  In Vista and Windows 7 it failed.  The serial port monitor software that I running in Windows was able to see the messages with 100% accuracy while the RB serial control was not.

Sounds like an RB bug, right?  I submitted it, with video proof, and had a reasonably happy weekend.  The client was not happy, understandably, and after consulting with REAL Software (who, by the way, responded to my email promptly this morning) agreed that it might be a bug and they would be happy to try to reproduce (and ultimately fix it) if we sent them the hardware and a sample program and some money to do it for the R4 release.  R4 will come out sometime this fall, by the way.

The client was not happy about the additional cost and the time delay as you can understandably imagine.  So I said I’d do some research and figure out if other people are having serial issues too before issuing a recommendation to send all the materials to RS.  I’m sure some of you are guessing where this is going.

It just so happens that the specific manufacturer of the Serial to USB Converter (Prolific) has some serious issues with their Windows 7 (and Vista) drivers.  After a few more specific web searches I found an alternative (perhaps older) driver that works fine if you do the following in Windows 7:  Right click on the properties of the installer, select Run as Administrator and select Vista SP2 under the compatibility popup.

Run the installer, restart Windows 7 and Voila!  We now have a fully functioning driver – that works – in Windows 7.

Hindsight, as they say, is always 20/20 and I *should* have thought about this last week.  I had “something in the middle” that I assumed worked.  I had evidence that it did work (the serial port monitor) but my assumption was false (obviously).

Debugging serial communications (and network communications for that matter) is a royal pain in the behind.  When something isn’t working, work the problem backwards.  When there’s hardware involved, verify that the hardware works or try to eliminate the hardware.  In my case, my Windows 7 doesn’t have a true serial port (it’s running on my Mac in VMWare).

So maybe you’ll learn something from my experience and pain.  Maybe you’ll keep yourself from having a bruised forehead (from banging your head up against a brick wall).

Happy coding!

I’ve had one of those weeks where I thought I was going crazy (crazier?).  My cross-platform application that works fine on Mac OS X was behaving very strangely in Windows but only sometimes.  This particular application talks to a hardware via a serial port.  My standard test platform is Windows 7 with Windows XP as the secondary and both of these are run in VMWare on my Mac.  So a bunch of things might be at fault but after trying this out on an old Windows XP laptop I quickly narrowed the problem down.

The data packet the hardware device sends is very small – 4 characters to be exact.  What I was experiencing was that RB captured the first character on the first send – but not the whole packet.  Then it would complete the first message on the 2nd message and only get part of the 2nd message.  It would go something like this:

1. A
2. B | A
3. C | A
4. D | A

Where A is common to all messages so they should be AB, AC, AD and so on.

These messages in the real world are sporadic and with the exception of a regular hardware pass message it might be days or weeks in between messages so as you can imagine, this problem mucks up the logic quite a bit.

If you are not familiar with the Serial control, the DataAvailable event fires when there is data available (duh) and there you can check what’s in the serial buffer by using the LookAhead function.  LookAhead in this case showed just the first character.  The other property to check is  BytesAvailable which should tell you how much is still in the buffer.  It simply returned zero so I should have a complete message.  Definitely something screwy going on there.

Invoking Serial.Poll via timer did not produce any different results.  Neither did forcing a ReadAll.

One other thing that I discovered was the Serial Port Monitors are worth their weight in gold.  Using one, you can at least verify that the data got to the computer.  A free 14 day trial was good enough but if I do any other serial projects it will be worth it.

The good news is that I wasn’t crazy.  The client is okay with Windows XP for now.  The bad news is that it might take a release cycle (or more) to get it fixed. Oh well, battles for another day….

For those that care, the Feedback id is 12723.

Be aware that RB 2010 R2.1 has a nasty Windows-only bug that might affect you.  It seems that the keyboard accessibility for pushbuttons (and possibly other controls) no longer works properly.

To duplicate, put two pushbuttons on a window.  Put a message box in the Action event saying which one has been pushed.

Test it with the mouse.  Works fine.  Now tab to each pushbutton and press the spacebar.  Works fine.

Now, tab to each one and press the Return or Enter key.  Nothing.  If you happen to have a default pushbutton the Enter/Return key will activate that button regardless of where the focus is.

Nasty bug that leads the average Windows user to curse your name in vain if they rely on the keyboard to navigate.  I spent hours trying to figure this one out because it manifests itself in the MessageDialog class too.

Yeah, I’m a little pissed.   I have to revert to RB 2010 R1 where it does not manifest itself.  The hard deadline for the project I’m working on is today.  Gives me a black eye for a problem outside of my control.

For those that care, Feedback ID 12626

I’m a big fan of the Einhugur control suite for REALbasic.  In particular, the Einhugur TreeView, Calendar, Date, and Time controls often find their way into my projects, both internally and for consulting projects.  The StyleGrid also gets some consideration for many projects as well.

A recent post on the Monkeybread Software blog mentions a number of bugs about the ComboBox control.  I agree with Christian’s assessment of the state of the ComboBox control.  I made a comment (currently awaiting moderation) that I thought that a 3rd party could sell a full-featured combobox control.

I’ve mentioned in the past that I would help finance someone to come up with a cross-platform WebKit plugin and, as of yet, no one has made one or approached me taking me up on the offer.  REAL Software has indicated that they’re looking at it.  Given their workload I’m not sure I expect it anytime soon.

I’m also a big fan of the True North Software Formatted Text Control.  I’ve used it in quite a few projects and find it to be a very nice replacement for the the TextArea control.  For now, it’s the best way to get true RTF support in your REALbasic application.  It’s also very extensible so if you need it to do something special you can modify the source to do it (though it might be a lot of work).

Other things I’d like to see:

• A multi-column popupmenu/combobox
• A grid control that supported container controls hosted in individual cells
• A list view that could switch between column (Mac OS X), TreeView, List, and Icon View.

What is on your wish list of controls for REALbasic that are currently not available?  Why isn’t there a bigger market for 3rd party controls?

As you start to code all day, every day, you start to develop your own set of guidelines.  I’d call them rules, but since I break them often enough I have to call them guidelines.  Since I deal with my own code and Other Peoples Code (OPC) on a regular basis here are my guidelines (in no particular order):

• 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?

Earlier in the week I mentioned that I thought the REAL Software beta process is broken.  I’m a passionate user and I use RB all day, every day, so I have some strong opinions.  I happen to know a thing or two about testing on a commercial software product.

Earlier in my software development career I was the lead tester for a printer utility (for a very large printer company).  I was in charge of the test scripts (imagine the same test on 30 printer models for each beta release – yeah it was mind-numbingly dull) that each tester used to report bugs.  We’d find a bug in Test 3.13b (how to reproduce), explain what the error is and sent it to the developer in charge (via the bug tracking system).

The developer would fix it and then the build developer would put together the list of changes for that build and the system would then send the bug back to the original tester for verification.  If it passed our test (with the next build) we told the system that the fix was verified.  If not, it got sent back to the developer.

Then, when the developer made a public release, the fixed and verified bugs were put into the change list.  Depending upon how late in the process we were, verified bugs were listed as known bugs so the public testers didn’t report the same bug a billion times.

It’s a tedious process but it’s the only way to really do a beta program.  If you assume that you really want a quality (good enough?) product you need to slow it down and be tedious about it.

So why do I think that the RS beta program is broken?  First, in this release, several bugs were listed as fixed and were clearly not.  This, to me, says that there is no verification process on fixed bugs, or if there is, it’s not a very stringent one.  I understand how this happens because on small teams everyone is maxed out.

It could also be that the bug, as described, was fixed but it didn’t fix the overall problem.  I could easily see this happening.  The developer has a long list of things to do, looks at the bug report, fixes it, verifies it to his or her satisfaction and marks it as fixed.  This, all without a deeper look at why the bug is occurring.  I understand because it’s happened to me.

I would also posit that that the beta program, as it exists, doesn’t work the way that benefits REALbasic (and us end users) the most.  Bugs are getting introduced into the product.  Bugs aren’t getting fixed.  New features don’t get tested properly and take several releases to get working properly.

The beta program asks members to test each build against their projects.  Here’s the ugly truth:  When you ask me to test ‘everything’, it’s like asking me to test ‘nothing’.  There are a couple of dozen of controls that can be used in millions of different ways.  There are hundreds of REALbasic classes that can be used in an infinite number of ways.  Telling me to test my project against the new version only catches in-your-face, or easily noticeable, bugs.

Yes, there is a change list for each beta version but they never tell the beta list what the changes are per new beta build.  Several developers take the time to parse through this list and then publish what’s changed, but why are the testers doing this and not RS?  They should know what has changed in each release and publish the list based on beta build not just an overall list.

ARBP did a survey late last year asking about the beta program.  Most developers said they did it for early access to the next release.  This is akin to saying, “We are part of the program to make sure it doesn’t muck with my project.”  Sure, they test, but is it what RS really needs?

My recommendations.  Not in any particular order and some are mutually exclusive:

1)  Since the beta program isn’t producing the feedback RS needs/wants early enough, scale back on bug fixes and new features and do more internal testing for each release.

2)  Provide guidance on each beta build as to what to focus testing on.  If the listbox received a lot of work, then say that.  As a beta tester I should focus on the listbox.  With Cocoa receiving a ton of changes for each build, it would be helpful to know what the developer wants tested.

3)  Scrap the program entirely and rebuild it by invitation only.  This ensures quality testers and a good mix of hardware, operating systems, projects types, time commitment, etc.  Perhaps even do groupings of people to focus on different aspects of the product in each build.  Group A does controls in this release while Group B focuses on a framework or whatever and in the next release you reverse it.  It ensures that there are always different people looking at different things.  The key here is having as many eyes looking at as many things as possible.  This gets rid of the tire kickers too that provide no valuable feedback.

4)  Have a single person in charge of the beta and build process.  Give that person the authority to delay a public release if beta feedback is too negative or bugs are found at the last minute.  Don’t push the product out the door “just because”.  If there is a legal commitment (for whatever reason) to release on a certain date, then there must be proper time for the testers to vet out problems.

5)  Enforce a proper feedback loop.  Proper discussion needs to take place, both internally and externally, before major things get worked on.  We, users, have a certain set of expectations about features and when no one gets our expectations on record then we end up being overly disappointed in a feature we can’t/won’t use.  We, the users, are the biggest marketing arm of REAL Software.  Keeping us happy makes for happy reviews and comments in public forums.

6)  Don’t ignore beta feedback by saying we’re not the typical RB user.  Um…yeah, we are.  We care enough about the product to give you our time – for free.  Yes, we’re in it for our own interests but don’t dismiss our thoughts as not being representative.

Thoughts?  What would you change to the beta program, if anything?