BKeeney Briefs

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:

R1:  http://www.bkeeney.com/apps/WebContainerR1/webcontainerr1.cgi

R2:  http://www.bkeeney.com/apps/WebContainer/webcontainer.cgi

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.

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: http://www.bkeeney.com/realbasic-training-section

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.

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 app.open event.

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

Hopefully this saves you a little bit of time.

I spent all morning on a dirt simple WE web app and for the life of me I can’t get it to run.  I replaced the line of code that I mentioned in a post from last week.  Uploaded the app, verified permissions, and I get nothing but a standard server error message.

In my web server log I get the following error:

malformed header from script. Bad header=App.Open: myapp.cgi

Just to add to the mystery, I created a little log function that write to a local file and the app is starting, opening the database connection and then quitting without hitting the app.close event (hard crash?).

Web Apps built with R1 seem to work with no problems but I’ve been unable to get R2 apps to run.

Anyone else seeing this?  Anyone have any ideas?  This is very annoying.

I’ve been having issues recently with Real Studio recompiling my plugin cache frequently.  For those of you not familiar with Real Studio plugins, the IDE will create cache files for all the plugins so it doesn’t have to do this every time it does a build.  If you change plugins, or update them, it rebuilds the cache.

If you don’t use plugins it’s no big deal but we have quite a few plugins.  We use the Monkeybread Software plugins, Einhugur controls, eSellerate, and even our plugins that we’ve created for own use and for various client projects.  Based on configuration I sort of expect a certain level of pain for recreating the plugin cache.

One has to wonder why there’s not a more elegant solution built-in to Real Studio to manage plugins other than moving them in and out of a certain directory and restarting.  And that doesn’t even begin to address version issue with projects that are a few years old.

If you are having the same problem, you can sign on to the Feedback report:  <feedback://showreport?report_id=16431>.  This is currently ranked 54th in the Feedback System.

I’m not entirely sure what the mechanism is that Real Studio uses to determine if a plugin has changed.  Has that changed recently?  Or could the problem be the Monkeybread plugin since that seems to be a common plugin?  Maybe a combination of both?  Regardless, it would be nice to shine some light on this particular bug so it can be fixed because even with a fast machine it can become very tiresome quickly.

Are you experiencing the same thing?

Real Software released 2011 Release 2 this morning.  It has the usual number of bug fixes (especially for Cocoa) and some new things (especially for Web Edition).

I haven’t compiled my list of the good, bad, and ugly yet, but in my initial testing of Web Edition there are some significant changes that may or may not affect you.  The way WebPages are handled is different and if you relied upon the Session.CreatePage event you now have to rewrite that portion of it.   This change is for the better (in my not so humble opinion) but it might make your life a little harder until you get used to it (and change existing code).

The one critical bug that I’ve discovered in my testing this morning is that the config.cfg file that is generated by Real Studio gets fragged for CGI applications.  So instead of this:

APPNAME=JCLogin

THREAD_COUNT=10

PORT=0

AUTO_PORT=1

After I try to run it one time I get this:

APPNAME=

Obviously my app no longer runs.  Chatter indicated that RS thought this was a Windows only bug but since I’m running on Debian Linux I think the problem goes deeper.  More info as I find it.

[Update]:  I should point out that I’m creating a Linux, CGI application with automatic port detection.  I’m building it on Mac OS X 10.6.7 on an i7 iMac.

[Update 2]: Feedback:  <feedback://showreport?report_id=17297>

I was a Visual Basic developer for many years.  Despite the perception that VB 6 made crappy apps, I know of many successful commercial apps that were written in VB6 and, what matters more, is that those apps are still in service.  Despite Microsoft dropping support for VB6 years ago developers were able to limp along and get their apps working in Vista and Windows 7 with few headaches.

Does this change with Windows 8?  I don’t know, but I’m already seeing an uptick in developers that are looking to convert from Visual Basic 6 to Real Studio.  Uncertainty is a bad thing and even the full-time Windows developers I know don’t seem to know what’s going on.  Some of them are even worried that .NET and Silverlight support is up in the air.

The only thing that’s been mentioned for Win8 is JavaScript and HTML5.  No mention of .NET, Silverlight, or even Win32.  It’s very uncharacteristic of Microsoft to be so secretive and up-in-the-air over a future product.  Are they trying to be more Apple-like?  Perhaps that’s why people are freaking out.

Do I think MS is going to drop support for .NET, Silverlight, or even Win32?  Not a chance.  They have way too much invested in each of those to abandon them.  From a corporate standpoint there would be a revolt since almost everyone has invested, heavily, in one or more of those technologies/platforms.

But are Visual Basic 6 apps still safe?  That is a very good question and from the research I’ve done it appears that the VB6 runtime will not be shipped with Win8 though some in the community suspect that a hack will be found before release.  Other comments I’ve seen indicate that Win8 will ship as only 64 bit.  The VB6 runtime is 32bit only so that will mean running in compatibility mode which adds to the possibility of it not working properly for all applications.

Microsoft, at some point, has to kill compatibility.  Visual Basic is an old development environment that doesn’t take advantage of many new technologies.  It’s also not a very good object oriented language – it just wasn’t designed to be that way.  If the MS dev tools of the future are Silverlight, .NET, and JavaScript/HTML5 (does anyone really believe that!?), then it sure seems that VB6 might be on its way out.

So while VB6 apps might work with Win8 using hacks and compatibility mode, I believe developers have every right to be worried.  They’ve invested heavily in VB6 tools and controls and now the (long) honeymoon is over and it’s time to look at alternatives.

If you are only interested in Microsoft then the options are easy with .NET or Silverlight (assuming they aren’t going away).  If you’re thinking of a Mac or Linux version than the options are limited.  You could do Java, but as a long-time Mac user I’m not a big Java fan and try to avoid them because their UI generally isn’t native (I’m a Mac snob, but then most of us are).  Qt is a possibility but it’s not a RAD option either.

I am a little biased but I think Real Studio is a good choice for those coming from Visual Basic.  They are very much alike in how they work though REALbasic is MUCH better at object oriented programming than VB ever was.  It’s newer and is on a regular update schedule.  And, with just a little work, you can easily make apps for Mac, Windows, and Linux that look the same on all three platforms.  And now that Real Studio can make Web Apps there’s a fourth platform that you could potential support (though making a web app involves different controls, editors, etc so it’s not as easy as clicking a checkbox).

Is it a quick and easy conversion?  No.  Don’t trust any conversion program and, from experience, any converter will be just as time consuming (if not slightly worse) as rewriting from scratch.  We’ve found that taking a look at the UI and making it a bit more object oriented to take advantage of the strengths of REALbasic is always worth the investment.  We like to say you’re writing the apps for the next ten years and not only for right now.  So doing the extra work now will pay off for years.

Is Real Studio perfect?  Absolutely not.  It currently is not 64 bit compatible either though I know of many developers that have no issues with running in Windows 7 64 bit.  I do know that 64 bit compatibility is the next big upgrade for Windows after Real Software finishes up on Cocoa builds for the Macintosh side.  If memory serves they are on track for late 2011 64 bit compatibility (though that’s always subject to change).

With Win8 on schedule to be released next year (does anyone really believe that either?), you might need to be proactive and start thinking about the alternatives now.  Waiting until Win8 is released might be too late for your product.  Do you really want to be under the gun from management to get something that works on the CEO’s new shiny Win8 laptop?

If you would like to get a rough estimate on cost to convert from VB6 to Real Studio, we (BKeeney Software) have a VB6 Analyzer Tool for you to download (written in RB of course) that analyzes your project and gives us some metrics on lines of code, controls used, numbers of classes, etc, that help us give you an estimate.  More information can be found at http://www.bkeeney.com/consulting/vb2rbconversion.

I ran across a Twitter post today that asked what feature they’d remove from FileMaker Pro.  I don’t use FileMaker (not in many, many years at least), but I thought it was a very good question.

It’s a good question in regards to Real Studio too as it makes you think about what you don’t use.  I’ve asked the question before on what’s the one thing you need above all else in Real Studio.  But removing something is a much harder question.  So it should probably be something that’s not very good, or makes things worse, or something made irrelevant by 3rd party tools.

After thinking about it for just a few seconds I came up with the one thing that I never use in Real Studio:  The Database Editor.  For me, it’s the one thing that is worse than useless since it makes the job of managing your databases harder.  I mean,it’s just not very good, in my opinion.  Based on my experience answering questions in the Real Software forums it’s not an uncommon experience.

In reality, the database editor experience is much like any generic tool:  it just doesn’t have the features that match up well to tools built for the specific database.  If you want a good SQLite tool there are some awesome commercial versions available.  Heck, there is a freeware version that works inside of FireFox that’s better than the DB editor, IMO.  The same goes with MySQL, PostgreSQL, Oracle and any other database that RS supports.

I’m a big fan of Navicat as they have versions of each of the aforementioned databases.  Granted, Navicat has a generic user interface and it’s a Java app (I think) but it’s the only thing that Navicat does (database admin tools).  It’s interface is consistent across all of their versions so it’s no big deal to move from the SQLite version to the PostgreSQL or the MySQL version.

If the Database Editor was removed from Real Studio would anyone really notice?  What would you remove from Real Studio if you had the chance?