Namespaces and Encrypted Classes

There’s an unfortunate bug in Xojo (and Real Studio) that decreases the value of namespaces for those of us who sell and provide code to other developers. You currently cannot encrypt a module that contains classes due to a major bug in the IDE. You can encrypt the classes inside of the module in binary and XML formats, but if you do, then you can’t save in version control format.
The main benefit of namespaces is to avoid unintentional clashes with names in code that you don’t own or control. If it was only a matter of our own internal projects we could just change names if and when a clash arises but we’re shipping our code to other people and we can’t reasonably ask them to modify their code if there’s a name conflict.
In Xojo, we have two choices:
  1. Use modules as a namespace. It would be nice if there was better support for this but it works fairly well.
  2. Give our classes long names that have some kind of prefix or suffix (this is the approach taken by Monkeybread Software, which predates namespace support).
We’ve chosen to go with namespaces but that won’t work for encrypted classes. This is unfortunate because the same people who deliver encrypted classes are also the most likely to be creating the sort of project that would benefit from namespaces.
Right now there’s not a good work-around for this. The options are basically to stop using namespaces or tell our customers they can’t use version control format.  Either solution stinks. Not using namespaces eliminates much of the advantages of using them and we would have to name our classes so that conflicts would be rare (if not impossible).  Furthermore, we recommend that all developers use version control so not allowing it for certain licenses would be hypocritical to say the least.
This is an important bug to get fixed.  Please sign on to <feedback://showreport?report_id=28891>

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 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:


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?


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.

Remote Debugger Issue

One of the changes in Real Studio 2012 Release 2 was an improved Remote Debugger Stub.  It compresses the files it’s going to transfer which results in a significantly faster transfer to the remote machine.

I’ve been happy with it until today when I kept getting this error when trying Remote Debug into Windows in VMWare on my machine.

VMware FusionScreenSnapz001


Not a very helpful error message.  This occurred as soon as the first data packet reached the Debugger Stub.

After banging my head of against the wall for about an hour (and starting to panic a bit because of a deadline) I started poking around.  The stub has worked for me, without issue, for years.  Why now?  What changed?  I tried using an older stub, older IDE versions, and all sorts of things.  Since I had the older one, newest one, and even a new beta version I had renamed the folders so I could keep them in one folder.  Last week I consolidated and moved folders around so I could manage them batter.

Have you guessed what the problem is yet?  I finally went to options and that’s where I discovered that the Download Location I was putting the files into no longer existed.  A simple change fixed the error and I was able to use the Remote Debugger in Windows again.

Feedback report <feedback://showreport?report_id=23508> was submitted.  Ideally the Stub should check the location before a debugging session starts or if the location doesn’t exists uses a temporary location.  I suspect this one will get fixed rather soon.

So, there you go.  If you’ve been banging your head up against a wall trying to get Remote Debugging to work, you might want to check the Options/Preferences and see if the Download Location exists.  Hopefully this saves someone, somewhere along way, some time.  Happy Coding!

Beginners Don’t Stay Beginners Very Long

There have always been Real Studio users that have been critical of the company and their products.  I have been known to throw a fit every now and then when I get bit by a bug.  There are currently several users in the Real Software forums that seem to be overly critical of the company these days.  These users go out of their way to hijack threads and tell everyone what a crap product Real Studio is and how Real Software is screwing everyone over.

I get their anger.  I really do.  I’ve been using Real Studio for ten years now working on a commercial products for clients all over the world.  Some of those are private apps, some are vertical market commercial apps and some are mass market  commercial applications.  I have probably been bitten by a bug in nearly every release and on every project.  It sucks but thankfully I’ve been able to find workarounds to most and come up with alternatives to others.

Don’t get me wrong, I’m not happy about bugs.  As a developer dealing with bugs is part of the job.  When I was an electrical engineer I dealt with hardware and software bugs ALL the time.  Try explaining to the client why a 1500 degree furnace stopped working because of bad firmware or why you stopped an automobile assembly line because a PLC glitch  When I was doing Visual Basic 6 development my code was a masterpiece of workarounds.  There is no excuse for bugs but they happen.  It’s part of my job to identify them and work around them.

One Real Studio user sent ME an email explaining how crappy Real Studio is.  It was reasonably intelligent email from someone who felt very passionately about the subject.  It was obvious he had a history of using Real Studio as a consultant.  I disagree with him on most every part of his email but I can sympathize.  Am I becoming to ingrained to ‘just dealing with it’?  I dunno.

Part of the problem, I feel,  is that Real Studio is geared for beginners and hobbyists.  That’s great and it’s how many long time users started.  Beginners don’t stay newbies very long if they stick with the product.  Soon enough they get past the initial learning curve and figure out how to ask the questions they couldn’t even formulate before and this is where the experience sometimes falls apart for many Real Studio users.

It feels sometimes that RS is solely interested in getting new users (and hobbyists at that).  New users are not a bad thing (in fact they are critical to any company).  However, isn’t retaining existing customers even more important?  You’ve already done the hard work in getting them to buy into the platform.  All you have to do is find the way to get them to stick with the product and ideally find ways to get them to upgrade to a higher priced product.

The Personal license is so cheap it’s practically giving it away at $99.  The Professional version is $299 so for every Professional license you have to get three Personals.  The Enterprise Edition is $995 so for every one Enterprise license you need ten Personal licenses.  Now, I don’t know what the renewal rate is among the licenses but I would suspect that Pro and Enterprise users renew more often Personal license users.  I know from a business standpoint my toolset is part of the cost of doing business so why NOT keep upgrading until I no longer use the tool?

My point is that Pro users are valuable and Enterprise users should be the most valued customers.  Instead, many of us feel abandoned for a variety of reasons.  As an Enterprise user I really like being able to use Web Edition, and use the product on all three platforms.    IDE Scripting, Build Automation are nice, but I could live without them.  I use the Profiler maybe once a year so it’s a feature that is wasted on me.  What makes the Enterprise edition worthy being an Enterprise product?  What are the compelling features for people to upgrade to Enterprise?  Not much at this point.

I’ve been doing this for ten years and I’ve been asking for the same things over and over again:  a grid component, a calendar control, date and time controls, less flickering in Windows, and finally reporting.  I lobbied hard for reporting and I feel like a fool for doing so since the reporting tool in Real Studio isn’t what I need (nor can use).  Instead I feel like I got a checkmark on a marketing page.

Granted, there are alternatives to many of the things I mentioned.  That’s not the point.  Instead of giving me the things I could use, today, in selling the product to my clients, I’m getting a new User Interface that will probably have some major bug when introduced that will make it less than ideal to use.  Did I ask for a new UI?  No.  I could think of a dozen things I’d like to see BEFORE a new UI comes down the pike.

So my hope for 2012 is some focus on features that Pro and Enterprise users need.  You can debate all day long on what those features are but the fact no one from RS has ever seriously asked me (or any other pro developer that I know of) what I need.  That says what they are focusing on instead.  Perhaps with some true Enterprise features more people would purchase Enterprise.

Well, but then again, I’m a long time Enterprise user and probably a bigger pain to support than those ten Personal licenses.  Happy coding!

Bugs Are In The Eye of the Beholder

The other day someone on the NUG list posted a somewhat lengthy message on Web Edition bugs. They were asking “why was Web Edition so buggy after a whole year?” Here is my response (mostly the same but with some changes).

Sure, Web Edition has more than its share of bugs. Like all bugs, however, it all depends upon the beholder.  What bug causes the most pain for RS’ is the one that gets fixed first.  I’ve seen a lot of the same things the community has discovered and have just worked around them (where I can).  I was using WE in a commercial project during the first beta ( a year ago) and while we got it to work it wasn’t very good.  That one project probably generated over a hundred feedback reports.  In my opinion WE really hasn’t really been usable until 2011 R3.

Part of the problem, in my opinion, is that RS has NOT created enough Web Edition applications for themselves.  If you don’t thoroughly exercise the framework you just don’t see the things you’d see in a big, complex application (like we are creating).  There is ONE real world example of Web Edition on their website.  While I don’t know how many examples are ‘enough’, I know that one is definitely not enough.

Web Edition exposes the same problems that we all see in Cocoa, Carbon, and in the IDE on a regular basis.  Unless RS experiences the pain it won’t get fixed in a timely manner because it’s not as important to them.  The Reporting editor and generator and the database editor are but two examples of things in the IDE that RS doesn’t use in ANY of their products. It shows because there are gaping wholes in usage that make them unusable for many developers.

RS takes pride in saying they eat their own dog food because they use Real Studio to make Real Studio.  Admirable, but they tend to be on a restricted diet since they don’t eat everything on the menu.  They rarely change the menu’s for the IDE so the Menu Editor hasn’t seen many changes or enhancements.  As far as I know, they don’t use a database in the IDE so I see no reason why they’d be using the database editor on a regular basis.  They don’t do much with StyledText or Movies so its no surprise that those classes are minimalistic (at best).

Since the IDE has no need for date pickers, they have never provided one.  Likewise, the Listbox is good enough for the IDE while we’ve been asking for a more powerful grid component for years.  Full RTF support?  Forget about it because StyledText is good enough for the IDE. A better toolbar control? Well that one’s a bit of a mystery since the IDE is obviously using something different than what they provide to us.

My point is I’m not sure why anyone would be perplexed about long standing bugs.  Sure, they’re painful to you and me (and my clients), but they’re not (as) painful to RS.

Lobbying the community to get Feedback reports higher in the list is about the only way to realistically get a bug fixed. But even that is a crap shoot as there are quite a few bugs (not feature requests) very high on the list that have been there for a long time. So the only thing conclusion that I can come up with is that the bug that all the rest of us are seeing isn’t painful to RS so therefor it isn’t a priority for them.

This is my opinion as a ten year Real Studio consultant.  I know and respect most of the engineers and staff at RS and I think they do a remarkable job.  However, I think as a company they mostly ignore those like me (an Enterprise user that ponies up thousands of dollars per year) and focus, almost exclusively, on the hobbyists (that bring in a hundred dollars a year at best).  If they could make me happy(ier) the hobbyists would come along anyway (see history of Visual Basic).

Bugs happen in every software product. I remember grousing about Visual Basic bugs when I was a big VB6 user. I know that my code back then had plenty of work arounds for bugs in their API. There is no doubt that Microsoft had more developers working on the product (as a whole) than RS has working on Real Studio. There’s also no doubt that VB6 has a considerably larger user base than Real Studio. I feel that this resulted in more workarounds being posted and more alternate solutions.  The reverse is that our smaller community doesn’t have as many solutions and documented workarounds so it feels worse but I feel that it isn’t.

Anyway, that’s enough on my opinions about bugs and such.  Have a good New Year and be safe. Happy coding!

This method or property does not exist.

I find this to be a common problem for new people to Real Studio.  They will try to work with an object and rather than using the instance of a class they use the class name itself.  The resulting error is:

This method or property does not exist.

The first initial response is, “Of course it !$#^ exists!  I just coded it!  Stupid Real Studio.”  I totally understand the reaction because I’ve been there and done that and have the t-shirt to prove it.  It’s frustrating because the compiler message doesn’t really give you the real reason for the error.

The error is misleading but I’m not sure there’s a way for the compiler to come up with a, “You cannot call methods or properties of a base class without an instance,” message.  There are times when you can call a Shared Method or Shared Property of a base class but those are fairly rare (so far) in the Real Studio framework.

It sucks that the IDE code editor auto complete lets you call methods and properties from the base class rather than the instance.  For all of the times that auto complete is good, this is an instance where relying upon it can be a misleading and lead to poor decisions when writing your code.

I also blame the way Real Studio names their controls and classes by default.  Class1, Class2, Button1, Button2, etc are really poor ways to name your objects but that’s the way Real Studio defaults their names.  I would almost prefer a GUID name so it would force developers to come up with meaningful names.  If nothing else, it would certainly help if, when adding a control or class, the first thing to get the focus is the name in the properties list.

This poor default naming conventions is part of the reason why we, at BKeeney Software, name everything we reference in code (and many things we don’t call either).  The names of our classes, controls, methods, and variables are consistent across our three full-time Real Studio consultants so that when one of the other three has to look at code we’re constantly not having to look back at the Window Layout Editor or base class to find out what the object does.

It seems overkill, but we work on about two dozen big projects a year an we’ve been doing this for ten years.  There’s no way that I can remember what I did ten years ago much less six months ago.  So we try to be consistent with how we name things.  You should too because as your project grows there will be portions of your project you won’t see for months and even years.  Why not make life easier for your future self?

Happy Coding!

Container Controls and Properties List


One of the most powerful features in Real Studio is the container control letting you take a complex set of native controls, pictures, canvas objects, etc and put it all in one very neat and compartmentalized object.  They can be used like a normal control and can have custom events, have their own properties, their own logic.  All-in-all, I love these things and use them all the time.

Since they are a control in all practical terms to the developer the properties really should be exposed to the user at design-time in the IDE.  This means that after you create the container and place an instance of it on a window its properties show up in the IDE property list.

In previous versions you used to be able to select a property in the container, right-click on it and select “Property List Behavior” and select those properties you wanted the user to see in the IDE.  This made for reusable controls you could share easily with other developers and they could set their initial values without resorting to writing initializing code in the open event.

But 2011 R2 this is broken (again) even though it has been working (albeit sometimes not consistently in recent versions).  Needless to say, it was a very handy and very convenient feature.  It made making your own custom controls much easier.   There are various reports of this going back to 2008.  Here are few reports:

2008:  <feedback://showreport?report_id=5428>, <feedback://showreport?report_id=5215>, <feedback://showreport?report_id=4313>

2009:  <feedback://showreport?report_id=6356>

All of these reports are either Open or Reviewed status.  Why is it so damn hard for Real Software to get this feature working?  It greatly limits the usefulness of this control.

Look, I realize this is a minor thing so don’t blow it out of proportion, but yeesh, how long do we have to wait to get this fixed and working again?  I just want it to freakin’ work and stay working!

Oh, and just to muddy the waters, I’ve added a new Feedback report  <feedback://showreport?report_id=17551> since it’s obvious that the old reports don’t get much attention.  Feel free to add it to your Top Cases.


WebContainer Different in R2

I noticed another significant change in Web Apps in 2011 R2 this morning while updating another Web Edition video training project.  It appears that WebContainers don’t behave the same as they did in R1 (and earlier).  For some reason, WebImageViews aren’t redrawing properly.  See example URL’s:



I’ve tried a variety of ways to get it to refresh by moving things around in the shown vs the open even to no avail.  This significantly reduces the usefulness of WebContainers.

I have reported this in case 17414 with example project.  Unfortunately it added it as private so you can’t view it.

Web Edition R2 Tip

I updated a good portion of my Web Edition training apps tonight to 2011 R2 and discovered something new (after banging my head up against the wall for several hours).  It seems that in R2, using the Application Identifier property is not only a good idea, but a necessity if you have have multiple web apps running.

What happens if you don’t have the Application Identifier property set?  Your first app will start just fine.  But subsequent apps will fail.  I finally figured that out after looking at my server log and seeing entries like this:

malformed header from script. Bad header=Another instance of com.yourco: myapp, referer:

Once I recompiled the apps with unique app identifiers they loaded no problem.  So the lesson is to make sure you have unique identifiers for all of your Web Edition apps.

Hopefully this saves you some time (and a bit of skin).  And maybe it will solve a mystery for you.

R2 WE Woes Solved

My post yesterday described the issues I was having getting a fairly simple WE app running on my Debian based web server.  The issue appears to have been a Print statement in the App.Open event.  Technically I was calling a method that did both a print and logged it to a local file as well, but the end result is that the print statement itself was the issue.

Once I got rid of the print statement, the app ran fine.  Why this was causing an issue I have no idea as I was doing pretty much the same thing in R1 apps.  Using the print statement elsewhere in the app is also no problem so this bug appears to manifest itself only in the event.

The feedback ID, in case you are interested is <feedback://showreport?report_id=17388>

Hopefully this saves you a little bit of time.