BKS Spell Checker 1.0.2

picBKS_SpellCheckerWe released a new version of our Mac/Windows spell checker plugin today.  Version 1.0.2 works better with foreign language Hunspell dictionaries that are in different encodings.

The Spell Checker plugin has two different spell checking modes.  In the first mode it  works with the native spelling dictionaries on each platform.  On all versions of Mac OS X (that Xojo supports) and Windows 8 and above it uses the built-in spell checker dictionaries.  If you can’t, or don’t want to, use the native dictionaries you can use the Hunspell dictionaries.  There are hundreds of Hunspell dictionaries available for use in a variety of languages and speciality industries.

There is no Linux version at this point due to lack of interest.

More information, including downloadable demo, pricing, and usage is available at http://www.bkeeney.com/allproducts/bks-spell-checker-plugin-for-xojo/

App Wrapper 3 [u]

Xojo makes developing Mac OS X apps very easy but getting those apps ready for distribution can be a daunting task. Apple has had the option for a while to not open applications from unknown developers using a security option that Apple calls Gatekeeper. Gatekeeper, in effect, restricts which apps a user can run on their computer. This theoretically helps protect users from installing malicious applications.

Gatekeeper has 3 settings: Mac App Store that allows only applications downloaded form the Mac App Store. Mac App Store and Identified Developers that allows Mac App Store and applications signed by certified Apple developers. Anywhere that allows any application to be launched. The default in Yosemite, is the 2nd option (Mac App Store and identified developers). Since Apple only recognizes its own developer certificates they have more control over the entire process.

To pass Gatekeeper you need to have a verified Apple Developer Account. Then use Keychain Assistant to request a certificate from Apple through the Apple Developer portal. Setting up this account costs $99 a year and it isn’t too difficult – Apple has some nice instructions for the novice developer to figure this out. However, signing your Xojo app isn’t the most straightforward thing to do, but we’ll get to that in a minute.

If you are trying to distribute your app on the Mac App Store you have to worry about a myriad of things that Xojo doesn’t automatically give you. The first is code signing your application. Other issues include Retina display settings and Retina image sizes, how you interact with the system via the App Sandbox, and if you are using iCloud or other Apple online services, Push Notifications or Game Center.

That’s a ton of stuff to figure out how to add on your own to your project. For several years we had our own postscript build that called a bunch of command line utilities that did the code signing, set the proper plist entries and so on. It was a pain to maintain and move to different projects for a variety of reasons – one of them being that finding out the cause of a script error wasn’t always straightforward!

AW Open

Enter App Wrapper from Ohanaaware. We’ve used App Wrapper 2 for a while and have been extremely happy with it. It takes the guess work out of configuring your Mac OS X distribution because the utility remembers the settings you’ve used for each application. This includes remembering which code signatures to use. Since we create apps for ourselves and for clients this is particularly useful.

App Wrapper 3 has five panels to choose from. The Report tab gives an overview of everything in the application along with reasons why it may be rejected from the Mac App Store. In the example below I’m showing ARGen, our ActiveRecord utility, that is NOT in the Mac App Store. If I did try to submit to the Mac App Store it would be rejected for three reasons: first, it uses the Sparkle framework, and the eSellerate libraries – both of which are rejected by Apple and are unnecessary in Mac App Store applications. The second reasons is that CubeSQL references QuickTime in the plugin (which is surprising since it’s a database plugin).

AW General

The General tab lets you set a number of variables needed by Apple. What’s the Category, minimum Mac OS X that can run the application. The copyright information. The version information, high resolution mode (Retina), which code signature to use, registering an Apple help file, and how the app should be packaged for you (to name the highlights). This is, by far, the panel you’ll need to pay close attention to.

One thing that was less than clear to me when setting up my app in App Wrapper 3 was the About Info credits. In version 2 there was checkbox to include this in the build. In version 3 it gets put into your application. The solution is to simply clear the text field but it’s not obvious. The default text is using my name and information. If I’m creating client builds I will now have to deliberately clear this out before I send to the client. Otherwise, there will be a Credits.rtf file in the Resources directory of the bundle.

For the Mac App Store the code signing certificate will automatically set the Packing for you. For non Mac App Store distribution you have the option of no packing, zip file, or Apple Installer. For us, we distribute via disk image (DMG) so we leave it to none.

The Capabilities panel is all about the App Sandbox and how the app interacts with it. There are a number of things with Sand Boxing that will make your development life a joy. All that fun stuff is beyond the scope of this review but if you’re going to submit to the Mac App Store you should really do some research!

The Info panel is all about setting up the info.plist properly for your app. The top list is what changes App Wrapper will add to the plist and the other sections are for Document Types, URL Aliases, and Uniform Type Identifiers. Some of these are set from Xojo and others are not.

AW Wrapping

The Other panel lets you clean up the application bundle. You can remove subversion remnants, DS_Store files, language files, and whether or not to clean up some of the architecture such as removing any old PowerPC code, or restricting it to Intel 32 bit or 64 bit. You even have the ability to fine tune the files and ignore them, delete them, delete them for the Mac App Store and so on.

To actually wrap your application you have two options. The first is to do it all manually. Drag your built executable on to App Wrapper 3, set it up all up, and simply hit the Wrap button in the upper right corner. You’ll want to do this manually a time or two to make sure there are no major errors.

The second, and probably preferable way, in my opinion, is to hit the Xojo Script button and drag the script file into the Finder and then into your project and put it under the build steps for Mac OS X (supposedly you can go direct from the App Wrapper to the Xojo IDE but I couldn’t get this work). Then it’s just a matter of hitting build in the Xojo IDE. The application is built and the script will use the executable and run App Wrapper in the background. Voila! You have a code signed application that’s ready for upload to it’s final destination (assuming no errors).

In App Wrapper 2 we used the command line option with our own Postbuild script. Version 3 doesn’t appear to allow this so we’ll have to modify our workflow a bit to use it but it doesn’t appear very onerous of a task (at this point). The benefits of using App Wrapper far outweigh the chore of setting it up.

Once your application is wrapped there are a couple of options for testing. The first is to test the application with Quarantine or RB App Checker Lite. Quarantine lets you start an application as if it was downloaded from the internet. This is handy because applications built on your machine are automatically considered ‘safe’. RB App Checker Lite from Rainer Brockerhoff http://brockerhoff.net/RB/index.html lets you verify the certificate and check the entitlement settings before submitting it to the Mac App Store. Both of these tests are useful.

App Wrapper 3 has three purchase options. First is the 30-day Single User “Pay As You Go” option for $9.99 that runs for 30 days but can no longer be used at the end of the 30 days. The 1-Year Single User plan costs $20. The 1-Year Small Team plan costs $199.99 and lets App Wrapper be used by up to 10 developers. Both the Single User and Small Team options have free upgrades for a year after purchase and allow you to use the application even after the time period is up (no usage expiration).

The Pay As You Go option seems very odd. For a mere $20 you can get the Single User plan and can use it forever. I see no advantage in the Pay As You Go option and, to me, is more of a software rental plan.

[Update:] The 1-Year Single User plan is normally $49.99 but is $29.99 until the end of November.  Sorry for the error.

If you haven’t already checked out App Wrapper I recommend that you do. It is by far the easiest way to get your app ready for Gatekeeper and the Mac App Store. Without it, you may spend a lot of time figuring it out on your own. From experience I can say that Apple’s documentation assumes you’re using xCode so figuring it out for Xojo makes it that much harder.  Ohanaware has already done it for you!

For more information on App Wrapper 3 please visit http://www.ohanaware.com/appwrapper/.

Offline Xojo Training with Xojo Trainer

BKeeney Software announces offline Xojo Training Video application.

Xojo developers have had the ability to stream many hours of video from our Xojo Training web app at http://xojo.bkeeney.com/XojoTraining/ for years.  Thousands of Xojo and Real Studio developers have streamed well over 10,000 hours of training video from BKeeney Software.

Now, for the first time, Xojo developers can purchase the videos and watch them on their own computer without an internet connection and with no expiration date. Xojo Trainer is available for Mac OS X and Windows and is shipped on a 32 GB flash drive. The drive comes preloaded with all of the videos and Xojo project files.Xojo Trainer

Xojo Trainer allows users to select training videos by section (matching the online version) and to search videos by keyword.  Videos can be resized to practically any size.

Xojo Trainer comes with two complete desktop projects and one complete web app project.  The projects all start from nothing and Bob shows you how to test and debug the applications.  Of course the complete projects are available for you to peruse and the source code is there for you to use in your own projects!

Pricing and additional information can be found at http://www.bkeeney.com/allproducts/xojo-trainer/

Xojo vs Xamarin

AndroidLast week when I was the guest speaker on Xojo’s webinar on consulting, I fielded a question regarding Xamarin.  The basic gist of the question was if I felt that Xamarin was a threat to Xojo.  At the time I had heard of Xamarin and read a few articles on it but that was about it.  In the week since I’ve been doing more research on the topic.

Xamarin is an interesting development tool.  To sum up what it is in a sentence or two probably does it some injustice but here’s my take.  Xamarin takes the C# language and .NET framework and has ported it to Mac OS X, iOS, and Android.  This allows developers to use the Visual Studio IDE on Windows, and Xamarin Studio users on Mac OS X and Linux to create native Mac OS X, iOS, Android apps, in addition to Windows desktop and Windows Phone apps.

I threw Mac OS X in there since it’s listed on their website but it appears to more of an afterthought since the focus seems to be on mobile applications.  Indeed, their mantra is that they want to make the best development experience for mobile applications.

I am not a C# developer but like most modern languages it’s not the language that’s difficult to learn it’s the framework and .NET is arguably one of the biggest and most advanced frameworks around.  Having the .NET framework available for iOS, Android, and Mac OS X is a huge advantage for anyone already familiar with it.  Theoretically it should make the transition from Windows developer to cross-platform developer very easy.

Xamarin uses native platform user interfaces and compiles to native applications for each supported platform.  This is good in that you get the best of each platform.  The not so good is that it appears that you’ll end up coding each user interface separately (see Xamarin.Forms later on).  I can see the arguments going both ways on this whether this is good or bad.

Unlike Xojo, Xamarin does not have a built-in forms editor.  They give the option of building Cocoa and Cocoa-touch applications strictly via code or by using Apples Interface Builder.  You either stay in Xamarin to build everything via code or you exit to Interface Builder to design your UI.  I can’t imagine that’s very efficient but Interface Builder wasn’t always integrated in Xcode either.  As a developer you have to roll with the punches.

The Xamarin framework has some cross-platform calls to make life easier, but when it comes to iOS and Mac OS coding it appears that most of it is similar to Xojo’s ability to make declares into the native OS.  Again, you might call this a strength as you get the Apple methods but it also means that you’ll need to know each target OS in detail which can be a rather large learning curve.

Xojo abstracts as much of the platform as possible which means that a TextField on Mac OS has mostly the same capabilities as a TextField in Windows and Linux.  The strength in Xojo means that you don’t need to know the details of each platform but it also means that you generally get a compromise in functionality.  This is where system declares can really aid the Xojo developer.

Web Presentation

Xamarin’s website is gorgeous.  Nearly everywhere you go there are very helpful tutorials and videos explaining how to do things.  It’s also laid out in such a way that you can quickly find things.  The Xojo website is okay and relatively easy to find things but Xamarin goes out of their way to convince you to use their development tool.

The tagline on the Xamarin home page is “Create native iOS, Android, Mac and Windows apps in C#.  Join our community of 687,765 developers.”  Practically everything about the website screams, “Use me and you’ll make a great applications!”  It’s very professional looking and it’s all business.

The tagline on the Xojo website reads, “Create powerful multi-platform desktop, web & web-mobile apps.  Fast development.  Easy deployment.”  It’s not that Xojo doesn’t attract professional developers but their emphasis is on different things.

One thing that surprised me quite a bit was under the Support/Consulting Partners menu of the Xamarin website.  It’s a listing of Xamarin consultants and they are listed by tier (authorized or premier), by geographical region, and by expertise.  The Xojo website has the Find a Developer page.  The first says that it’s a serious language with a lot of software development partners and the other says that it’s a smaller community.

IDE Comparison

The Xamarin IDE is fairly simple and seems to be a hybrid between Xojo and Xcode.  Their Solutions pane is not nearly as complex as the Navigator and is far simpler and easier to use, in my opinion.  The Solutions list only shows objects unlike the Xojo Navigator that shows everything (methods, properties, constants, enums, etc) as you drill down into the object.  As you select an object in the Solutions list the source code editor loads all your source code.

If I had a major beef with Xojo is that they try too hard to dumb down the IDE.  You can’t just start typing away like you can in practically every other language/development environment I’ve ever seen.  Instead, you are forced to add methods through the Xojo UI.  You’re forced to do the same thing with properties, events, constants, enums and so on.  While this is great for people just starting out in Xojo it’s a limiting factor for more experienced users and forces you to use the mouse – a lot.  This means you can only see one method at a time unless you open up multiple windows whereas the Xamarin source code editor shows you everything in the source code.  Method definitions are defined via text in the code editor and not by a specific user interface.

Xamarin has the prerequisite autocomplete in the source code editor and appears to be work roughly the same as Xojo’s.  One thing that I REALLY liked about Xamarin was a tool tip showing you what the current parameter was.  As the user types the code editor recognizes where it is and provides a tool tip with a hint on what it’s currently expecting for the parameter.  This was one of my favorite features from VB6 and sadly, Xojo’s source code tip is an antique by comparison.

Xojo has a built-in forms editor.  Not only that but it has a reports editor, menu editor, database editor, as well as specific editors for a bunch of one-off items.  Xamarin shows objects and source code – that’s it.  So this forces you to either build all the UI via code or via an external editor.  While the Xojo editors aren’t perfect they are there and easy to use.

If you purchase the Xamarin Indie subscription (or better) you can use the Xamarin.Forms module which allows you to build iOS, Android, and Windows Phone screens from a single code base and it should speed up development.  However, I think Xamarin faces similar hurdles to Xojo in that a bug in their framework requires a new release so it’s no panacea.  And, you still build the UI via code not through a GUI editor.

Pricing

Xamarin comes with four different subscription options.  The Starter Subscription is free and is good for individual developers and allows you to deploy Android, Windows Phone, and iOS apps to a device and to their respective app stores.  Apps are limited in size and you are forced to use the native UI builders.

The Indie Subscription costs $299 per year, per developer, per platform.  If you were interested in iOS, Android, as well as Mac OS X this would cost $807.30.  Apps are unlimited in size and can use Xamarin.Forms.

The Business subscription costs $999 per year, per platform, and per developer.  This gives you Visual Studio support, “business features”, and email support.  The same Android, iOS, and Mac bundle jumps to $2,697.30.

The Enterprise subscription costs $1899 per year, per platform, and per developer.  This adds Prime Components (pre-built UI assemblies), guaranteed response time of a day, hot fixes, an individual manager, a bunch of support and code troubleshooting options.

Xojo pricing is much simpler by comparison.  $99 for an individual platform license with a $99 1 year renewal.  $299 for all desktop apps (Mac, Windows, Linux) with a $150 1 year renewal.  $399 for web apps (running on Mac, Windows, or Linux computers) with a $200 1 year renewal.  $999 gets the Pro license which gives you all desktop, web, database server, and console/service apps, consulting leads, and beta program access and the 1 year renewal is $500.  The Enterprise license at $1,999 is everything as Pro with an additional day of custom training and the 1 year renewal is $1,999.  All of the licenses are for a single developer.

Xojo is considerably less expensive but the Xamarin pricing is inline with what professional developer organizations are used to paying for their tools.

Conclusions

If I were a C# developer I would be all over this product – especially if I wanted to my apps running on non-Microsoft computers and devices.  I believe this is where many of the nearly three quarters of a million developers are coming from.  I’m sure there are plenty of other developers that were tired of developing their mobile apps on one or possibly even three separate development tools too.  Xamarin makes the development process easier  by using a single tool.

Xamarin is really pushing mobile app development.  Based on the forum activity I suspect that Mac OS X isn’t in the limelight but because iOS is so similar I can see why it was added.  It’s another notch in the capabilities checklist for a growing tool and user base.  If you can do all of your development with one tool why wouldn’t you?

Xojo really isn’t competing in the same space as it’s for only desktop and web applications (an iOS version is currently in alpha testing and should be released this year).  Xojo has been doing cross platform desktop and console applications for nearly two decades and has transitioned through 68k, PPC, and Carbon to Cocoa on the Apple side as well as all the Windows and Linux variants and versions.  Web apps are relatively new but the framework is very much the same as the desktop side.

From what little we’ve seen of the iOS version (remember that it’s in alpha testing right now) it has a built-in forms editor and uses pretty much the same framework as the desktop and web (with specific differences, of course).  It promises to make developing for iOS extremely easy.  However, Xojo has no current plans to support Android or Windows phone.  This might be the one key difference that might make Xarmarin an attractive development environment for many.

Will this consulting company be switching from Xojo to Xamarin anytime soon?  No.  The cost of migrating to a new tool, retraining, and getting involved with consulting in a new environment is considerable.  If Xojo went away tomorrow I know which tool I’d look at first.

BKS Spell Checker Plugin for Xojo

BKeeney Software is proud to announce a new Xojo plugin that allows Mac OS X and Windows developers a simple and easy way to add spell checking to their Xojo applications.  This plugin allows Macintosh OS X and Windows 8 applications to access the native OS spell checker, or to use the popular Hunspell spell checker.  All versions of Macintosh OS X and Windows can opt to use the Hunspell spell checker.
The system spell checker uses the OS language by default but can also be overridden via code to use any dictionary installed on the OS.  The Hunspell spell checker is used by many popular open source applications and may use many of the free dictionaries available.
Version 1.0 is for Mac OS X and Windows only.  Linux support may be added in the future depending upon user demand.
Pricing and Availability:
The BKS Spell Checker plugin is priced at $100 for unlimited use and 1 year of free updates.
For more information visit:

2014 Training Day Early Registration Price Ends Next Week

Bob KeeneyThe early bird pricing for our 2014 Xojo Training Day ends on December 31st.  Save $200 off full price for our full day of training.

Join us in Las Vegas, Nevada on Tuesday March 25th (the day before the Xojo Developer Conference), at the Monte Carlo Hotel and Resort, as the BKeeney Software staff walk you through creating desktop and web applications using Xojo.  This is a great opportunity to ask questions about your own projects and project needs.  Join the BKeeney Software staff as we share our experience using Xojo (and Real Studio) for the past thirteen years.

More information can be found at https://www.bkeeney.com/xojo-training-2014/.  More information on the Xojo Developer Conference can be found at http://www.xojo.com/xdc/

Place a sure bet with BKeeney Software.  See you in Vegas!

Formatted Text Control 3.1.1

We released a new version of the Formatted Text Control today.  Version 3.1.1 is a general release after a long beta period.  This version finalizes the special key handling required by the new Text Input Canvas plugin as well as fixes a host of smaller issues that popped up because of using the new plugin.

For those that aren’t familiar with the Text Input Canvas, it’s the only way for canvas based controls to get the proper key input from the operating system in Cocoa applications.  In Carbon applications Apple Text Services from the Mac OS provided a lot of extra information but in Cocoa that information is only available to text handling controls.  Canvas based controls do not get that benefit so Xojo had to create and provide a plugin to do that.  With the plugin, special characters now input properly (such as é, ü, ç) as well as all of the odd keyboard handling key combinations (shift up/down/right/left arrows) now work.

FTC works in Xojo applications built for Mac OS X (Cocoa) and Windows.  Some users have gotten it to work in Linux but it is unsupported.  Version 3.0 and above work only in Xojo.  Real Studio developers should stick with version 2.

Version 3.1.1 is a free update to any version 3.x license owners.  An email going out from the FileShare system should already be in your inbox telling you about the new versions.

The Formatted Text Control costs $150 and comes with full unencrypted source code upon purchase.  Version 3 is a paid upgrade to version 1.x and 2.x version owners.  If you do not already have an upgrade coupon please contact BKeeney Software support.

More information regarding the Formatted Text Control may be found at http://www.bkeeney.com/formatted-text-control/

 

The New Xojo Framework

Xojo, Inc. has talked a lot at XDC (Xojo Developers Conference) about their new upcoming framework.  The reasons for a new framework are many and valid.  Among them are consistency, a need to serve desktop, web, and soon to be iOS applications, and to remove archaic methods.

This sounds kind of scary because most of us have been using the existing framework for many years.  But in reality I don’t think this is a bad thing.  How many times have you been bitten by framework calls that are one-based rather than zero-based to name just a few.  The new framework promises to make everything consistent across the entire Xojo universe.  All arrays/lists will be zero-based and methods are more explicit in their naming.

Furthermore, UI controls will become portable between desktop, web, and iOS.  In the current framework a desktop button is not portable to web button and visa versa.  While this isn’t too horrible, it makes life a bit more difficult as you have to create new instances and then copy the code from the events from one to the other.  The new framework means that a button is a button is a button regardless of platform.  There will be SOME differences as there are some platform specific controls (iOS has views, splits, tab bar, etc) that have no equivalent on the other platforms.

The Xojo framework has several main modules:  Core, UI, iOS, String, Color, Number, Math, Media and a few others.  They’ve also added a number of common interface elements that I suspect will become a very big part of the framework.  The Core framework has common items like Dictionary, Point, Rect that will be used by other parts of the framework.  In today’s framework you would create a Dictionary object like:

dim d as new Dictionary

In Xojo it would become:

dim d as new xojo.core.dictionary

Not a huge difference but enough that I’m sure will tick some people off.  But what this gives you are new methods that are unique to the Xojo framework that are very useful like ValueOfKey and RemoveByKey.  Not that those do anything different than Value and Remove in the existing framework but they are more explicit in their use.

Strings are another change in that strings now are zero-based to become consistent across the entire Xojo universe.  But otherwise most functions are part of the Xojo.String module.  All the usual suspects are there but new functions that are more explicit are also available.

The new framework is a requirement for iOS.  When it ships it will NOT be able to use the old framework.  Shortly after the iOS release it will be released for Web and then shortly after that for desktop.

The good news is that the old framework and the new framework can be used simultaneously (exception iOS) for years to come so it probably won’t mean much to anyone for a while.  When I asked Xojo, Inc. when they’ll drop the legacy framework they really had no answer.  I suspect like many deprecated things from Real Studio it will take a while.  So there’s no need for panic.

The new framework should make life easier for all of us in the long run.  It’s not going to be a quick transition and we won’t be forced to use it.  I’m okay with it because I’m sure there will be a bunch of other things to worry about more.  Welcome to the future.

eSellerate Issues with Real Studio

Even though I’m a consultant, I still believe in the axiom that “Time equals money”. So while I don’t have a problem creating my own solution, if there are existing solutions out there I’ll use them. This is why I have the full suite of Einhugur and MonkeyBread Software plugins (including Chart Directory and DynaPDF) to name a few. I acquired the Formatted Text Control and Simple Help Editor when they became available because they scratch an itch that we have as Real Studio developers and they save me time in one form or another.

One item that seems to come up with regularity in our products and for our clients is licensing and registration. Add in web store functionality and it becomes a can of worms. Not that you can’t do it yourself, but most developers (and clients) are in the business of selling their products, not coming up with solutions for web stores, licensing and registration.

For several years we used a web only solution called phpAudit. It worked okay, but the the software wasn’t designed with desktop applications in mind. We made it work but it wasn’t ideal. For one, it required a web connection to check registration and the only way to purchase was through the web and the only payment option was PayPal. Again, we weren’t unhappy with that solution. Heck, several of our clients still use it and are happy with it.

We made the switch to eSellerate for our own products a few years back. It’s a decent solution with a web store solution AND an integrated store so users never have to leave your app to purchase the software. It can accept payment from credit cards in addition to PayPal and several other forms of payment.

It has an offline mode where you can still activate the software even if the end user machine doesn’t have an active internet connection. This came in handy when someone purchased our software while on a ship traveling the South Pacific.

I have had many conversations over the years with people who despise third party solutions like eSellerate because if their service gets broken/hacked then their apps get broken too. This has happened at least once in eSellerate’s history but not recently. While I can’t disagree with their reasoning I find it amusing that they’ve spent an inordinate amount of time trying to come up with their own unique licensing/registration solution. Remember my opening statement about time equals money?

eSellerate requires a plugin for Real Studio and it works on Macintosh and Windows. Until recently there have been zero issues using this plugin. The switch to Cocoa took eSellerate a while to come up with a solution (that you have to ask Support to get, by the way) but that’s okay since Real Software’s Cocoa solution has been in beta for a while.

In Real Studio 2012 Release 1 the plugin API was changed slightly to make applications a bit safer. Until then it was possible for a plugin developer to do some unsafe things and this might have caused instability and hard crash issues. Many plugins worked just fine in this transition but the eSellerate plugin was one of the casualties. Ironically, the Macintosh (Carbon and Cocoa) version works fine but the Windows side of things crashes the application when certain plugin calls are made.

I know there are others who have reported the issue as well, but I first reported it in October of 2012. Since then I have received several updates from them with this being the latest:

I’m afraid I have some bad news.  As you know, we’ve lately had an engineer working on a daily basis to try and resolve the issue with Windows apps crashing if compiled with REALStudio 2012.  The folks at Real Software had been awaiting the results of our engineer’s investigation to try and troubleshoot further.

Unfortunately, as of last week, our engineer who had been working diligently on this case is no longer available.  I’ve taken this matter up with my manager, the director of eSellerate, and she has escalated it above her as well, trying to get some dedicated engineering resources to get this taken care of.  However, it doesn’t appear that we’re going to be able to continue the investigation in the immediate future.  We’re not sure when we may be able to resolve this.

We do understand how important this is for your continued integration with eSellerate, and we sincerely apologize for the trouble.  I’m very sorry I don’t have better news for you.  If it might be possible for you to integrate with a 2011 version of REALStudio, that might be your best bet for the time being.

This is not good news and their proposed solution is less than ideal. As the 2013 release nears completion this issue will continue to grow. Eventually Cocoa will be the defacto build for Macintosh and there will be features in Real Studio that can NOT be reverted to 2012 R2.1.

Because we’ve developed plugins for Real Studio I offered our services to eSellerate. I also contacted Geoff Perlman, CEO of Real Software, to see if they could help. RS has also offered to fix the plugin for eSellerate. So far neither RS or I have received any additional feedback.

So now I’m stuck between a rock and hard place. I can assume that eSellerate will fix their plugin but I’m currently advising one client NOT to do so. What’s the point of converting their entire user base over to eSellerate if they’re going to abandon the Real Studio market. Now, I’m not suggesting that they are, but it’s been four months and they don’t appear to be any closer to fixing this bug then they were in October of 2012.

If I go with my motto that time equals money what are the other solutions out there that handle payment, licensing, and registration in one package with Real Studio applications? I know of Kagi and FastSpring that are being used by some Real Studio developers. What are you using?  I’ll look at just about anything.

Mountain Lion and Saving Real Studio Projects

We noticed a very disturbing thing over the past couple of weeks in a couple of different Real Studio projects.  Occasionally, we find that changes to code are not getting saved to disk despite what the IDE.

In both instances we had things in the code editor not get saved.  The sequence was this:

  • Open up code editor.
  • Make changes (dirty flag goes on).
  • Save (dirty flag goes off).
  • Close project and then open it back up.
  • Code changes are not saved.

There is a thread on the Real Studio NUG http://www.realsoftware.com/listarchives/realbasic-nug/2013-01/msg00188.html about this very issue and it appears that it might be a Mountain Lion issue.  I wouldn’t necessarily disagree, EXCEPT that I was using Mountain Lion with Real Studio 2012 Release 1 with Mountain Lion and never noticed this issue.  As someone working on projects all day long and using version control format I think I would have noticed it before R2.

Movie of our code loss:

RBCodeLoss

For us the problem seems to occur when using the VCP project format in 2012 Release 2.  That might be spurious data as we use VCP for practically everything and most of our projects are running in R2.  This has happened in both desktop and Web Edition projects.  Only 1 of these projects is being actively used by multiple people.

In one case I did a Save As over the existing VCP files and it appeared to make everything better and I’ve not seen the issue (in that project) since.  I have not tried using Disk Utility to check permissions and other disk errors.

Is it a pure Mountain Lion issue, is it a Real Studio issue, or a combination thereof?  Regardless, this is a very serious issue that the community needs to help figure out.

Have you seen this issue?  Was it using the binary or VCP file format?  Did you do anything to try and fix it?  What and how did that fix work?

[UPDATE]

As seen in the comments section it appears that Norman from Real Software found the issue we were seeing and has it fixed.  To recap: my bug only manifested itself in 2012 R2 version control format projects.  You had to change source code in the event of a control on a web page and not change any property anywhere else on the page nor any code in any of the methods.  It should be fairly rare to see this bug and we only found it because we hit that exact sequence.

Anyway, good news that it was found and fixed.  I don’t think it’s the same bug as reported in the NUG though it might be distantly related.  Only RS will be able to discover that.