Tuesday, July 27, 2010

Important Information Regarding Cocoa Build Option

A Beta version of our Cocoa-based framework is included in REAL Studio 2010 Release 3, which is now available. While it is feature complete, it is not bug free or even close to that. Beta is defined as being feature complete but still needing usability testing. For more information about what beta means view the Wikipedia article, http://en.wikipedia.org/wiki/Beta_version#Beta

We decided to release a beta version so that we can maximize feedback about what doesn't work. While we have plenty of bugs left to fix, we want your feedback on as many issues as possible to make sure that Cocoa is of sufficient quality before we release it. Some of your projects will work and some will not. The more complex your projects are, the more likely they will not work. For example, a project that would otherwise work perfectly can be stopped by a single bug in a single control. If your project depends on a plug-in that provides any user interface, it will probably not work. Check with the author of the plug-in to see what their plans are for Cocoa support. When you find an issue, search using the Feedback application to see if this issue has been reported. If you have some additional information to add, please do so. If you have a simple project that reproduces the bug, please add it. And of course if the case has not been reported, please report it. Steps to reproduce a bug or a simple project really help gets bugs fixed faster. You can include screenshots as well, which can help when describing cosmetic bugs.

It is also important to us that you see we are making progress. Many of you are waiting as anxiously as we are for this transition to happen. Try each of the controls. Experiment. You will see that many things do work. The most important elements to try out are user interface controls. If your application builds but crashes on launch or at some particular point, create a report and include a crash log. Those details will help us track down crashing bugs. There are new pushbutton types, drag and drop provides ghosting now, your TextField controls support the Mac OS X spell checker and if you are into making OS API calls, check out the CocoaObject examples in the Examples folder.

Based on the speed at which we are fixing Cocoa bugs, we believe we can be ready to ship by the end of this year. Your help with trying out your projects and reporting bugs will help us to reach that goal.

There is a Cocoa Beta Information document included in the product download where you can find more information about the availability of the Cocoa beta.

REAL Studio 2010 Release 3 Now Available

AUSTIN, Texas, USA (July 27, 2010) — Software development tools company REAL Software today announced the availability of REAL Studio 2010 Release 3. REAL Studio is a cross-platform software development tool that enables developers to create high-quality, native applications for Windows, Mac OS X and Linux. Along with increased productivity, developers who use REAL Studio also report an increase in revenue for commercial applications, since they are able to get their product to market faster and expand their offering to multiple platforms. REAL Studio has a low learning curve, making it the perfect development tool for both those who are new to programming and professional software developers.

REAL Studio 2010 Release 3 includes 81 improvements and 25 new features. The new functionality includes:

  • LLVM for RBScript: RBScripts now run up to 17 times faster than in previous releases. Using LLVM for RBScript is the first step towards the adoption of LLVM for building applications in REAL Studio.
  • Cocoa (Beta): The option to build for Cocoa is now available, but is at the beta stage. There are some new features for Cocoa builds, such as Pushbutton now has a ButtonStyle property that gives access to nine new styles of pushbuttons.
  • Documentation: The REAL Studio documentation is now locally stored and the user can choose between viewing the local version or the online documentation,http://docs.realsoftware.com.
  • Reporting Improvements: To make reporting easier, reports can now take a RecordSet directly to report upon.
  • Database Improvements: ODBC and REALSQLDatabase queries and updates no longer block the other threads while they are executing. This allows users to make their user interface more responsive.
  • Graphics Improvements: All of the graphics classes are now supported in Console applications. Also, pictures can now be copied to and from MemoryBlocks using a variety of picture file formats. Since memoryblocks can be transformed into strings, this allows the user to store pictures without having to write them to the disk first.

“Over the next few releases of REAL Studio we will be transitioning to LLVM. LLVM for RBScript is the first step in this transition,” commented Geoff Perlman. “In this release developers will see a marked increase in their RBScripts and will see an up to 10x speed improvement once we move the main compiler to LLVM.”

The complete list of improvements and new features in REAL Studio 2010 Release 3 can be found in the release notes in the product download section, http://www.realsoftware.com/download.

Thursday, July 22, 2010

What's up with this 8 digit code?

I've talked with a lot of users lately about our validation process and subsequent prompts for 8 digit codes. Validation of your REAL Studio license will happen whenever you enter a key into the registration dialog, revalidation happens every 90 days. If you are online and using REAL Studio 2010r2 or later validation and revalidation will happen quickly and automatically.

If you are not there are a few different reasons you may be prompted for an 8 digit code when validating your REAL Studio license key.

1. You are working offline.

2. You are working behind a proxy server or firewall. In most cases this happens to users trying to validate from schools, universities and secure work environments and your REAL Studio is unable to communicate fast enough with our system.

3. You are using a version released prior to REAL Studio 2010r2. For more details on this visit Geoff's earlier post.

So how to do you get an 8 digit code?

1. Follow the instructions on the splash screen and call US Customer Service at 1.866.825.2114 during business hours 8:30 am - 5:30 pm CST.

2. Email Customer Service. Make sure to include the license key you are validating. We know how valuable your time is, if you are prompted for an 8 digit code outside of business hours or on a weekend please indicate "8 digit code" in the subject of your email. We will do our best to reply as promptly as possible.

3. You can also contact any of our partners around the world via email or phone.

You have an 8 digit code but get an error when you try and use it.

As a security measure we have implemented a 2 minute wait time between when REAL Studio prompts you for the 8 digit code and when you click Continue. You must wait at least 2 minutes at the screen requesting the 8 digit code or you will receive an error message when you click Continue. If you do receive this error message simply click Back, wait the 2 minutes and click Continue again.

Once you have validated with the 8 digit code your usage should not be interrupted again on that machine. Revalidation will not prevent usage if you do not have an internet connection or are using an older release, it will simply be delayed until later.

We appreciate your patience with this process. We have plans to make this easier to our users in the future and look forward to implementing those changes. In the meantime, if you have questions or comments please contact Customer Service.

Sunday, July 18, 2010

Exceptional Exceptions

If you're like me there's a good chance you learned programming using a language that didn't have the concept of exceptions. Instead, you probably had some error parameter to check to see if the call you just made succeeded. And if you're like me, you've probably heard that the REALbasic language has a feature called "exceptions" but you don't know much about them. You may know that they happen and that when they do it means something has gone wrong, but that's about it. Until quite recently, that was me. I didn't mess with exceptions because I didn't fully understand them and using an IF statement to check for an error was somehow more familiar and comforting.

In an effort to make the REALbasic framework more self-consistent, we are deprecating a few functions which are going to require you and me to get familiar and comfortable with exceptions. If the word "deprecation" is unfamiliar to you, it means we are not longer going to support a particular feature and will, one day far in the future, remove the feature. However, we do remove the deprecated feature from the documentation immediately to discourage its use. Why would we do this? Because if we don't, the REALbasic framework will age and be filled with "cruft" as we call it. Cruft is extra, unnecessary stuff that we have to maintain and thus adds to the expense of bringing REAL Studio to you. It also confuses new users as they aren't sure whether method A or B is the right one. If we don't deprecate things in favor of a better way of doing something, one day we could be in real trouble when some technology we have all grown to depend on suddenly doesn't work anymore and we require you to make massive changes to your code to move it forward. So think of deprecation as being like the pain of regular exercise. It's necessary, not always fun but better than the consequences of a lifetime of neglect.

So back to why you need to learn about exceptions and why they can actually be fun and rewarding. In REAL Studio 2010 Release 3 (the next release of REAL Studio) we are deprecating the NewPicture function along with NewMemoryBlock and NewAppleEvent. There are two reasons for this. First, these functions are not consistent with the regular way you create objects. For example, to create a new date object, you use this syntax:

Dim Today as New Date

Wheras with the NewPicture function, for example, your syntax would be:

Dim p as Picture = NewPicture(100, 100, 32) //the parameters are width, height and depth

The difference here appears to be nothing more than the space between "New" and "Picture". After all, this syntax is also valid:

Dim p as New Picture(100, 100, 32)

But in this case, you will need to use an exception. More on that in a moment.

The second reason we are deprecating these functions is because of how you deal with them when things go wrong. NewPicture (along with NewMemoryBlock and NewAppleEvent) creates something and returns the object if the object was created successfully or nil if it was not. When these functions return an object, life is good. When they return false however, the reason for that failure is unknown. Your guess is as good as mine.

Not with exceptions however. Exceptions give you a way to know exactly why an object was not created and they don't require any more code than an IF statement. In fact, they can sometimes require LESS code. Let's consider the following Canvas Paint event example where we create two pictures using NewPicture and then draw one into the other , then draw the result into the canvas:

This example has 14 lines of actual code. The two IF statements that check to see if the object was created or not make the code more complex and harder to read. Here is the same code rewritten using an exception:

Using exceptions, this code is only 10 lines and it a lot cleaner and easier to read. The catch statement at the end makes it quite clear why the pictures could not be created so your code is more self-documenting and readable. And of course, you could trap for other possible reasons as well.

Now, in the exceptions example I'm only dealing with the fact that either picture could not be created. But in this example, if I can't create one of them, then there's no need to continue. The reason exceptions are called "exceptions" is that they are not likely to happen. If they do, that case is an exception. Hence the name. In the first example, I have to have an IF statement after each attempt to create a picture. If I don't my app will crash with a NilObjectException. Yes, an exception. So you are dealing with them anyway. But in the second example, using an exception, I don't need to do this. If one of the pictures cannot be created, the code will immediately move down to the Catch statement.

Finally, if you have some code that should execute even if an exception has occurred, you can add the Finally statement after Catch but before End Try. You can see an example of this here.

Now you may think you've got a better way to write my examples above and you probably do if you think that. After all, I'm the CEO and that "E" doesn't mean Engineer. But the point is, exceptions are either the same amount of code or less than using IF statements and make your code easier to read and more self-documenting. They are a good thing. Do you have a choice to use them or not? For now, yes. But some day, a long time from now, NewPicture, NewMemoryBlock and NewAppleEvent will be removed entirely and then you will have to use the New keyword and exceptions so why not start today?

Think of this as an opportunity to learn something new and sharpen your skills. If you need some extra, added incentive, many other object-oriented programming languages support exceptions as well. Not that you will ever need to use any other language of course.

Friday, July 16, 2010

Tip: Pushbutton Height and Backdrops on Mac OS X

With the Mac's market share approaching 10%, more Windows developers are wanting to cross-compile their projects to support Mac OS X. If you are coming from Windows, this tip will help you understand a few issues you may face and how to deal with them.

It may surprise you to find that there is a restriction on the height of a pushbutton on Mac OS X. If you make a button more than 22 pixels high, the button will change from being rounded to rectangular. This is not a feature of REAL Studio. It's a feature of Mac OS X:

Bonus Tip: If you add a background picture using the Window's BackDrop property, on Mac OS X your controls will have rectangles around them with a background that matches the window. As a result, they will look like this:

However, if you set the Window's Composite property to true, the rectangle will disappear:

You will continue to see the rectangle in the Window Editor on Mac OS X, but not in your running application. The rectangle in the Window Editor will likely disappear once we are compiling the IDE itself as a Cocoa application. Depending on the complexity of your window, you may or may not have some issues with using the Composite property as it has some problems on Carbon. However, these issues should disappear once you can build using the Cocoa option as all windows in Cocoa are composite and are handled quite well.

Thursday, July 15, 2010

REAL Studio to Include Cocoa Framework Beta in Upcoming Release

AUSTIN, Texas, USA (July 15, 2010) — Software development tools company REAL Software announced today that their rapid application development tool, REAL Studio, will include the option to compile a Cocoa application in the upcoming 2010 Release 3. REAL Software has been working on the development of the Cocoa framework for a long time and though it is not yet complete, it is far enough along that it will be made available as a beta to all REAL Studio users.

On Mac OS X there are two ways for applications to communicate with the operating system: Carbon and Cocoa. Carbon was designed to allow applications from Classic Mac OS, like REAL Studio, to run natively on Mac OS X. Cocoa is the method that has been part of Mac OS X since its introduction and all applications must move to Cocoa to continue to be modern.

Unlike when other companies have gone through the conversion, REAL Software is trying to minimize the impact on their users. One of the many benefits of using REAL Studio is that developers are mostly abstracted from having to deal specifically with platform details. REAL Software has developed this new Cocoa framework in such a way that REAL Studio users will only have to recompile their applications to get a Cocoa version. When recompiled most applications should simply work. In some cases minor changes might need to be made such as if users want to take advantage of new features, like additional button types.

“Our primary goal with the transition to Cocoa is compatibility for people’s projects; we want them to just work,” commented Geoff Perlman, REAL Software Founder and CEO. “Had our users been developing their apps in C or C++, they would have had to go through the enormous task of transitioning from Carbon to Cocoa themselves, but we’ve saved them the trouble since they are using REAL Studio.”

“Even some of the biggest software companies on the Mac have struggled to make the conversion and many have had false starts," added Perlman. "We are excited to be nearly complete with the transition.”

For more information about REAL Studio or to download the latest version, visit http://www.realsoftware.com.