Xojo Consulting

When we (Christian Miller of Pariahware and myself) spoke at REAL World 2007 about Xojo (then Real Studio) consulting we had no idea what people wanted.  So we took the generic approach of  lets-throw-everything-we-can-think-of-and-fit-it-into-45-minute presentation.  We were surprised that nearly every seat in the room was filled.  We were off to a decent start.

To make a very long story short, we were pretty happy at the response to the presentation.  What surprised us even more was the Question and Answer session afterward.  There were a lot of really good questions.  One of those questions has come up again and again:  How do you find Xojo Consulting work?  It’s a good question.

In my opinion, the best way to find work is to get the Professional license for Xojo.  Yes, at $995 it is expensive but in addition to the Desktop, Web, Database Access and Console you get access to the Pro-only forum which includes access to Xojo consulting leads.  As a consultant I find myself using all the Pro features eventually so the price doesn’t concern me.  I do realize that not everyone has the same resources that I do.

There is a page on the Xojo website called Find a Consultant where potential clients enter basic details of who they are, how to contact them and a brief synopsis of their project.  That information is then posted in the Pro-Only forum.  In turn, the developers may contact the person who posted the project.

In my opinion, this is like shooting fish in a barrel.  The potential customer already knows (or at least thinks they know) that they want a Xojo developer.  So you don’t have to sell them on Xojo or the advantages of one code base for three platforms for desktop, web, and console apps.  Isn’t that half the battle?

I’ve been part of the program for a a long time (in all its various incarnations and price points).  The quality and quantity of the leads varies considerably but all it takes is one decent sized project to make up your investment. You can find more information about it at https://xojo.com/support/consultants.php.

Most of the clients I’ve obtained from these leads have come back for more work.  This doesn’t happen with every client, naturally, but it happens enough to make a note about it.  In several cases the original job was a small project so the client could see if we were worthy of the project they REALLY wanted to do.  These small projects are good to see if you and the client are compatible (people are people and some just don’t get along).

Other developers have had some luck with finding work on the hire a developer sites like Rent A Coder.  Some of these sites require a fee to bid on the listings.  I would use caution using these sites to find work as your competing against people from all over the world.  Some people can live on $15 an hour (or less).  If you can pay your bills and save for your retirement at that rate then go for it.  I know I can’t!

Bidding on a fixed bid projects is an art form.  I use some basic formulas that call for a certain number of hours for each window/class/control and for really complex windows or classes I break them out separately.  Then if you want to get an idea of how much time you’ll spend on a project multiply your estimate by three.  That will take care of interruptions and waiting for responses for questions, doing research, and all of the things you have to do on a project that you can’t directly bill for.  I know a few developers that use a factor of 5 in doing their estimates.

This might seem a bit excessive but nearly every project I’ve ever worked on (even as an engineer in a previous lifetime) this seems to work reasonably well.  This doesn’t mean that the bid is inflated by three, it just means that I’ve accounted for interruptions and other issues that come up that might cause a delay.  At any given time I’m usually working on three or four separate projects and each one needs attention on a regular basis.

Track the time you spend on each project.  If you can, track the time you spend on each part of the project.  After each project, review how long it took to do the entire project and if you can, track how much each portion of the project took.  After you’ve done it a few times, you’ll find out what takes more time than you anticipated and what takes less.  This is valuable feedback for when you’re first starting out and learning how to do things.

Another thing to keep in mind is that you need to live on what you’ve bid.  If your rate is $15 an hour and you live in New York City I doubt you’ll be living comfortably unless you have six roommates in a two bedroom apartment!  In the long run, what you earn has to take into account your lifestyle, your location, and your ability to set aside enough for your retirement years.

As a consultant if you can bill 30 hours per week that’s awesome!  Most consultants say 20 billable hours per week is good.  Use that as your basis for determining what you should charge.  You’ll need to allow time for dealing with administrative issues, taxes, writing proposals and looking for more work.  Then take into account vacation and sick time (it happens) and what your expenses are and you’ll need some padding because some months will be slower than others.

50 weeks * 20 hours = 1000 hours per year.  You determine that you can making a living if you bring in $80,000 per year.  That means that you need to charge $80 per hour.  $80,000/1000 hours = $80/hour.  Don’t forget that you’ll have to pay your own taxes and insurance so take those things into account!

To be honest we charge significantly more than the $80/hour rate.  This was just an example of how to do some simple math to come up with a consulting rate.  Hopefully your rate leaves you with enough to live on and start saving for retirement.

Where are you finding Xojo work?  Have any fun stories of a client saying no to your rate and then coming back a year later after spending far more than your original estimate?

Look for some posts next week about my experiences at XDC!

How Not to Get Screwed By Clients

Excellent article over at Fast Company that’s a really good read.  http://www.fastcodesign.com/3024819/how-not-to-get-screwed-by-clients?partner=newsletter  I’ll wait for you to come back.

Get it in Writing

Never do any work unless you have it in writing.  If you do happen to be talking via phone or video send an email afterward what you think you heard.  It’s up to the client to tell you differently then.

Don’t do any work without a contract.  You can find some simple contracts over a http://www.docracy.com.

No Spec Work

We get this line a lot, “There’s additional work in the future.  What kind of a price break can we get on this small starter project?”  Really?  You want the discount, now, before we’ve established that we can work together?  Um…no.  Discounts are for when you trust each other and it’s a really big project (as in you don’t have to find additional work).

Upfront payments & never send final work before final money

If you ever have a client tell you that they’ll pay you afterwards just walk away.  Seriously.

I turned down a project a few years back for a lot of reasons but one of them was that my gut was telling me the client seemed ‘slimy’.  For one, he insisted that in his 30 years of working with developers no one had EVER asked him for money upfront.  We said no and he went on his way.  He shopped his project around to a number of other consultants who also turned him down (for similar reasons).

Finally he found a Xojo developer that was just doing consulting for fun (really!) and who didn’t ask for any money up front.  What could go wrong, right?  He agreed to the project (no contract, by the way, but that’s another story) and delivered the project.  Guess what, the client stiffed him.

This developer did the work with no down payment and gave the client the final product before payment.  If he had at least gotten a down payment he would have been compensated a little.  Instead he got nothing.  Make sure you have your bases covered.  And of course with no contract in place the developer has no recourse.

Look for red flags.  Run for the hills

Don’t be afraid to run away from a prospective client.  Trust your instincts.  The linked to article has some good ones (including the This will lead to paid work line).  Some of our red flags:

• No specifications.  It’s common for a client to not have the fine details but when they have zero idea what they want then it’s time to move on (or charge them to write the specifications).

• Worse yet, worthless specifications.  I once had a client give me an 80 page specification document that made zero sense.  We had four people review it and all of us came out scratching our heads.  Funny enough, after meeting with him it was written exactly the way he talked.  Sadly, I should have walked away from that project even though the alarm bells were ringing.

• They fight you over every penny.  I’m not saying that the client shouldn’t be prudent with their money, but if they are professionals looking for professional help they should realize that your time, effort, and experience is not cheap.

• You’re the third or fourth developer they’ve either approached or worked with.  There’s a reason why they keep not finding or losing developers.

There are more red flags but those are a start.  What are some of your red flags with clients?

Last Call for Training Day

The response for our XDC Training Day in Las Vegas hasn’t been as good as we had hoped.  If we don’t get a few more attendees, we will need to cancel the event.  That would really bum us out.

The Training Day is a huge commitment for us since we have our entire staff at the event helping answer questions.  Not only does this include an extra day of lodging and meals it takes away from our consulting business.  As a consultant if we’re not coding we’re not getting paid!  On top of all that, I do a bulk of the preparation and much of the training.  Not only does that take away from my consulting time it takes away product development, writing, and video production of training videos.

This year is a little different too.  Attendees get to help choose the agenda.  We are running out of time available to incorporate agenda changes into the syllabus.

We need a few more attendees or it just isn’t worth it for us.  To entice a few more people we’re rolling back the pricing for another week.  The price remains $350 until Saturday, February 22nd.  Attendees also receive a complimentary three month subscription to our online videos – that’s over 40 hours of video and over 100 Xojo and Real Studio project files you can use in your own code.

We want to see you the day before the Xojo Developer Conference!

More info and to sign up please see http://www.bkeeney.com/xojo-training-2014/

We’ve Acquired the Fireye PDF Classes

Lenexa, Kansas, USA (December 27, 2013) — BKeeney Software Inc. has acquired the Fireye PDF classes for Xojo and Real Studio.

We are very excited to bring the FireEye PDF classes to BKeeney Software.  The PDF classes represent years of quality work and fill a need in the Xojo developer community in regards to the creation of PDF documents.  We will spend some time modernizing the classes to conform with the new requirements for Cocoa and rerelease for sale once we have completed the work.  We also plan on using these PDF classes to enhance our Xojo related developer products, particularly Formatted Text Control and BKeeney Shorts.

Asher Dunn, the original developer of the Fireye PDF classes said, “I am happy that my work was highly valued by the community.  I think Bob and his staff at BKeeney Software will do a great job maintaining and enhancing the PDF classes for years to come.”

All existing customers will receive version 2 for free.  An email will be sent to all registered users with instructions on how to upgrade to the BKeeney version.  Once a new version is released existing customers will be able to upgrade at a discounted price.  At this point, pricing has not been determined.

The new home for the FireEye PDF Classes is at: http://www.bkeeney.com/allproducts/pdf-classes/

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

Visual Basic 6 on Windows 8.1

Not a month goes by where we don’t get a prospective client asking about the possibility of converting their old (but working) VB6 application to Xojo.  They always tell me that their project is working great in Windows 7 and Windows 8.  Then comes the but.  But, they feel that they’re living on borrowed time and it’s only a question on WHEN Microsoft pulls the plug on compatibility not a matter of IF.

Let’s face it.  VB6 Service Pack 6 was released in 1998 and official support ended in 2008.  I think it’s a testament to its power and popularity that developers are still using it five years after support was ended.  It may also be an indictment of how many felt abandoned by Microsoft in the move to .NET.

So the questions I end up answering for many are these:

Can we convert their VB6 application to Xojo?

The answer is generally yes.  I’ve come across few projects that can’t (or shouldn’t) be done in Xojo.  There are some caveats, though, because Xojo is a cross-platform programming tool.

If you’re looking for fancy grids that you rely upon in Windows you’ll be disappointed.  As a cross-platform tool some controls are the least common denominator simply because Mac OS X doesn’t support or encourage the same types of grid components.  Apple encourages simplicity which forces different design considerations.  Linux has differences too that force compromises.

Reporting isn’t nearly as robust in Xojo as in VB6 either.  While it’s true that Xojo has built-in reporting components most developers I know find it too weak for anything beyond simple reports.  There are a number of third party reporting tools (including BKeeney Shorts, our particular solution) but none of them are as easy, mature, and integrated as Crystal Reports.

Can we easily convert their project to Xojo?

This answer is a definite no.  I don’t care what anyone says, running your VB6 project through any of the available converters will not result in good Xojo code.  From experience, you’ll end up spending more time fixing the things that it didn’t convert properly than if you had just started from scratch.  In our opinion it’s much easier to rewrite the application in Xojo rather than convert it.

That’s not saying you can’t reuse major portions of the VB6 code in Xojo but, as a developer, I want to analyze it and choose what I want to port rather than having it bring over everything.  There are a couple of reasons for this.

  • This first is that Xojo is really good at subclassing controls.  VB6 was horrible at it and many developers have extensive classes and modules to work around this fact.  Little to none of the code that’s in those classes and modules is necessary in Xojo.
  • The second is that Xojo is pretty good at threading.  Much of the app.doevents code you’ve had to add in your VB6 project because of tight loops to avoid the UI from freezing you’ll do away with and put into a thread in Xojo.  There are some caveats with threads in Xojo but generally it’s a better way to deal with time consuming operations that might otherwise freeze the user interface.
  • The third is that the VB6 best way to do something may not be the best way to do it in Xojo.  A number of years ago we converted a simulation application from VB6 to Xojo (then called Real Studio).  The project used an insane number of control arrays  with various levels of overlapping controls.  The logic was very convoluted.  Rather than try to duplicate the exact same functionality in the same way in Xojo, we were able to greatly simplify the logic and put everything in simple classes.  The ‘unit’ in the simulation handled all of its own actions and generated events for the UI to respond to.  The UI simply passed the user action into the appropriate class instance.  Everything was encapsulated in the classes and in the long run they could have used the same UI front end for any number of different simulations.  It wasn’t the VB6 way and it took some convincing that it was a better Xojo way.  In the end they were happy with the results with a solution that ran on Windows and Macintosh (and Linux if they had requested it).

Windows 8.1

So why bring all this up?  For some reason a lot of people have hit a previous blog while searching about Windows 8 and VB6 during the past month.  I did some checking and while Microsoft has said Windows 8 would still have VB6 compatibility built-in, some developers have had issues in Windows 8.1  The workarounds seem to be fairly simple, but I think most people still using VB6 are wondering if this will be the last version of Windows that will still have that.  VB6 does work in Windows 8.1 but will this be the last version?  Only Microsoft can answer that but given their stated intentions of doing annual updates like Apple it seems likely at some point they’ll jettison some backwards compatibility.

Also a consideration for many of them is Mac compatibility and to a lesser extent Linux.  Ten years ago the Mac version was an afterthought for many of our clients.  Now, not so much, in that they need a Mac version to satisfy their customers or personnel.  The past couple of desktop projects have actually been Mac first and then Windows.  How times change.

Finding Xojo Developers

I’ll put a plug in for ourselves https://www.bkeeney.com/bkeeneyconsulting/.  We’ve converted dozens of VB6 projects to Xojo.  Contact us if you’d like a quote.  You can even put your application through our VB6 Analyzer (https://www.bkeeney.com/vb2rbconversion/) so we can get some metrics about what all is in your VB6 project.  The beauty of the analyzer is that we never have to see your project to give you a rough estimate of the cost to convert.

You can also request the Xojo Developers Network to get in touch with you.  Simply fill out the request at http://xojo.com/support/consultants.php and Xojo developers will contact you if they’re interested in your project.

Support for VB6 ended a long time ago but based on the number of contacts I get it is certainly not dead yet.

When a License Isn’t a Valid License

I will preface this post with the usual disclaimers:  Not everyone will have this issue nor will it even apply to a vast majority of Xojo developers.  Take it with a grain of salt and if you disagree, that is your prerogative.

This week we had a little lull in the development of one of our bigger consulting projects.  It’s a Web Edition project that has 300+ web pages, 250+ WebContainers, 97,000 lines of code and compiles down to about 43 MB of code.  It’s a monster and we’ve been maintaining it in Real Studio 2012 R21.  This week we decided to upgrade it to Xojo 2013 Release 3.

We have 3 full-time developers and a DBA/QA person who is familiar enough with Xojo programming to fix some of the simple stuff.  We already had 2 Xojo pro licenses and bought a 3rd for our other full time programmer that had been working on this project.  The 4th team member won’t ever compile but will need to be able to save in the version control format that we use on all projects into Subversion.

Being a responsible and conscientious user I read the Xojo End User License Agreement (EULA).  Here is what it says:

• A Xojo License Key is required to save a project in Text or XML formats.

With that fairly plain English we bought a desktop license because it would be the most likely be relevant in the future for our 4th team member (since most of our work is desktop apps).  When our team member applied the license and worked on the Web Edition project every time she tried to save the IDE kept doing a Save As in binary format.  Obviously something was wrong with the licensing.

After checking with Xojo Inc. we discovered that the licensing text was incorrect, or at best misleading.  You need the target specific license key to save a project in Text or XML formats.   In other words, to save in Text or XML for a Web Edition project you need a Web Edition license, to do the same thing for a Desktop project you need a a Desktop license and so on.

For us it was not a huge deal.  We needed it so we bought another Pro license and Xojo Support quickly lupgraded our license.  I understand the reasoning behind it but the fact that I looked it up in the EULA just to make sure says the EULA language needs some additional clarification.  I was pretty mad at the time because it wasted my time and a team members time for a half day while we got it all straightened out.

So be aware of those restrictions when you buy Xojo for your team.

What Pro Developers Need Out of Xojo

I’ve been a REALbasic/Real Studio/Xojo developer since REALbasic version 3.5.  I’ve been through a lot of versions, UI changes, and have made a fairly successful business using the product.  I am a huge supporter of the product and count a lot of the current and former Xojo Inc employees as friends.  I am also a critic in that I always want a better product than what I have right now.  This post is a laundry list of things that we find lacking Xojo.

The first thing that we want is stability in the product.  Xojo 2013 Release 3 is better than the 2 previous releases but we can still get it to create exceptions fairly reliably (yes, we’ve submitted Feedback reports).   Granted, Xojo has not been out for very long but we also had a year long wait from when it was promised to when it was released and we expected more.  For example, Xojo still hasn’t fixed bugs reported years ago in Real Studio.  Autocomplete still doesn’t work properly with shared methods and properties and namespace objects and there are a few other instances where autocomplete just doesn’t work.

The second thing we want from the product are power features (i.e. things that make my life easier).  The debugger, while powerful, is still essentially the same debugger it was when I started using REALbasic many years ago.  Many people want debugger watchpoints, and a better way to view application data while debugging (tooltip variable values are a common request).  Plugin management is a royal pain for developers like us that have projects spanning a decade.  We’d love to have a complete source code view of an object without having to click on each property, method, event, constant, etc.  In my VB6 days I was a huge fan of MZTools which was an add-in for the VB IDE that provided additional functionality that we’d love to have in Xojo.  In other words, we’d love to have the ability to have IDE add-ons.  We’d also like to have the ability to compile applications via the command line and the ability to create libraries and plugins via Xojo itself.

The third thing we need is better RAD tools.  For a tool that claims to be a RAD tool it has a surprising lack of RAD options.  Despite many years of users asking for it there are still no good options for a data grid control.  Sure, many things can be done with the listbox but it’s not quite what users are asking for (think embedded native controls).  The fact that Xojo does not ship with a basic date, time, or calendar control for many is the kiss of death for using the product.  Make them so basic (like Microsoft did) that any power feature has to be satisfied by a 3rd party developer (like Einhugur).

The last thing we need is better database support.  We see no reason why the recordset can’t have an AddNew function.  Why can’t the DatabaseRecord code be merged into the Recordset?  Currently, the classes are close enough in functionality to be easy to figure out but just different enough to be highly annoying (for example, field vs column terminology).  We’d also love to have a Batch Update function with the recordset and the ability to have Disconnected Recordsets.  Both of these features lead to some interesting and powerful database applications.  Another thing that we find lacking is that there are no built-in options to help the user with database operations as there’s zero error checking on table and field names (other than checking the database error property).

These are things that are on our short list and things that we’ve been talking with other developers since about 2008 when we helped found  the Association of REALbasic Professionals (ARBP).  This list does not include 64 bit support, LLVM, or SSL for Web Edition applications because those are already scheduled to be implemented.

Let me be clear, Xojo works for us – we just want it to be better.  We spend an awful lot of money on licenses and going to the developer conferences because this is what we do for a living.  Doing Xojo development pays the salary for all of our employees.  We depend on the tool on a daily basis and even though we think it’s already pretty good, we simply want it to be better.

So what is on your list of things you really want/need in Xojo?

Xojo Licensing Changes

Xojo, Inc. confirmed last week that the licensing for Xojo is changing.  The IDE now costs nothing.  Free.  Zip.  Zilch.  Nada.  Now we all know that it’s awful hard to stay in business by not charging any money, so the catch is that to make a build you need a license.  If you’re building for desktops (Mac, Windows, Linux) you need a desktop license.  Building for Web you’ll need the web license.  Building a console app you’ll need a console license.  The only oddity in the mix is if you’re using database servers which requires an additional license SQLite is included in all licenses).

Now that the IDE is free all users can take advantage of all Xojo features.  Item encryption, server sockets, SSL support, database encryption, remote debugging, container controls, code profiling, IDE scripting and build automation are the big items that were not available to all users depending on what license they had for Real Studio.  This has some advantages for training and getting people to actually use those features.  Everyone has the same set of features and all are available on all supported platforms.

Announced Pricing is this:

Console Licenses $100 ($50 renewal)

Desktop $300 ($150 renewal)

DB Servers $300 ($150 renewal)

Web $400 ($200 renewal)

So what does this mean for those with existing Real Studio licenses?  Real Studio personal licenses automatically get a Xojo Desktop license.  Real Studio Professional get Desktop, Database, and Console licenses for Xojo.  Real Studio Web licenses get converted to Xojo Web and Database.

Real Studio Enterprise licenses now get what’s called Xojo Pro.  Xojo Pro gives you all licenses.  You get desktop, console, web, and database licenses.  It comes with Priority Support which means that Xojo Inc. will handle all Priority Support issues first and then everything else.  Pro licenses also work on three machines (in contrast to the two for other licenses).

Another feature for Xojo Pro is that it gives you guaranteed access to the beta’s.  The Real Studio beta list really had no restrictions.  You signed up and you got access.  They didn’t say this but I suspect this is in response to the many people on the beta list that never reported anything but generated a ton of useless chatter.  This will definitely cut down on that problem.

Some people have taken offense to this.  They are not going to be Xojo Pro users so they feel that they’ll be cut out of the beta list.  The wording in the keynote was very specific.  Xojo Pro gives you ‘guaranteed’ access to the beta list.  That does not mean that you can’t join the beta it just means that it’s up to their discretion.  Those that have contributed in the past will most likely be welcome.  Those that have not are probably out of luck.

Another advantage of getting a Xojo Pro license is access to a Xojo Pro Only forum.  They figure it will most likely be the full-time developers (such as BKeeney Software) that use it.  Honestly, I have a problem with this even though I will most likely have several Pro licenses.  I have been a top 10 poster in the Real Studio forums for many years and I just don’t see how this helps me, or the community.  It seems like it will introduce some stratification into the community where there is none now.  I can’t imagine having an issue that I wouldn’t ask the entire community about.  I could go on about this but it seems to me that it’s a marketing bullet-point to make Pro look better.  I think it’s a bad idea and probably won’t use it.

The final ‘advantage’ of the Pro license is that Feedback cases now get a 3x multiplier. Real Studio licenses are a little different.  I believe Personal licenses get no multiplier, Pro/Web gets 3x and I thought that Enterprise licenses now get a 5x multiplier.  So in this scenario everyone else gets no multiplier but Pro users are the only ones to get it.

The Feedback multiplier isn’t a huge change but it definitely favors the Pro license.  I like this but I have my doubts that it will change anything significant.  As a pro user I have needs that are not being met by Real Studio (and now Xojo) despite many years of blogging and generating feedback reports.  Instead they have consistently gone for marketing bullet-point solutions and solutions that make it easier to sell to beginner and hobbyist developers.

Don’t get me wrong.  The free licensing has the potential to introduce Xojo to a lot of people that would consider themselves hobbyist or part-time developers.  That’s a good thing.  But it’s the folks like me (the Pro’s) that spend serious cash.  I want and need features that a) make my development life easier or b) help make me money (usually in completing things faster).  Not a whole lot of those types of features have been introduced in the past five years.

What do you think about the new licensing and the Xojo Pro features?

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.

Busy Updating Products

I apologize.  Blog posts have been slow lately.  Acquiring products from another company is an interesting process and figuring out the StyledHTMLField and Simple Help Editor was no exception.  First, you have to get in the mind of the original developer and figure out what they were trying to do and then determine if you wish to change the code and then test, test, test.  I can say I am very thankful for source code control because I’ve broken a few (too many) things and had to revert to older code!

One of the things we’re doing with Simple Help Editor is changing the licensing scheme to fit most of BKeeney Software’s other commercial products.  That led me down the proverbial rabbit hole because we discovered that the eSellerate plugin works fine in Carbon and Cocoa (after contacting tech support to get the Cocoa update) but fails in Windows (go figure).  Of course this only happens in Real Studio 2012 R1 and higher so I’m sure it’s simply a plugin compatibility issue and hopefully we can get an update soon (because we’re waiting to release!)

The other thing we decided to do was move to our standard preferences system.  The reasoning was twofold:  First, it now works just like every other of our products so my and my team won’t have to think about what the preferences system does because we know it (and use it everywhere).  The second reason, which was kind of by accident but fortuitous anyway, was that we got to touch code everywhere.  Just by replacing the preferences we go to see a LOT of code we wouldn’t have normally touched.

Just by doing these two seemingly minor items I now have a whole laundry list of items I want to change in Simple Help Editor.  Some of it is personal preference and some of it is features I want for my own products.  It’s also a strong possibility that we’ll integrate the Formatted Text Control into Simple Help Editor to not have to rely upon the RTF to HTML conversion routines and the built-in TextArea control which doesn’t allow any graphics to be shown.  This should make the Simple Help Editor text editors to be a bit more intuitive.  If you are are user of Simple Help Editor and have a feature request then please let me know.  I

Speaking of the Formatted Text Control we’re also working on it too and getting it ready for new features in version 3.  Among the planned features are Retina display support, HTML Export, Hyperlink support, and adding a number of simpler examples that developers can (hopefully) use out of the box without any plugins.

Sometimes I am amazed at how long some things seem to take.  I guess I shouldn’t at this point as I come up with estimates for clients all the time.  When it’s my own stuff it seems to take FOREVER to get done.

Anyway, that’s the current update.  Thanks for you patronage and continued support!