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?

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!

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.

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?

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

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?

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.

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

Geeze.  How many levels of wrong is this rumor?  You think Apple is going to trust Microsoft with the keys to their iPhone/iPad kingdom?  I don’t think so.  Apple has worked too hard building xCode and Cocoa Touch to let a 3rd party develop for iPhone/iPad.  If this does happen, then Apple might as well give Adobe a call and let them know they can restart their iPhone/iPad programs too.  And we all know where that feud isn’t over yet.

Where this might make sense is desktop applications.  Microsoft, while doing all that work to write Microsoft Office for the Mac in Cocoa, wrote their own Cocoa libraries and other Mac GUI editors and put it into Visual Studio.  Seems like an awful lot of work with minimal gain for Microsoft unless they’ve decided to make a push in REAL Software’s corner.  They certainly have the knowledge and resources to do such a product.

While I don’t think this rumor has legs it does make you think.  No doubt Microsoft is feeling the pinch of developers learning Cocoa which does nothing for Microsoft.  If they developed a cross-platform Visual Studio it stems the bleeding because now developers don’t have an either/or decision to make.  Learning a new development tool and frameworks suck and letting all those Windows developers develop for Mac and Windows using their tool keeps Microsoft in the game.  It doesn’t help them with iPhone/iPad development (now) but in five years who knows.  If it does happen it will generate some serious buzz which is something Microsoft wants (needs?).

What does this do, if true, to our favorite development tools company located in Austin?  I don’t think it would be good news.

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?