Real Studio 2011 Release 4 was released this week by Real Software. This release marks a number of significant changes that might affect how your application behaves so take care when making the decision to upgrade (as you should with all new releases of your development environment).
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.
[Update: The WebToolbar styles are now in the online Wiki]