BKeeney Briefs

All of us have a story on how we came to use Real Studio, what we’re doing with it today, and what we plan on using it for in the future.  I thought it would be interesting to get some stories on how I, and others, came to use the product.

For those that don’t know, I didn’t start off as a software developer.  I have a degree in electrical engineering from an engineering school, IIT (Illinois Institute of Technology), in Chicago.  I did take some programming courses (since they were required), but was never into programming.  That might have had something to do with the state of software development at the time since Pascal was the hot language and as engineer we were more concerned with FORTRAN and Assembler.  User Interfaces were pretty bad at the time too.

In school I joined a fraternity and was immediately immersed in the Greek culture.  Our fraternity had a lot of committees and activities that required a fair amount of planning, work and communication.  This led to being placed in the various committees that communicated with parents and alumni, and remember that this was before email and the internet.

As a freshman (IIT allowed freshmen to be Greek), we did all of our newsletters the old fashioned way.  One of our members that worked at the newspaper used the typesetter to create a high res proof, we laid it out, and then we sent it out for printing.  It was a long and rather expensive process.

They did that for years – until the year that I was on the Parents Committee and was in charge of the newsletter.  That year, the upperclassman that had done it was gone and we had no one on the newspaper staff.  Our resource was gone.  After the suitable panic period another upperclassman recommended that I take a look at one of “those” Macintosh computers in the computer lab and take a look at some program called “PageMaker”.

So I did and it was like water to a fish and that started my love affair with the Macintosh.  It won our fraternity some award for newsletter design and it helped pay my way through college as the more I did the better I got at PageMaker, FreeHand, and Persuasion.  I did a ton of work through MacTemps doing miscellaneous stuff and still have friends in the Chicago area because of my Mac work.  And my skills translated into really good looking lab reports that consistently got good grades despite sometimes shaky experimental results.

But, after graduation I entered the engineering work force and was stuck with DOS and eventually Windows.  At home I always had a Mac and was dumbfounded that more people didn’t write software for the Mac because it couldn’t be that hard, right?  So I bought the Inside Mac book series, practically every book written on Mac software development, Think Pascal and then Code Warrior and programmed for fun in Pascal and then C/C++.  During all this time I was the lone Mac user in the engineering wilderness.

Fast forward a bunch of years and I meet my wife, a long-time software developer.  She gives me permission to change careers since during all this time I’m still developing for fun and she’s “hired people with less experience.”  Cool.

At that point I get into Access and Visual Basic programming and really, really enjoy it (despite working in Windows).  Then my son is born and I have the honor to stay home with him.  Literally just a few weeks after I start staying home with him I get contacted by a local company that needs a part-time Code Warrior developer.  Awesome!

Over the next couple of years I do more and more C++ work and one day they call me in for lunch (I was remote worker) and they ask me to do some prototype work for a photo management app they were thinking of developing.  They wanted to do it as quickly as possible so they recommended this product called REALbasic which, at the time was at version 3.5.

I learned REALbasic as quickly as I could and did a quick and dirty prototype for them.  Weeks later though, Apple introduced iPhoto, so my work never went anywhere.  But, it was enough to show me the possibilities of REALbasic.

Over the next year or so I kept using RB for small utilities including one that would eventually become Task Timer.  Task Timer made me money the first week I used it because I was always underestimating the time I spent on my projects.

The CodeWarrior gig ended and I joined the Real Software referral program (still the best way to find Real Studio work, by the way) and started doing REALbasic consulting.  I’ve done that ever since.

REAL Studio (as it’s called now) has come a long way since the version 3.5 days.  It’s gone through a lot of changes.  They now support Windows and Linux in addition to Mac OS X.  Even Mac OS X support has transitioned over the years from Mac Classic and PowerPC support to Universal Binaries and soon Cocoa.

The move to Cocoa has been a long, rough road for Real Software.  I remember sitting through a Cocoa session at one of the REAL World conferences (2007, 2008?) thinking there was no way this was going to fly with the user base because it was simply hackish and way too hard to use.  With the amount of work you had to do to implement Cocoa in your RB app you might as well have learned xCode and Interface Builder.  Thankfully they pulled it and started over.

In 2005 they transitioned from the old code base and User Interface to one that relies upon REALbasic itself.  Some people hated it and some people loved it.  If nothing else, ‘eating their own dog food’ proved to be good in some respects and just as frustrating in others.  At the same time they introduced the Rapid Release Model where every 90 days a new version is released.  The upside is that you can set your calendar to when a new release is going to happen.  Every release brings new features, enhancements, and bug fixes.  The downside is that every 90 days you may discover a critical bug in of those new features, enhancements, or bug fixes.  I know I’ve been bitten by this in the past (as anyone whose read this blog can attest).

Late last year they introduced the Web Edition which was their second attempt at making web applications.  A version codenamed SwordFish was demoed earlier in the decade (2006?) but was never released since Ajax and other web technologies took off about the same time and it was apparent Real Software missed the boat on that one.  Only time will tell if Web Edition is everything they promise it to be.  It’s still very young and has some very annoying limitations as well as difficulties in deployment.

Over the past ten years as a Real Studio consultant I’ve done work in a dozen different industries.  I’ve written accounting, professional athletic training, military strategy, legal utility, movie editors, foreign country election, and credit repair applications and dozens more that I’d have to go look up.  Some of these have been for private use in a single company or individual use, some for Fortune 100 companies, some for entrepreneurs in vertical markets and some for myself.

So that’s where I came from and what I’ve done in the past.  What did you start using Real Studio for?  What version did start with and what do you remember about the ‘old days’?  Was there a transition that was particularly painful to you?

 

At the Atlanta Real Studio Summit a few weeks ago several presenters were showing off beta code or showing code that they had modified earlier in the day.  Of course you know what happened – there were embarrassed developers saying, “I swear, it just worked a minute ago.”  It’s the Law of Demo’s and happens as soon as you use code not thoroughly tested before you show it off, or when you veer from your script.

When I told my son that they violated the Law of Demo’s he replied rather quickly, “Oh, you mean they tried to modify their program the day of the presentation?”  Smart kid, but then we had learned that lesson the hard way during our First Lego League robotics season.  Trust me, there’s nothing worse than your team (full of 9 and 10 years olds) feeling horrible because they didn’t keep a backup and the modified program just doesn’t work.  Lessons learned the hard way are always the best.

The same goes with consulting and contracts.  I’ve recently been in a spat with a client over unpaid invoices.  Because this person was a referral and well known to many in the Real Studio community I made a verbal agreement to do a lot of work for him.  It was a Web Edition project, which was new to me at the time, so I agreed to a lower rate since it was a good way to immerse myself in a new technology.  In general, I thought the project went rather smoothly while using alpha and beta editions of Web Edition.

Normally, all communications are via email and text iChat so I have a record of all conversations.  This client, however, likes to talk via video iChat.  The drawback is that iChat doesn’t automatically save these (there is an option but I didn’t find out about this until I started doing the research).  So now that the project is done, the client is 60+ days past due on his invoices and is *surprised* that he has a large unpaid balance.

How he can say this with multiple invoices being emailed automatically and the multiple emails and phone calls trying to engage him is beyond me.  He now claims there was a spending cap on the project and says he ‘told me this’ early on.  Right, I would have agreed to two days on-site coding (after a months worth of offsite work) for him since those two days alone are higher than his supposed cap.

The funny thing is that after the project was done he still tried to engage me to do more work.  Unfortunately (or maybe fortunately depending upon your viewpoint) the hourly rate he wanted to pay was so low that I couldn’t have made payroll.

The lesson learned is never to do anything verbally when it comes to money.  At a minimum, after a video chat and/or phone call, send an email confirming the details.  The paper trail, while a pain to maintain, is the only way to cover your bases.

A contract is better, of course, because that’s a legally binding document.  The sad thing is that I presented on this very topic at multiple REAL World conferences so that means I obviously didn’t learn my own lesson.  But then I guess I was blinded by the connections this person has with Real Software (not that I hold them responsible) and the community.  The referral was from a trusted colleague too which made it ‘safe’.  When money is involved there is no trust.

As a word of warning, this person is trolling the forums looking for Web Edition coding help.  Make sure you get a signed contract from him before doing any work.  Get everything in writing, which, of course, is good advice for all business dealings.

Will I get what’s owed?  I sure hope so but somehow I doubt it.  Regardless, I’ve relearned a valuable (albeit costly) lesson.

For those of you that use the Version Control Format (VCP) for your Real Studio projects you should be aware that I do not recommend using it for Web Edition projects.  I discovered (and logged) several bugs today in 2011 R1 that will bite you.

The first is subclassing a WebControl in VCP format results in it displaying in the IDE with a black triangle indicating that it doesn’t know what the control is.  Thankfully the control still works, it just looks funny in the IDE and doesn’t seem to affect the final build.

<feedback://showreport?report_id=16518>

The second is that WebStyles do not read properly after saved in VCP format.  This will result in controls not adhering to their styles after the project is loaded again.  This does affect final builds.

In both cases it could be a write or read failure.  Not my job to figure out which one.

If you use Web Edition and version control you should make these bugs part of your priority list.

<Rant>  This is the third release in a row with serious issues with the version control format that keep me from using it.  For my consulting business I need reliable version control.  The only way to do that is to have a rock solid version control format.  It has to work in EVERY release.

Binary format just isn’t acceptable for my business.  I need to track changes on a line by line basis – sometimes my livelihood depends on knowing what changed, and when.

It ‘s obvious, to me anyway, that RS doesn’t use Web Edition internally for anything big, important, or that requires multiple users working with it.  If they did, they would have spotted these problems a long time ago. </Rant>

We now return you to your normally scheduled broadcast.

I was asked this year to be a coach for my sons robotics team through First Lego League (FLL).  It was my honor and privilege to coach these fourth and fifth grade boys.  It is when I see activities like this I feel good about the future of our country as I fully expect each one of these kids to be the future scientists and engineers of our country.

For our school it was our first year in FLL.  We had 4 teams, each with 6 kids.  The season lasts from start of school to until the end of February and for our team we met once a week and for the last month we met twice a week.  All meetings were 90 minutes long.  That is an incredible commitment for coaches, kids and parents.  It spans football, volleyball, soccer, wrestling and basketball seasons (and I’m sure several others).

This years theme was Body Forward and the competition consists of two major components.  The first is the research project where you identify a problem and come up with a solution.  Our team had fun and chose the brain as their topic and our presentation was ‘Zombie Brain Inspectors’ because, as we all know, zombies like BRAINS!

The second part of the competition is where the real fun is.  There is a 4 by 8 foot playing field with a number of field pieces (made out of LEGO’s of course) with tasks (each with their own set of rules for completion) that you have to do in two and half minutes.  You build your robot using the Lego Mindstorms kit and software.  Our robot did well, partly I think, because we went through three major robot designs, and finally settled on a tank design that offered stability, flexibility, and repeatability (things you really want in your robot!).

The LEGO Mindstorms NXT programming software stinks, which is unfortunate, because it has marred an otherwise awesome experience.  It’s written in LabVIEW and while I’ve heard people rave about how good LabVIEW is – our experience was anything but that.

First, getting it to run on Mac OS X 10.5 and 10.6 was difficult (PPC or Intel didn’t seem to matter).  In fact, after trying for a month I gave up on it and went back to an old Dell laptop running Windows XP.  The installers on the CD’s don’t work in those Mac operating systems.  Period.  There’s a hack where you have to copy all of the files to your hard drive, modify one of the installation files and then install from hard disk.  Really!?  Leopard was introduced by Apple in October of 2007.  Simply unacceptable.

Once we did get it installed on my two year old Mac laptop the darn thing never worked right.  The mouse was always jittery and made it next to impossible to select the blocks.  It didn’t seem to matter if they used the built-in trackpad or an external mouse.  My team got so frustrated they all voted to switch to the Dell laptop.

Even once we got onto the Dell, our problems didn’t really go away.  We had permission issues with the help files that required fixing.  We had file corruption issues:  once during one of the practice rumbles!  Because of this we (okay, this one was mine but the boys loved it), “Save As will save your…bacon” and it did after we learned the ‘save as’ lesson the hard way.  Unfortunately, we discovered that saving to a thumb drive didn’t always work.  A file length of zero is a bad thing!  We also discovered that doing a Save As will sometimes rearrange your blocks for you and another coach reported having severe issues copying programming files from one computer to another.  Ya.  Not good.

Once you get into the development environment a couple of things strike you as being odd.  First, everything is a shade of white and grey making it hard on the eyes.  A lot of the really important text, while black, is tiny when it should probably be the most important thing on the screen at the time.  The  User Interface in the environment isn’t Windows, it’s not Mac OS X, heck it’s not even Java it’s some weird thing that I’ve never seen before.  One has to presume that this is the environment that LabVIEW creates.

The whole left to right programming paradigm is odd.  I think you could argue that a top to bottom approach would make more sense and would certainly make it easier to print out.  I don’t have a strong opinion about this as there might be some very good reasons to do it the way they did.  Frankly, making it look like LEGO’s is eye candy and could be left out in my opinion as it adds absolutely no value.

The NXT brick only has 4 input ports and 3 output ports.  Why do I have to specify which port on every block?  Why can’t I just say, somewhere, that Port B is the LEFT motor, Port C is the RIGHT motor, and Port A is the ARM?  Or that Port 1 is the LIGHT sensor, Port 2 TOUCH sensor, etc?  I can’t tell you how many times the kids kept changing the wrong motor or used the wrong sensor because they chose the wrong port.  Why can’t I customize the names of the ports?  That simple change alone would have made life simpler.

The Mindstorms software has the ability to add comments to your code.  It’s less than optimal because you can’t tie it to a block or group of blocks.  So if you make a comment and then insert or remove a block it doesn’t move and I’ll be darned if I can figure out how to move a comment once you’ve created it.  End result is we’ve taught the kids not to bother with comments and I find that to be troubling.

I live and breathe cross-platform software development on a daily basis so I am being very critical.  I can’t tell you how many times I’ve thought about how cool it would be to use Real Studio to develop a better, more modern Mindstorms application.  It would be  a MUCH better experience for kids learning how to program using the LEGO Mindstorms kit.  It would be a native Mac OS X and Windows application with the appropriate installation methods.

Alas, it is but a pipe dream.  FLL requires that the kids use the LEGO Mindstorms software.  I can’t tell you how much money I’ve spent on Lego’s for kids over the years.  You’d think LEGO could come up with some better software for all the money I’ve given them.  The software came out in 2008 and hopefully a new version is in the works.

Now that the season is over I will remember the good things about the season.  I will also try to forget the crappy experience we had with their software.

 

BKeeney Software Inc. announces the release of Spirit is Calling, a daily spiritual journal co-authored by Rev. Chris Michaels and Dr. Edward Viljoen.  Spirit is Calling seeks to grow spirituality by encouraging daily journal entries that allow the user to track their spiritual growth over the course of a year. The journal tracks thoughts and reflections on a daily basis and allows the user to return to previous entries at any time.

Spirit is Calling features a perpetual calendar allowing the user to make use of the journal this year and for years to come. In addition, the program can be scheduled to automatically open every day at a scheduled time. Technical features include a full-featured word processor with spell check and the ability to insert graphics into your journal entries.

Many people find journaling to be very powerful.  It’s a way to get their thoughts and feelings out and into the Universe.  That can be a very liberating experience.  To get the most out of it, it does require some daily attention.  From the book:

Lesson Quote:

Daily practice has an advantage over sporadic practice, in that regular attention to your spiritual life builds up a rhythm in your awareness. This rhythm allows deeper insights to emerge that are not possible with a random program. This journal presents one of many possible devotional activities that you might use to establish a regular, daily rhythm of introspection.

To aid in the process of making it habit we added an autostart preference setting so that at a time of your choosing Spirit Is Calling starts automatically.  In the beginning that can be helpful to get into the habit of journaling.

One of the reasons why I created the electronic version of the journal is that I don’t write by hand much any more.  Writing by hand is very slow and somewhat painful for anything of length.  But I can type 80 words a minute (if I don’t care about the mistakes on the first pass) so having a word processor built-in to the journal (with spell checking) makes sense.

Spirit Is Calling’s home page is at www.bkeeney.com/spirit-is-calling

Direct Download Mac OS X:

www.bkeeney.com/downloads/macintoshdownloads/64-spirit-is-calling-for-mac-os-x/download

Direct Download Windows:

www.bkeeney.com/downloads/windowsdownloads/63-spirit-is-calling-for-windows/download

If you are looking to try something different in your spiritual practice, please try Spirit Is Calling.  Perhaps the journal will help you define your goal and get you out of your daily trivia.

Inspirational Quote:

In the absence of clearly-defined goals, we become strangely loyal to performing daily trivia until ultimately we become enslaved by it. – Robert Heinlein

It’s Thanksgiving week in the United States and it’s traditionally a time where we give thanks for another good year.  This year I’d like to give a big shout-out to REAL Software for REAL Studio.  Thanks, REAL Software!

I’ve been pretty hard on REAL Software the past three or four months.  I’ve been bitten hard by several bugs and I’ve been pretty vocal about it.  As one of the regular commenters noted to a disgruntled user:

As much as we whine and complain, we all have a love/hate relationship with REAL Studio. We love it for its easy-to-use IDE, it’s readable but powerful language, its ability to compile cross-platform apps, etc.

My sentiments exactly!  REAL Studio is incredibly easy to use.  REALbasic, the language, is pretty well thought out.  It gets better with every release which happens every 90 days (sometimes less).

REAL Studio, when you get down to it, doesn’t let you make too many mistakes.  It does everything it can to prevent you from doing something stupid.  It’s a development tool and that’s about as complex a piece of software as you’re going to get and it does it on three platforms (four if you count Cocoa as another platform and five if you count the new Web Edition).  Auto-complete isn’t perfect, but it’s useful in learning the language.  Sure, I wish it had some more powerful features/tools built in to it, but for the most part it’s easy-to-use.

I’ve spent some time in xCode recently and it’s not the same.  It has a tremendous learning curve.  There are settings all over the place and I’m actually quite amazed that Apple, being the user interface experts, have such a crappy IDE.  Auto-complete?  Please.  It’s barely usable unless you know exactly what you want before you start typing.  Granted, I’ve not spent 1,000 hours in xCode but I think it’s safe to say that REAL Studio has a MUCH shorter learning curve.

The REALbasic framework also seems to make much more sense than quite a bit of the Cocoa frameworks.  The RB frameworks are fairly logical and encapsulated rather nicely (there are notable exceptions) but it seems (to a newbie at least) that the Cocoa frameworks are all over the place in terms of logical encapsulation and usability.  I’ve heard enough complaints from .NET developers to wonder if many of the same issues don’t exist there as well.

Could it be that a smaller development group actually makes framework development easier, or at least more coherent?  Very few people (in relative terms) have touched the RB framework over the years than either Cocoa or .NET.  I think this is a good thing because the RB framework is remarkably consistent.

Whether you like the 90 day release cycle or not, it makes REAL Studio predictable.  You know, to within a couple of weeks, when the next version will be out.  This is nice to know.  It’s also nice that RS has release several point releases when the large bugs have been found and reported.

Sure, it drives me nuts that old bugs sometimes reoccur and new bugs were introduced in recent releases.  Sure, I find it hard to believe that new features haven’t been thoroughly documented and vetted before release.  But at the same time I feel that my public bitching and whining (and that’s what it really was) may have gotten the point across that it’s unacceptable for my business.

In the long run, I’m thankful for REAL Studio.  It pays the bills for my family and my employees.  From a consulting standpoint I can create really rich and complex applications for Mac, Windows and Linux with minimal platform specific code.  Is it perfect?  Of course not, but I’ve not found a better environment for me and my clients.

REAL Studio is a Rapid Application Development (RAD) tool.  It takes me days to create a rich application that takes weeks to do in other tools.  Many features are remarkably full-featured and have stood the test of time since they haven’t changed much in the nine years I’ve been using REAL Studio.  The fact that they’ve added some pretty powerful language features, that maybe 10% of the user base will ever use, speaks for how powerful and expandable the language and platform really is.

It’s easy to focus on the negatives, but this week I’m going out of my way to say thanks.  I’m thankful for (in no particular order) awesome clients, a successful business, good health, good friends, an awesome employee, my super wonderful family, and yes, even REAL Software.

I’m thankful for all the hard work that REAL Software has put into REAL Studio.  So thank you to all the men and women of REAL Software.  I wish you much success, happiness and prosperity in the future!

There’s been a lot of chatter about my recent blog posts.  I am not really opposed to the 90 day release cycle – that’s not the problem (and as such the feedback request is poorly titled).  The real problem is the quality of the releases that happen every 90 days.

Each release cycle brings many bug fixes and that’s great, but it also introduces new bugs and changes in functionality.  This happens for new features and for other changes (including refactoring that’s going on for Cocoa).

I realize that there will always be bugs.  It’s next to impossible to ship a product that’s perfect – especially something as big as REAL Studio (that spans three and soon to be, hopefully, four platforms).  But, reporting easy-to-find bugs after the release gives the product an unnecessary black eye.

Part of the problem, I feel, is the beta program.  The mantra has been to test your projects with the beta build and ‘test everything’.  Since my time is valuable, that’s akin to saying “test nothing” because, like REAL Studio itself, my projects are rather large.  It either compiles or it doesn’t and that’s not testing the product, that’s smoke testing (electrical components work on smoke and if you let the smoke out of the component it fails – sorry, electrical engineering joke there).

No one tells the beta program to test “x” feature – we just get a list of bug fixes.  I know I would like something specific to test to get the most out of my time.  Harness the people that have already volunteered their time and effort!

The Feedback system has a lot of bugs and feature requests.  Many of them are very old (they predate this incarnation of feedback system).  Some of them should be closed and some need to be addressed.  Should feedback items older than 6 months get an automatic system vote and then get another vote every 6 months thereafter?  That fact that there are a lot of open bugs is worrisome.  Should bugs and feature requests get the same level of weighting?  Should they have separate areas so that priorities for feature requests are different than those for bugs?

As someone who has spent considerable amount of time and effort trying to reduce Windows flickering I feel I can say that Windows builds right now have some “issues”.  You can say anything you want about the individual controls, I think the issue is with the Window itself.  Put a background image into a window and you might as well put sunglasses on to avoid a headache.  I bring this up because you don’t see this issue in Mac OS X (because the OS double-buffers the window).

Does REAL Software need to spend more time using Studio in Windows?  I dunno, but Windows is not like Mac OS X.  There is quite a bit of inconsistency between platforms.  Some of that is the OS and some of it is REALbasic.  I’m not enough of a Windows expert to offer any hints, but I do know that if I run into problems it will inevitably be on the Windows side (see blog posts on memory leak issues).

I know some people are pretty upset with the new LLVM compiler for RBScript.  It doesn’t work for many causing them to stay with an old version of Studio.  The problem is that the beta program said it was broken and it was released anyway.  Again, I realize that you can’t fix 100% of the bugs before release but when the major users of RBScript are saying it doesn’t work – perhaps it should have been delayed.  Maybe there should have been an option to use the old compiler.  I have no idea how much work that would have been but it would have resulted in more testing and a happier bunch of RBScript users.

So rather than focusing on the 90 day release cycle, let’s focus on the root causes of our unhappiness.

These are just a few of my thoughts.  What do you think?  Did I miss anything major?

Conferences are always a good way to get together like-minded individuals and share ideas and to get energized.  For those folks in Europe, the 2010 REAL Studio Conference is starting today (October 8th) in Koblenz, Germany.  For more information, see http://www.realsoftware.de/realcon2010/

The 2011 REAL Studio Summit is taking place in Atlanta, Georgia on March 19th and 20th.  ARBP announced early bird pricing this week of $250 with discounts available for the ARBP paid memberships.  Early bird pricing will remain in effect until the end of November 2010.  For more information see http://arbpmembers.org/real-studio-summit-2011.

The 2011 Summit is shaping up to be fun and interesting.  REAL Software has committed to three sessions with at least one of them being devoted to the Web Edition which will be relatively new at that point.  Another interesting twist is that one session will be about migrating from Visual FoxPro (yes, it’s still around and very much alive despite Microsoft trying to kill it off) to REAL Studio.  Take a look at the 2011 Summit page for the tentative sessions so far.

The summit will also have the official meeting of ARBP where we will decide upon the future of the organization.  All leadership positions are open and need to be filled.

I’ve already set the intention that I will not remain in a leadership role of ARBP.  If nominated for anything I will respectfully decline.  I helped birth ARBP with the help of a lot of good people and unfortunately we’ve lost a lot of those dedicated people due to various reasons.  Unfortunately, the many responsibilities of the organization have fallen largely on me – especially in the past year.  It’s essentially become a part-time job with no pay and while I love the organization it’s time to move on and it either lives or dies on its own.  Not that I’ll go away, but I can’t sustain the same level of commitment that I have now.

If you are interested in helping out, feel free to send us an email through the ARBP site at http://arbpmembers.org/contact-us

REAL Studio released a point update to REALStudio this week and brought it up to version 3.2.  The only bug fix listed is a Windows-only memory leak that affected various controls.

I know that the leak affects the StaticText control and the timer.  The bug is simple to reproduce:  add a StaticText control and a timer to the window and change the text in the timer.action event.  Run it.  That’s it.

The memory leak memory was so bad that one of my Windows apps was gobbling up tons of RAM to the point where the app was unusable.  Though, to be honest, part of the huge memory leak I was experiencing was the fault of my networking code, but the StaticText and timer leaks weren’t helping matters any.

The bug was big and whether it was my ranting or enough customers complaining about it, RS fixed the leak and issued a 3.2 beta.  Which I tested and the same day logged another memory leak.  The original leaks were fixed but now just by putting window.refresh in the timer event caused a leak in the StaticText control.  I actually logged it improperly because I wasn’t sure where the leak was and speculated on several different possibilities.  The RS engineer in charge of it added a simpler example project into the Feedback report the same afternoon.  So, obviously, they knew about the issue.

And yet, Release 3.2 went out the door with that known memory leak in place.

I’m not sure how I feel about it.  I spent an awful lot of my own time (because I sure as hell can’t charge the client doing all this testing to fix a problem that’s not theirs).  I provided timely feedback (less than 12 hours from the beta release) to test and document the bug and it was released anyway.

R3.2 is better, but it still has a major hole in it that may or may not be acceptable for my Windows builds.  I’m very disappointed that R3.2 saw the light of day since it obviously wasn’t really fixed.  In many ways I feel like this was a “Let’s shut Bob up and give him a new build.”  I know that’s not the case or at least I hope not (not to mention that sounds sort of narcissistic).

I really am starting to question their commitment to the Windows environment given their current workload.  Cocoa is late but is getting closer to reality all the time.  The new Web Edition is generating lots of buzz and even though the Cocoa and Web Edition teams don’t overlap much, the keyword is ‘much’ so it means there is *some* distraction.

It’s been another miserable week of 12 hours days trying to debug my app AND Studio at the same time.  So, yeah, it’s not been a pleasant one.

As a consultant I use the best tools available to me and my clients.  One of those tools is the Formatted Text Control (FTC) from True North Software.  Today they announced version 2 of their excellent text editor control.

FTC is one of those controls that I find indispensable and use a lot because of its power and flexibility.  Because it’s done in 100% unencrypted REALbasic code you have complete control over how you use it.  Need to do something that it doesn’t do?  You can do it yourself if you have the patience for implementing your own changes.

FTC is big and powerful.  It has around a hundred classes that let you implement a full-featured word-processor with very little work (literally drag and drop and maybe add ten lines of code).  With a little bit of elbow-grease it’s very easy to create your own reports via code (perhaps I’ll write a little tutorial on that one of these days).

If you’re interested in learning how a control can be implemented in REALbasic using just a canvas this is excellent code to learn from.  FTC does class inheritance well, is optimized, and the code is easy to follow.

Brendan Murphy, the creator of FTC, is very responsive to bug reports and feature requests.  We’ve been users since the early days of development so you’ll see the BKeeney name in a few places in source code from bug reports and feature requests.  It’s rare to see somebody share the credit so readily.

Version 2 has a number of welcome new features and enhancements.  The first is that the alignment of the display when it’s in Page display mode.  Before it was always flush left, but now you can center and right justify it.  It’s a minor thing, but very high on my own wish list.

New search and replace functionality was added.  You can do it either programmatically or interactively.  There is also a new Replace All function.

You can now scroll to the selection which, as the name suggests, scrolls the display to the current selection (and presumably the insertion point).

A new KeyPress event was added that allows you to have more control over what characters can be inserted to the control.  Since this is an event in the TextField and TextArea controls this is a welcome addition.

A new subclass was created from the FTC.  The FTTextField is a replacement for the RB TextField control and has all of the advantages of the FTC.  This means that the FTTextField can do spell-checking, undo, and the ability to read/write true Rich Text Format (RTF) files where as the RB TextArea is fairly limited in what it can do with RTF (no graphics).

Also new in the FTTextField is the ability to limit the number of characters in the control and the ability to use masks.  Given that the RB mask property in the TextField is bad (perhaps sucks is a better word) this by itself might be worth the purchase price.

The cost of the version 2 of the FTC is $150.  A demo and more information about  version 2 is available at http://www.truenorthsoftware.com/formattedtextcontrol/