BKeeney Briefs

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?

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.

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