The first significant change in R4 is that it no longer compiles for PowerPC (PPC) which means that Universal Binaries can no longer be built.  Mac OS X versions 10.5 (Leopard) and better are now supported.  I have not tested this premise but your app might run on older versions of Mac OSX, please let us know your experience.

The R4 release sports a huge number of Cocoa fixes.  Cocoa is now mostly usable but there are still bugs and oddities in this version.  Drawers, StyledTextPrinter and MoviePlayers do not work in this release.  Drawers are not used (much) in Mac OS X any more and not many use StyledTextPrinter but the MovePlayer could be a significant problem for quite a few RB developers.  However, if your app makes use of these controls and classes you will not be able to upgrade and will have to wait for a future release of Real Studio.

You REALLY need to start testing your apps in Cocoa (if you haven’t started already).  You are bound to find something that RS hasn’t fixed yet, or, at a minimum, requires some additional optimization.  One bug that has hit us particularly hard in trying to port one of our apps to Cocoa happens when trying to access a toolbar with a separator.  When accessing it an un-trapped exception occurs which means your application goes “poof” and there is nothing you can do to catch it.  <feedback://showreport?report_id=18971>

Another Cocoa bug that’s affecting some of our projects is the graphics object.  If you use FillRect or ClearRect on a picture that ISN’T new it is extremely slow.  So, for example if you have an overall picture and you’re just updating a section of it, it will be very slow.  <feedback://showreport?report_id=18915>

Cocoa really is different than carbon and some things that appear to be bugs aren’t necessarily so.  For example, all fonts in carbon apps can be made italic.  In Cocoa not all fonts have an italic version so it won’t render it in italic’s regardless of the setting.  Carbon just happened to force an italic version regardless of the font whereas Cocoa won’t.

Web Edition has changes too.  The first is that all Web Edition projects now require the app.ApplicationIdentifier to have a value.  The IDE will no longer allow it to be blank and if it’s not filled in when opening an older project one is added for you (so be aware of it).  This is important because the each Web App running on the server must have a unique identifier.

The WebListbox received some much needed attention in this release.  Column widths now work properly (yay!) and no longer shows an extra column.  A new boolean property, called Multiline, was added to match desktop listboxes more closely and when set to true, each row will expand automatically to fit all the text.  If false, text is truncated to one line with ellipses if it’s larger than one line.

The WebToolbar has some new style options available.  These are not documented but You have control over the WebToolbar background, button, disabled button, item, toggled style and toggled disabled styles.  You can make some interesting combinations with these new style options.

Dynamic Constants in Web Edition can now be retrieved by language.  The WebPicture class now has 3 new constructors.  Unfortunately, you still can’t use dynamic constants like you can in the desktop editions so you have to code this manually.

Lest our Windows brethren feel left out there are a number of significant bug fixes in store for them as well in this release.  A number of memory leaks were fixed.  Drawing of primitives (rects, ovals, etc) are no longer off by a pixel (yay!).  When GDIPlus is enabled, Windows apps can now draw anti-aliased.

One of the biggest changes in R4 is that pictures and colors now support alpha channels and allow you to set their translucency.  This is a big deal for any plugin authors that deal with pictures as they will have to rewrite their plugins to check for the alpha channel or lack thereof.  It promises to be a nightmare for them since older versions or Real Studio won’t support it but newer ones will.  Be aware of this change if you rely upon 3rd party plugins that use, return, or otherwise manipulate graphics.

Be aware that the database plugins included in R4 are NOT backwards compatible.  Like many Mac developers I have multiple versions of Real Studio in the same folder so I can have the same plugin set across versions.  If you try to run an older version of Real Studio using the R4 database plugins Real Studio will fail silently.  I expect numerous reports of older versions of Real Studio to suddenly start ‘failing’ because of the change to the plugin format.

I’ve been using R4 since practically the first alpha.  I am converting my training videos to work in Web Edition and I’m fast approaching release.  It wasn’t until this weekend that I found a bug when saving using the version control format.  If you use the WebToolbar and assign icons to a button the changes will not get written out properly <feedback://showreport?report_id=19231>.  This really sucks because I have to go back to binary format – again.  Sadly, Web Edition has been rife with version control format bugs since the very first release and these woes continue.  It is obvious that the RS developers do not use version control format when testing Web Edition features.

Unlike many Real Studio releases, Release 4 is a huge bug fix release (well over 200).  The number of Cocoa changes is significant and developers should start porting and testing their apps in Cocoa.  It is really important for you to do so.  As with many releases there are some changes you might not be able to live with and some changes have been made in the background for future changes.

At the Real Studio Database Days training in Frankfurt Germany in early November, Geoff Perlman, CEO of Real Software, said that 2012 Release 1 would probably be the first release where Cocoa would be enabled by default.  What went unasked was whether or not the IDE itself will be a Cocoa application or not, but I would presume that it will be.  Regardless, the march to full Cocoa support goes on and you should be preparing for it sooner rather than later.

Happy coding!

[Update:  The WebToolbar styles are now in the online Wiki]

If you’d like your controls or libraries reviewed, please don’t hesitate to ask ARBP, or myself, or both, to review them.

2010 Release 5 and the subsequent 5.1 release (released in 2011 – how does that work?) were mainly about Web Edition.  I did a significant portion of a big web app project using Web Edition and to put it bluntly, there are many bugs, holes and significant issues with all aspects of Web Edition and I can’t really recommend it for production apps right now.  There are still significant issues with browser compatibility that need to be ironed out as well.

Deployment of standalone web apps seems to be okay, but installation of FastCGI applications was hit and miss (mostly miss) on commercial web hosts.  Since it was pretty much a black box installation it either worked or it didn’t and neither RS nor the web hosts were able to help much in diagnosing the problem.  And now we’ve been told that FastCGI isn’t all that RS hoped it would be and a new middleware application needs to be on the server so it can run as a CGI application.  This is disheartening to everyone that put in significant time trying to figure out deployment issues (including me).

Obviously, despite all of the problems in the first release of Web Edition, my client does have a working web app on his website (sorry, can’t share the URL).  To me this truly does indicate how powerful the RS web framework is and with a little more thorough testing and polish it should be a nice addition to my toolset.  I see much promise in Web Edition.  It makes the creation of web applications very easy.

Most of the skills you’ve spent years developing for desktop applications can be transferred to Web Edition with very little learning curve.  It’s those little things you’ve come to expect in desktop edition that will make you feel exasperated.  WebPage constructors don’t work as you would expect and sometimes subclassing WebDialogs will cause them to just not work and the Application.UnhandledException doesn’t catch exceptions and doesn’t let you keep your web app running.  All of these, by the way, have been marked as fixed in 2011 R1 already so RS is being very responsive to the major issues.

The other significant part of Release 5 was Cocoa.  Many things were fixed and much of it is now working.  Of course the first project I tried in Cocoa failed miserably due to a graphics issue but that appears to already be fixed (after I submitted a feedback report with a reproducible example project).  So despite all the fixes it’s still a work in progress.

RS really needs as many people using Cocoa as possible to find those hidden or quirky problems.  Always remember that RS doesn’t always use their own product like we do:  so creating feedback reports with example projects is the best way to help them.

A very promising note, though, is that the Feedback application that is available to beta testers is now Cocoa.  In my usage it’s pretty solid – but not quite perfect.  But it is built using an alpha build of Studio 2011 R1.  So it’s close.

So if you missed out on R5/5.1 you probably didn’t miss out on much unless you were specifically looking for Web Edition and Cocoa.  The march to Cocoa continues and it’s getting better (really!).  Web Edition shows a lot of promise and WILL get better (it has to) and hopefully the deployment issues go away in 2011 R1 which will hopefully go into beta testing soon.

Also, in a shameless plug for my REAL Studio training videos, I have an 18 minute companion video that goes into more detail at https://www.bkeeney.com/realbasic-training-section/free-content/article/2-free-content/288-real-studio-2010-release-4 (free registration required to view the video).

More thoughts on this release in the future as I dig out from work.

REAL Software announced today a new version of REAL Studio, called Web Edition, that will be released some time this Fall.  Internally, they called this product Barracuda.  If you know any history about REAL Software, they had an internal product named Swordfish that they announced at their annual developers conference in 2005.  It was never released because it was already obsolete soon after they announced it due to a variety of technologies like AJAX and JAVA and a number of other technologies.   So call this completely rewritten version the “Son of Swordfish”.

I spent three hours playing with an alpha build this weekend and my first impression of the product is good.  Since it’s an alpha build it has plenty of bugs but it is an interesting twist on REAL Studio and REALbasic.  This has the potential of being the first Rapid Application Development environment for web apps that doesn’t require an expensive server as these apps will run on any Apache server or web server capable of FastCGI (not all commercial hosts enable FastCGI on shared servers).

Existing users of REAL Studio will be instantly familiar with the editors and know how to get around.  Since web apps are unlike desktop apps in many ways, there are a number of new objects, classes, and controls that are for web apps only.  There are also some things, like the MsgBox function, that did not work for me but will probably work when it’s released.

Instead of the regular Application object, every REAL Studio web app has a new WebApplication object that handles the open, close and unhanded exception events.  New to the web app is the WebSession object which represents each user that is connected to your application.  It has Open, Close and Reloaded events which, as you can imagine, are similar to what you might do in the Application object in the desktop version since a desktop app supports one user at a time.

Instead of creating windows, you create web pages and you edit them in the web page editor.  It is much like the current window editor but has a new set of controls and new features to go along with it.

One of the first new features you’ll notice is the ability to do in-line editing.  There is a little editor icon to the right of most controls that when selected, brings up an editor for that control and masks out the other controls.  For some controls, like buttons, text fields and so on it simply changes the text you see on screen.  For more complex controls like the listbox, for example, you can add column headings and add default data into the listbox.

In some respects some of these features remind me of how ActiveX controls in Visual Basic 6 used to have their own editor and UI and for the most complex of controls this will be welcome as editing them through the properties list can be tedious.  For the simpler controls (like the button, label, etc) this new inline editor does the same thing as simply selecting the control and starting to type.

The page editor has tweaks on features that are better than the current Window editor such as visually aligning controls and showing spacing differently.  There are also a number of new controls that are pretty common in web apps today: Link which is a label that when pressed opens the browser to a new page; Search Fields which is a rounded TextField that keeps track of last values held; Segmented Button which is a row of buttons that can act like either radio buttons or check boxes.

There are a number of controls that have changed as well.  Pushbuttons are now WebButtons and Checkboxes are WebCheckboxes but act pretty much the same.  The StaticText object has been renamed to the WebLabel (which makes more sense to many developers coming from other languages).  Radio Buttons are no longer individual controls – they are now part of a group and you can specify their dimensions like a listbox (number of columns and rows).  I’m actually on the fence on this one since I see the value in it but could also see it biting me depending upon the complexity of the user interface in the project.

The first release will not come with a proper tab control, unfortunately.  This is disappointing, but you can easily overcome this limitation with a Segment button and using Container Controls.  Just like with the desktop app, I think Container Controls are incredibly powerful, and is a useful way to make complex, reusable ‘window-like’ objects.

Perhaps one of the bigger changes is the removal of the Canvas object.  This was done, I was told, because HTML5 has a canvas object and REAL Software did not want any confusion.  Instead we have the ImageView object which can accomplish many of the same things using its Picture property (the graphics object is gone).  The canvas object may return at some point, however.

One huge change is that in none of the controls or windows can you control the text characteristics or background colors you’re used to expecting in a desktop app.  For that, we now have Styles.  Adding a style is just like adding a new class or anything other object in REAL Studio and when you edit a style you have the ability to change the properties of Normal, Hover, Pressed, and Visited objects (this includes pages).  There, you can control the text properties, border, shadows, padding, corner radii, and opacity.

As you can imagine, this leads to some very interesting interactions that take very little code.  For example, you can create buttons that change color when you hover over them, or change opacity once you’ve clicked on them.  I suspect that this will be a huge deal in the long run as it makes very complex interfaces very simple.

Since there are a ton of things you could do with a web app and no possible way for REAL Software to cover them all, they have a virtual control called PageSource that lets you add pure HTML code, JavaScript, and others, and can be placed in any web page.  It has two properties, the code itself and the location.  You can place it in the Header, Before Content, or After Content.  I imagine that just like for plugins for desktop applications, there could be a market for HTML components for REAL Software web apps.

Placing and dealing with the code behind the objects is just like a desktop application.  In fact, it’s the same code for the most part.  Where things start to diverge is with dialogs.  In desktop applications you create a window and change it’s super to modal dialog or similar, and call it via code.  This was flexible and convenient but created a new window.  Many users have popup windows turned off so this won’t work.

To compensate, REAL Software created a web dialog class that doesn’t create a new window, it just shows up on the current window using some nifty AJAX.  Since the standard MsgBox method did not work in this alpha build I ended up creating my own web dialog and adding it to the page.  After you add it, it is displayed in a new list at the bottom of the window and can be access there.  Otherwise it acts similarly to how dialogs work now.

Debugging an app is easy as well.  Simply hit Run in the IDE and it compiles and runs the web app on the local web server.  It responds to break points and exceptions just like a desktop app and and allows you to interrogate application variables in the debugger.

I’m not sure if web apps will understand the concept of Reports in the first release or not.  If you need to display a report to the user, you could probably accomplish the same thing with a listbox that covers the entire page.

Currently, REAL Studio supports two types of builds.  The first is HTTP and the second is FastCGI.  FastCGI should be more efficient, but might not be for everyone if you’re on a commercial hosting service since many do not support FastCGI.

REAL Studio Web Edition apps work with Safari, FireFox, Chrome and Internet Explorer.  How far back this compatibility goes I’m not sure of at this point.  If you find a limitation, you can use the functions in the Session object to get the browser type, operating system, platform, etc and give corresponding messages.

The Session object also keeps track of the page state so your active web pages won’t be forgotten during a session.  This means that each page is ‘remembered’ which is a very nice feature.  So if you have a Customer page and an Invoice page and the user reloads the page or closes it and returns before the session ends it will load exactly where the user left off.  This is another one of the main features that I’ll like to see in action on a complex web app.

I spent less than a half hour converting a very small calculator application I had originally written as a desktop app.  I spent more time logging the minor bugs (I did say it was an alpha build, right?) I found than I actually did writing the web app.  I have no idea how long it would take to accomplish the same thing in php, Javascript, Ruby on Rails, or ASP.NET, but I suspect the answer is longer.  I’ll be curious to get a true web developers impression.

The one big question that remains is how easy it will be to deploy and install REAL Studio web apps on your server.  I looked up some documentation on my commercial host on how to install FastCGI apps and it did not appear to be for the feint of heart as it required going to the command line on the server.  At this point I do not think there is an option for Single-Click-to-Install.

The Web Edition will become part of the Enterprise Edition of REAL Studio and also as a standalone version for those interested only in web apps.  This addition to the Enterprise Edition really makes it worthy of the Enterprise moniker now.  The web app addition is scheduled to be released sometime this Fall.  With REAL Software’s rapid release plan that could mean either Release 4 or 5.

What do you think about this announcement?  Is your curiosity piqued?

Summary:  Smallish interim release with not a whole lot of new features.  Bunch of bug fixes.  A couple of new bugs introduced that may or may not affect you.

I’ve been using 5.1 exclusively the past week or so and it seems to be stable so now I can move up from R3.  Thankfully, the huge SQLite bugs introduced in R5 have been fixed in R5.1.  Reporting still has issues though.

Back in May is posted about the stupid error message and problem that occurs when you load a version control project with missing files.  I am happy to report that it’s much better now.  The IDE will ask for the missing file and if you click cancel it will load as much of the project as possible.  Before it would just stop loading the project and you’d get a mysterious File Error 0 message.  Now you get this error message:

This is great but in one project due to file corruption issues I clicked cancel over 25+ times.  So at this point this dialog isn’t exceptionally helpful because it tells me something bad has happened it just doesn’t give me a clue as to which ones were bad unless I happened to write every one of them down at the time the dialog was shown.

What would be more helpful is having a log file of missing files generated or list the files in System.DebugLog.  Either way it would more helpful.  Ideally I’d love to have the option to have it stop asking for the missing files and just create the log file but I understand that the IDE might have to undergo some significant changes to allow that.

And before anyone says it, of course it’s my fault, if the files weren’t corrupt/missing to begin with I wouldn’t have this issue.  Stuff happens – get over it.  Regardless, this one improvement will make my life a little saner.

Is there one fix/new feature that is really good news or bad news for you?  What do you think of the EditField deprecation and subsequent replacement with TextField and TextArea controls?