BKeeney Software Acquires Developer Products From The PandaWare Company

Lenexa, Kansas, USA (October 16, 2012) — BKeeney Software Inc. has announced that it has acquired two Real Studio developer products from The PandaWare Company including…

– Simple Help Editor: a cross-platform help authoring used by developers of all stripes
– PW Style HTML Field: a set of Real Studio classes for creating HTML email messages, used in several applications built with Real Studio

We are very excited to bring these products to BKeeney Software. These products represent years of work in areas that are fairly unique in the Real Studio world. These products are valued assets for the Real Studio community and we will continue to enhance these products. Dennis Birch, from The PandaWare Company said, “I am happy BKeeney Software has chosen to acquire these products.  They are well known in the Real Studio community and I’m sure they can continue to enhance these products and make them even better in the future.”

The new home for these products can be found at the following URL’s:


For more information visit http://www.bkeeney.com or send email to info@bkeeney.com

Protect Your Most Valuable Asset

If you own a house, most likely you have insurance in the event of a disaster.  You might even have a safe box somewhere in your house to protect your valuable objects and you might even have a safety deposit box at the local bank to protect your most valuable items.  Why do many developers not use a Source Code and Version Control System for their source code? After all, your source code is the most important business asset you have and until you hand it over to the client it’s yours to protect. Even if it’s your personal code, why not protect it?

Real Studio doesn’t make this easy, in my opinion, with their binary (rbp) file format. The binary format is very fast and very portable single file in comparison to the version control (vcp) file format that creates a text file for each object in your project. The binary format, in my opinion, gives users a false sense of security. Bugs happen and hard drives fail.

Version control systems can not read the binary format and track code changes. They check in a binary file as a whole unit regardless of how many Real Studio objects are in it. So it doesn’t matter if the code in Window1 has been changed or not because all that code gets sucked into the server.

In my ideal world I’d love to have a format that works with the source code systems but is also as easy to package up and move around as the binary format. Apple’s bundle format would be ideal but as far as I know there is nothing built-in to Microsoft or Linux distro’s that does this automagically.

Subversion servers (and their like) tracks source code changes down to the line of code. Change the capitalization on an RB keyword in Window1.open event? It’s a change that’s noted in the object file (window1) and even to the line of code. When you check in the changes to the server it knows who did it and assigns a version to it.

We’ve used a variety of systems over the years. Many years ago we used Visual Source Safe, CVS, and we currently use Subversion. There are a lot of developers that are using GitHub with a lot of success. Regardless of what you use I believe you should be using some form of source code and version control system. It’s the smart thing to do as it’s the only safe way to store your source code.

Have you every lost code because you failed to keep a copy of it, deleted it accidentally, your hard drive failed, or your computer was stolen? There’s nothing worse than knowing you had some source code that you can no longer find and use. That’s an asset that you’ve now lost – forever.

I know I’m not the only developer that’s worked on a piece of code for a few hours only to realize that it’s crap and I have to revert to the pristine version (because it’s impossible to undo all the changes you’ve just made). You can do this with the binary format if you are really, really good (or paranoid) about making copies of your project but that’s a lot of work. The source code and version control systems are designed for this!

These systems let me save incremental changes, create snapshot copies of the entire project and even compare files across versions so that I can see exactly what’s changed. With multiple developers on a project this is nice to see who changed what and when. When the developer commits a change we all add a note on what we were working on. This is important for us on large projects.

These systems just aren’t for teams, though. Tracking your individual changes is important because sometimes you’ll just be wrong when you change some code and you’ll have to check out an earlier version. These features are very important on projects and teams of any type of size.

Subversion and GitHub can be done on a local computer (not necessarily a server) and from what I know they are not exceptionally hard to install and setup. We chose a commercial host for a variety of reasons. First, I don’t want to purchase and maintain a server with all of the security nightmares that can come with it – the commercial host keeps up with security issues and we all connect via SSL so we know our code is as safe as our passwords allow.

While we do backups of our important files the commercial host is an offsite backup for us.  They do offsite backups of their servers. I know that if my office were to burn down, get hit by a tornado or flood, I would be down as long as it would for me to get a new computer from the nearest Apple retailer and hook up to our Subversion server. That’s a huge peace of mind for me.

We use a Subversion client that is cross-platform simply to make it easier for training purposes. We use SmartSVN which has versions on Mac OS X, Windows, and Linux. While we spend 99% of our time developing our Real Studio applications on the Mac we occasionally need to compile or debug natively in Windows or Linux. The standard UI across platforms with SmartSVN makes this easy and we do not have to copy files across development environments.

We also use a bug tracking system. Unfortunately our version control and bug tracking aren’t tied together but there are plenty of commercial hosts that have both. We tend to commit based on bug reports or, at a minimum, clusters of bug reports. Have a single bug in a class? That’s one commit with the bug ID noted in the commit report. Have a couple in a set of related classes? That’s one commit with all the bug ID’s noted in the commit. At a glance I can tell what bugs were fixed with each commit.

So regardless of the reasons that appeal to you the most, you should be using some form of source and version control system. Protecting your source code assets should be a part of your practice. If you aren’t protecting your most valuable assets your playing with fire. A disaster on your development computer could put you out of business. Protect your source code and yourself.

What about you?  What do you do to protect your source code?

App Wrapper 2.0.1

I meant to do this a while back but we got so busy with consulting and the Formatted Text Control acquisition that I forgot all about this.  Back in July I did a review of App Wrapper.  Though my review was positive (and I use it almost every week), Sam from Ohanaware contacted me and asked how I wanted it to work from an IDE script.

Voila!  About 2 weeks later they released version 2.0.1 that allowed me to wrap my apps using a PostBuild IDE script.  They added a handy menu item in the View Menu (called ‘Command Line Function’) that gives you the exact text to add to your script.  This is very handy because the path is escaped out if there are any funky characters in folder names.

App Wrapper was good before.  It’s even better now as I have it all automated.  Now I never have to stop what I’m doing to open up another application.

Happy Coding!

Localization in Windows Tip

Real Studio makes it very easy to create localized applications. When you use Dynamic Constants and create strings based on language the application will switch, at runtime, to the proper language. It’s pretty easy and straightforward.

In Windows, the only thing you have to do to set the language to something other than the default language is to change the Date/Time format settings in the control panel in Windows 7 to the language (and variation) of choice. This makes it very easy to test since you can have a different OS language than your apps (even if you can’t read the language).

This week, however, we had a client take our Spanish (and English) localized apps to a country in South America for installation only to find out that their default configuration is to leave everything in English. That meant the apps wouldn’t run in Spanish. I have no idea why they do this, but it certainly wasn’t what my client expected!

Major bummer and we all went into panic mode.  We went through various ideas on how to get work around the situation (and all of them ugly) until we stumbled upon the idea that the en.mo and es.mo files (located in the Resources directory next to the executable) could be swapped. So, we deleted the en.mo file and then renamed the es.mo to en.mo.

Voila! Problem solved. The client is happy, the folks on site are happy, and ultimately that makes me happy. The only minor issue is that the apps won’t run in English without swapping the files around again.

Happy coding!

Has Microsoft Already Lost?

I say this with no malice when I say that Real Studio is a fairly small player (development tools-wise) when compared to Microsoft and Apple.  Those two behemoths have much bigger pockets and drive the development environments on their respective platforms.  It’s also fair to say that each has little interest in supporting the other platform.

Real Studio is a good cross-platform development environment that lets a skilled developer create nice Macintosh OS X and Windows applications using one code base.  Most things ‘just work’ and the language makes it easy to take into account the occasional (and sometimes not occasional) platform specific API calls and differences.  Sometimes the differences are a royal pain but rarely have we been stymied in a project as there always seems to be another option available.  And sometimes the trick is know which things to avoid when working on cross-platform apps.

When I started doing Real Studio consulting a decade ago most of the clients who found us were hard-core Apple users.  They had to satisfy their corporate bosses by developing mainly for Windows and if they could get a Mac OS X version as a side benefit that was great.  For the past couple of years it seemed that the clients who contacted us were the corporate IT folks that had legacy Visual Basic projects and didn’t want to convert to .NET (and yes, the boss wanted a Mac version too).

In the past year, however, we’ve been contacted – a lot – by clients invested in .NET and needing a Mac version.  This isn’t just for their internal business apps either – they’re talking about commercial applications.  What’s even more interesting is the number of calls we’ve fielded by existing .NET development shops needing help.

So it begs the question:  Has Microsoft lost the battle of mindshare?  Has Apple now wedged their way into consumer and corporate America to the point where not having a Mac version of your software is a detriment to marketing and sales?

Don’t get me wrong.  Microsoft isn’t going away any time soon, but I can remember a time when if you mentioned Apple (or any non-Microsoft technology for that matter) you were derided for your obvious stupidity.  I can’t tell you how many times I was laughed at for being an Apple developer.  Now, it’s hard(er) to find diehard 100% Microsoft-only IT person.

I decided to write this post after yet another phone call with a .NET developer.  They want Mac versions and they’ve already decided on Real Studio.  But, and this is always the catch, they’re good at .NET and know next to nothing about Real Studio and nothing about Mac development.

That’s where consultants like us come in as we can help bridge the gap in knowledge.  If you’re interested, we have 36 hours of training video’s (over 100 individual videos) available to subscribers at http://www.bkeeney.com/RealStudioTraining/realstudiotraining.cgi including several projects that start from scratch.  I’ve had experience Real Studio developers tell me they’ve learned a few things even by watching the 6 hours of non-subscription video.  Perhaps your .NET developers would get something out of the training?  Perhaps some one-on-one training would helpful?  Contact me – we can help.

I digress (sorry for the shameless plugs).  Have you Real Studio developers been seeing similar trends?  Does .NET seem to be losing its luster?

Sept/Oct 2012 Issue of Real Studio Developer

The September/October 2012 (10.6) issue of Real Studio developer Magazine hit the newsstands (email inbox?) today.  Marc Zeedar tells us how to get our Real Studio applications ready for Retina based Macs.  He also has an article telling us how to get our Real Studio apps ready for Mountain Lions’ new GateKeeper security.

JC Cruz has an interesting article on text searching.  He includes a number of algorithms that you might find useful in your own applications.

In my regular BKeeney Briefs column I talk about the blood, sweat, and tears to become an olympic style programmer.  I give away my four secrets to my success.

I also have a review of App Wrapper and RB Package Maker similar to what I did a few months ago.  This fits nicely in with Marc’s GateKeeper column as you can use either utility to code sign and sandbox your Mac applications.

All that and much more!

Localization in Real Studio

We have clients all over the world and surprisingly most of them want their apps in English. It’s been kind of an oddity that up until a few months ago we have not had to localize an application. While it’s not hard, there are some things that are just harder than it should be.

Real Studio has some of the tools in place to make the localization process relatively easy with Dynamic Constants. Dynamic Constants let you localize strings per platform and per language. This is handy, for example, with platform differences such as Mac OS X calling it Preferences while Windows apps like to call it Options. Same with File->Quit versus File->Exit menu commands on Mac and Windows respectively.

Once you’ve created the dynamic constant strings you can then export a single Language to Lingua that the linguists can then search for missing strings and provide a translation. Lingua is only a marginally useful utility. Its biggest drawback, in my opinion, is that it only handles one language at a time. It would be way more useful if I could export selected languages from my project and have my translators be able to work on all of them.

In my most recent project I really only had to worry about Spanish so this wasn’t a concern but I could see this being an issue in the future. Of course, this feature might be useful in certain circumstances as I might be sending the Lingua files to multiple people for only the languages they handle. Either way, I only have one option now and it would be nice to have the option.

One of the things that’s missing from Real Studio is the ability to search for missing Dynamic Strings for a particular language. The only way to do this is to check each dynamic constant to see if it has a translation or run the app in the language in question and test, test, test and test some more.

If you’re not disciplined when you start your project and make all strings constants you have to search for strings after the fact. This is a royal pain – especially in large projects. In the project in question I had 30 windows, 86 classes, 28 modules and 30,000+ lines of code. And I had to do this in 2 additional sister projects (the UI was similar but each had slightly different functionality). The thought of searching all that code (3 times no less) didn’t make me happy. There had to be a way of making this easier.

The utility that I ended up using was, in fact, quite useful. Arbed http://www.tempel.org/Arbed/Arbedfrom long time Real Studio developer Thomas Tempelmann, makes this process relatively easy. It will scan your xml or binary project files searching out all strings. You then have the option of putting these strings in a global modules or making the constants local to the object. Furthermore, if you tell it to group the constants it will use the same constant for multiple instances of the same string. Be warned however as some words may actually mean different things in different contexts so you might have to break them out later.

Arbed does much more than just dynamic string creation and I highly recommend taking a look at if you are a Real Studio developer. It has a number of features that no other utility has.

Back to the Real Studio IDE. The constants editor is okay for dynamic strings but it’s not exceptionally smooth and like many of the editors in the IDE it’s acts stupidly at times causing me to pause for a moment until it will recognize a mouse click. Ideally, when it comes to dynamic strings in controls, I’d like to somehow have the creation of the dynamic string in the properties list without having to break concentration to go to a separate editor. I also find myself doing a lot of unnecessary copy/pastes.

It would be handy to be able to tell the IDE to make a string property a dynamic constant (using some standardized rules) so make it even easier. Perhaps when Real Studio releases their new IDE interface with its redesigned properties list (it’s no longer a listbox but dynamically generated controls from what little I’ve seen of the UI so far) they’ll somehow make this a reality in a future version.

I’m NOT a normal user of Real Studio. I understand that. This pain isn’t something most users are experiencing. But, the localization process could be simpler and making it simpler makes Real Studio even that much more powerful. Let’s hope they can do something in future versions of Real Studio.

What pains have you experienced localizing a project in Real Studio?

Plugin Management in Real Studio

We tend to have a lot of plugins installed at any given time. We have the full compliment of Einhugur, most of the Monkeybread (MBS) and a handful of others. However, not all projects need that full complement of plugins and the startup time of Real Studio suffers accordingly even on state of the art iMacs with 8 GB of RAM using SSD drives.

We tend to run 2 or 3 versions of Real Studio at a time because not all projects are on the most current IDE nor on the most up to date plugins. This can mean that we have the possibility of mixing plugin versions across our development staff.

Not every version of Real Studio can run all versions of the plugins. You’ll find this to be true in the 2012 R1 release as RS has changed the plugin API so some plugins may not work and cause the IDE to report errors (I believe there’s a workaround but I can’t find the email that contains that info).

The Real Studio IDE does not contain any information on plugin versions. Einhugur plugins contain some version information (which you can see in the Help -> Plugin References menu in you have any Einhugur plugins installed) but otherwise you’re on your own. I have my own person plugin archive that’s separated out by plugin vendor, plugin, and then by version. After talking with my developers we discovered that we all do it this way.

Is there a better way of managing this mess? One of the projects we purchased from True North Software is RBVersioner which holds some promise in helping manage plugins. I spent a few days working with it discovering how it works and I came to the conclusion that it doesn’t do anything for me. And since I’d like to think I’m an average RB user perhaps others would have similar thoughts. Which, of course, made me hesitate to spend a whole lot more time working on it.

So the question I have for you, my Real Studio friends, is do you think plugin management is an issue with Real Studio? In your ideal world (other than the IDE doing the management), what would your perfect utility for plugin management do?

I would love to see a utility where I can create a project ‘set’ and point it to a version of Real Studio (i.e. 2012 R1, 2011 R4.3, 2010 R5.1, etc) and it would be able to pull the plugin versions I’ve selected for that project. I’d love to be able to save any relevant information about any given plugins (min/max versions of Real Studio, targets supported or not supported, dependency information, vendor, release date, etc) and just tell the utility to install the correct plugin set and restart the correct version of Real Studio and automagically open the associated project. I’d also like a report generated for the set that contains Vendor, plugin name and version number so I can give that to my client when I hand project source code over to them. I’m not asking for much, no?

The first question that came to mind after I wrote down all of these ideas was this a solution really in search of a problem? After all I’ve been doing full-time Real Studio development for over ten years and somehow I’ve managed to get manual plugin management to work so far.

Is plugin management a problem for you? Would you spend $10 on a utility to make this easier?

RB Code Reports Version 3.0

Lenexa, KS, USA (August 10, 2012) – BKeeney Software has announced the release of version 3 of RB Code Reports.  RB Code Reports is a utility designed to read Real Studio binary and xml project files and analyze them and report on a number of useful things.  These reports are designed to let developers know of potential issues in their code.

RB Code Reports features the following capabilities:

– A statistics report showing how many lines of code and the code and comment densities

– An optimizations report offering ways to speed up code and avoid hard to maintain code

– A warnings report showing potential problems

– A signature report to document method signatures and to pull comments from methods

– A spelling report to show possible misspellings in control captions and other user interface elements

– A custom report option allowing the user to iterate the project tree and create their own report based on their own criteria


The following features were added in version 3:

– Can now read binary (rbp) project files

– Now recognizes Web Edition objects

– New optimization tests, include heavy use of variants, too many controls on a Window or WebPage

– New warning tests including the ability to check database code for sql operations that do not include a check for database errors, a very common problem with new Real Studio developers

– New signature report options to either pull all comments, or user selectable tagged comments, out of each method

– New user interface

– More preference options

– Automatic application updates


The pricing for this software is $24.95 for new users and $9.95 for existing owners of version 1.x or version 2.x


RB Code Reports can be downloaded from…


For more information visit http://www.bkeeney.com or send email to info@bkeeney.com.


Thoughts on the Formatted Text Control Acquisition

It’s been a busy couple of weeks around BKeeney Software world headquarters.  Besides our normal (read: hectic) Real Studio consulting work we recently acquired the Formatted Text Control (and various and associated  Real Studio projects and products) from True North Software.

There has been some speculation on the reasons why True North Software sold their Real Studio assets and on why we purchased them.  I will attempt to briefly summarize what I know and offer some commentary.

Brendan Murphy, owner of True North Software, told me that the company is moving in a new direction with consumer software.  This doesn’t necessarily preclude using Real Studio, but since he’s focusing exclusively on the Mac App Store he has no need for cross-platform support and therefore Real Studio is not fitting his needs.  xCode might be harder to learn but it has more Cocoa goodies for now and the foreseeable future.  Developer products just don’t fit into his future business model.

I am speculating that the apps that True North Software has released on the Mac App Store are more profitable then developing and maintaining Real Studio controls.  At the end of the day a business needs to have adequate cash flow and income to survive.

People ask me why there aren’t more third party products for Real Studio and there is no one answer but I’ll give several explanations.  The first is that the Real Studio market isn’t as big as .NET or Java or even xCode.  This alone, I feel, prevents many developers from attempting to get into the market as there are only so many people that could buy your product.

The second half of that equation is that even if you do get it to market there is a strong resistance to buying any third party products.  Seriously, go to the forums and you’ll see people bemoaning the fact that Real Studio is missing some (what they consider) key elements and yet they don’t want to purchase plugins or other third party code.  Those are two very big negatives for getting into the market.

The next issue is that Real Software, in my opinion, is not very friendly to third party developers.  You can’t add anything to enhance the IDE except IDE scripts.  Fine, but then they’re not exceptionally friendly to plugin developers for a variety of reasons.  The biggest one is poor documentation on how to create plugins and certainly no guidelines on how to create native cross-platform controls.  The IDE doesn’t manage plugins very well (either in a folder or not when Real Studio is started) and there is absolutely no version control on the plugins.  Projects don’t track which plugins they require so if you’re missing a plugin hopefully you can figure it out.  There is also no way to register and validate third party classes and controls so it’s up to each developer to implement a serial number system.  I don’t know for sure but I suspect that piracy is fairly common in the Real Studio world.

Real Software does throw third party developers a small bone by offering to sell their products in the Real Software web store.  The exposure is nice and it does make it easier for larger corporations to buy products (only 1 purchase order/invoice to get past supervisors) but the percentage take by Real Software for each sale is large.  I’m not allowed to tell you how much – it’s in the contract.  Let’s just say look at my product prices on the Real Software web store and look at them on my own webstore.  But, I digress.

So the incentive was there for True North to exit the Real Studio developer market.  And that’s how we came into the picture.  We’ve used the Formatted Text Control since before the first official release.  I can’t tell you how many commercial consulting projects we’ve used it in and we’ve been into the bowels of the source code offering code back to True North as we came across bugs and when we changed things to make our projects work better for our clients.

We are primarily a Real Studio consulting company and we obviously do more than just consulting.  We recently released our Calendar Control classes for Real Studio that gives developers a nice full-featured calendar like iCal (now Calendar in Mountain Lion) and Outlook.  Formatted Text Control and the Spell Check Utilities plugin fit in nicely in our new Real Studio Developer products category.

If nothing else, we will continue to enhance Formatted Text Control to meet our needs in ongoing and future projects.  Our ideas alone could propel us to several new versions.  We look forward to adding more documentation, example projects, tutorials, videos and the like in the upcoming weeks and months.  If you have features you’d like to see, please feel free to send them to us!

Anyway, I hope that clears up a few things.  It probably creates a few more questions so ask away!