BKeeney Briefs

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?

If you use Real Studio and are a blogger, the fine folks over at Figa Labs have (re?) released a plugin for WordPress that formats your REALbasic code properly in WordPress.  This is a very nice plugin and is apparently based the PHP code of an old Real Studio employee.  So now your code snippets go from this:

Function Ask(instructions as string, byref initialtext as String, bPassword as boolean = false, w as Window) As Boolean

stInstructions.text = instructions

efText.Password = bPassword

efText.text = initialtext

efText.SelectAll

if w = nil then

self.ShowModal

else

self.ShowModalWithin w

end

if bSave then initialtext = efText.text

return bSave

End Function

 

To this:

The only tricky part it remembering the shortcodes, which isn’t really all that hard.  ”["rbcode"]” starts the formatting and “["/rbcode"]” ends it (remove the quotes to actually get it to work).  Ideally I’d love to have a button that lets me do format the code without having to remember the shortcodes but hey, life isn’t perfect.

Happy coding, and blogging!

I’ve been playing around with Cocoa in Real Studio.  It’s come a long way in the past couple of releases and I urge you to start testing your apps to find those pesky Cocoa bugs.  Real Software is making a huge effort for the 2011 R2 release to fix as many Cocoa bugs as possible.  It’s that close.

Yesterday I ran across a problem where my app was crashing immediately upon startup.  The crash log gave a very odd error message:

Dyld Error Message:  Library not loaded: /System/Library/Frameworks/user32.framework/user32

Wha?  User32?  That sounds like a Windows library and certainly nothing I’ve ever seen on Mac OS X.  I actually wrote the ‘bug’ up and sent it in via Feedback and then did some more research.  The answer wasn’t really all that surprising.

I have a lot of old code that I’ve developed, bought, and found over the years that make it into most of my projects.  It’s there and I don’t even think about it.  One of the pieces of code that I bought from someone works cross-platform Mac/Windows and so it has a ton of #if statements.  Things like this:

#if targetcarbon then

//Do Mac stuff

#else

//Do Windows stuff

#endif

See the problem?  If I wasn’t making a Carbon application, which Cocoa most definitely is not, it attempts to run the Windows code.  So now the crash log makes total sense.  I suspect that a lot of people will have a similar problem.

Check your projects for compiler switches like this.  If you’re developing cross-platform applications you’ll probably have this problem.  In the long run all I did was do a simple global search for #if targetcarbon and replaced it with the target for Mac OS.  That won’t work for all cases, but it should get you close.

Ideally I would love for the Real Studio compiler to give me a warning for this case but I don’t think that’s even possible.  Really, how many libraries are there in the world to know about for each platform?  Impossible I say.  At a minimum, however, I would think that it would be possible to get a better runtime error.  Sort of like how you get error messages if you don’t have the plugin libraries where the executable expects them (much more of a problem in Windows if you move the Libs directory).

What say you my fellow REALbasic geeks?  Have you tried Cocoa yet with 2011 R1.1?  Any major problems?

This seems like a no brainer, but we’ve been bitten by it and we’ve picked up the pieces of multiple projects from others who haven’t lived by this rule:  If you’re creating a cross platform application, test early and test often on the platform you’re NOT developing on.

Real Studio is a cross-platform development tool.  It runs on Mac OS X, Windows and Linux.  In the Professional/Enterprise versions you can build for other platforms and debug on the other platforms as well while staying your native environment (using remote debugging).  It’s really an awesome experience running Real Studio on the Mac and running the executable via VMare (or even on another machine in the office) running Linux or Windows.

We see it time and time again (and we’ve been guilty of it ourselves a time or two) where someone does all their development on Mac OS X and tests on Mac OS X but their app looks awful once they get it into Windows.  Text backgrounds looks like crap and the flickering is atrocious whenever they resize the window or move controls around at runtime.

The reason?  Mac OS X and Linux have double buffered windows while Microsoft Windows does not.  Mac OS X and Linux always draw to a buffer first and then draw to the screen.  Windows does not which is the cause of much flickering.  Real Studio has some easy workarounds for a bulk of the flickering and some simple rules of thumb to reduce, if not eliminate, Windows flickering issues.  Among them:

• Canvas objects should have Double Buffering turned on
• Do not erase the background of Canvas and Container Controls
• Be wary of using Refresh – perhaps Invalidate is a better choice
• Layering of controls will almost always get you into trouble.  Putting anything over a Canvas control (that draws anything) is almost a sure way of getting into trouble

So the lesson is that you really should be testing your app in all of the environments you plan on supporting early in your development process.  If you wait until you’re about ready to ship it’s too late.  You might have some fundamental assumptions in the project that’s hard to fix now that you’re almost done.

Cross platform development is easy using Real Studio, but that doesn’t mean there aren’t differences.  You need to test for those differences early and on a regular basis.

Since I spend most of my time on the Mac side I’m assuming Windows and Linux RB developers have the same issues going to the other platforms.  What are some of the issues you see?  Did I miss any reasons for Windows flickering?