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?

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.

My review of REAL Studio 2010 Release 3 is up on the ARBP site.

Bottom line is that Cocoa isn’t ready for prime-time yet (obviously since it’s labeled as BETA), but it is nice to see what they’ve been working on.  I urge you to try it out and report the bugs you find (which shouldn’t be hard to find).  The more reports RS has on Cocoa bugs the better Cocoa will be eventually.

RBScript is still a mystery.  I don’t use it any of my projects and I don’t know of many developers using it.  With a new compiler (LVVM) behind it I expect it to break some projects.  Again, finding and reporting the bugs will help all of us.

Console applications being able to access the graphics classes seems like a recipe for disaster in certain situations.  If you use console apps a lot what is your opinion of this change?

What is your opinion of Cocoa, RBScript and Release 3 in general?  Did I get anything wrong?

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.

The July/August 2010 edition of REALbasic Developer Magazine is out.  This months column title is “Having a Thick Skin: Take the Emotion out of Your Tech Support”.

I talk about the pitfalls of providing tech support when people asking for (or is it demanding!) for tech support aren’t nice.  Email and forums posts are awful mediums for communicating to each other so you have to take the emotion out of the equation.

Do you have any horror stories, tips, or jokes about tech support you’d like to share?

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?

There is a thoughtful blog post from Mattias Sandström on the Association of REALbasic Professionals site.  (Direct Link)

I think it fits in rather well with my post back in May about the REAL Software beta process.  Mattias’ standpoint as a user of a lot of other IDE’s is well taken.  I really like the idea of polling the beta users about the release.  I wish it was possible to ask about every change but I know that’s not feasible but the number of bugs that were marked as fixed but were obviously not in the past couple of releases is insane.  There has to be a better way!

I would agree with Mattias regarding the beta mailing list.  I find it to be waste of time and energy.  I prefer forum style discussions.

Here is my prediction though, if RS tried to switch to the forums:  Instead of using the forum, the RB “old-timers” will insist upon the mailing list because they feel it’s better.  How do I know this?  When RS tried to kill the NUG mailing list a few years ago the “old-timers” threatened to create their own mailing list and many threatened to stop using RB altogether!  In the long run RS backed down and I lost a lot of respect for RS and the RB community as a whole.  They were being held hostage by a very select and vocal group of users.

For the beta program to get better, RS has to do what’s best for RS – not necessarily for us users.  If the beta program isn’t doing what it’s supposed to be doing then it’s time to kill it and start over with testers that can do it right.

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?