Wednesday, August 22, 2012

Tab Order Change in Real Studio 2012r1

With Real Studio 2012r1 we have changed the behavior of the tab order for Cocoa apps. In the past, the tab order for controls on your window was defined by you. You would click the Edit Tab Order button in the Window Editor and set the order in which you wanted the user to tab from control to control.

There are problems with this:

1) Most applications, including the Real Studio IDE, don't have the tab order set properly. This is due to the fact that every time you add a control, the tab order must be set for that control and users (ourselves included) tend to forget to do that. This causes problems for end users and is very easy for a developer to miss.

2) On OS X, the system will handle the tab order automatically and in doing so makes all kinds of keyboard accessibility features work for free such, as being able to tab into controls in toolbars. By circumventing the system's handling of tab order, apps built with Real Studio often don't handle keyboard accessibility very well, becoming a big problem for some users that really need this. If we continue to override the OS, we can't fix the bugs with keyboard accessibility. Also, generally speaking, we try to let the OS do whatever it does naturally so that we don't introduce bugs by circumventing it.

We have discovered that most applications have a tab order that is the same as what the OS would normally provide. So for Cocoa apps built with 2012r1, the tab order set on the layout is ignored and the tab order is generated automatically so that the OS can handle it. This solves both the problems above.

Currently, this change in behavior is limited to Cocoa apps. But it is our intention to change it for Windows, Linux and web applications as well. If you have a special case where you need the tab order to be different than the default, there is a way to handle this:

Tab order is handled by the parent container. You can use a parent control such as a group box or canvas to change the tab order. For example, say you have four Textfields, two columns and two rows:

C1R1 C2R1
C1R2 C2R2


Normally, the tab order would go:

C1R1 -> C2R1 -> C1R2 -> C2R2

If you need to change the order so that, for example, it goes C1R1 -> C1R2 -> C2R1 -> C2R2, put C1R1 and C1R2 on a canvas control. That will cause the tab order to go down instead of across.

We believe this change will result in a better user experience because the tab order will automatically work as expected on that OS, while still leaving you a way to achieve a different tab order if needed. If this method of changing the tab order does not work for you, please contact us through tech support. Before we make this change permanent, we want to get input from you, the community.

UPDATE: After considering feedback from the community, we have decided to rollback this change in R1. We are working on an update (R1.1) that will re-enable the ability to set the tab order once again. We have found a way to provide the default tab order along with a custom tab order option (the one you have now) which we will add to a future version.

Tuesday, August 21, 2012

ODBC and PostgreSQL Plugin Updates for Real Studio 2012 Release 1

Real Studio 2012 Release 1 was shipped earlier today.  The ODBC and PostgreSQL plugins each had a fix that was made after the final installers were created.  You can download newer versions of these plugins from our web site:

http://www.realsoftware.com/download/#extras

This is what changed:

ODBC:
22159: Multiple connections can again be open at one time.

PostgreSQL:
22166: No longer crashes when binding an empty string with PostgreSQLPreparedStatement.Bind.

So if you use either of these plugins, download the updates from the web site: http://www.realsoftware.com/download/#extras

Wednesday, August 15, 2012

Improve Your Build Process

An under-utilized feature of Real Studio is Build Automation.  Build automation is a way for you to have certain tasks (called Build Steps) run automatically each time you run or build your project.

The available build steps are: Copy Files and Run Script.

Right now, Build Automation is a feature of Real Studio Web and Enterprise editions, but starting with Real Studio 2012 Release 2, it will be available to everyone.

Copy Files

Use this step to copy files that your application needs to a location it can easily find at run-time.  You can copy files to a variety of locations, but the most common are Bundle Parent folder and the Resources folder.

The Bundle Parent folder copies the specified files alongside your built application (or application bundle on OS X).  You might do this for certain types of support files.

But more typically, you will use the Resources folder.  This copies the specified files to a Resources folder that is alongside the built application.  On OS X, it uses the Resources folder within the application bundle.

You can copy any file that you want your application to have available when it runs.  This could be help files, pictures that you do not want included in the project or really anything.  It is particularly useful with web applications so that you can make sure any other files needed for the web app are included in the same folder.

To add a Copy Files build step, use Project -> Add -> Build Automation -> Copy Files.  Then you can click the small circle icon for the Files property to open the Files dialog and drag the files you want to copy to it.

In order for a build step to work, you have to add it to the Build Automation section of the project.  In this section there are entries for each target platform and below them a "Build" entry.  This allows you to have separate steps that do different things for each platform and to have steps that run before your application is built and steps that run after it is built.

Scripts that copy files should run after the application is built, so you would copy it after the "Build" entry.


Build Automation in Project List


Run Script

The Script build step allows you to run an IDE Script, which are powerful ways to control the IDE and run external tools.

Here's one thing you might find useful: Saving your project automatically when you click Run.

To do this, add a new Script step to your project (Project -> Add -> Build Automation -> New IDE Script).  Click on the Script property to open the Edit Script dialog and enter this script:

DoCommand "SaveFile"

This tells the IDE to save the current project.

In order for this build step to run *before* the build is done, you now need to drag it before the "Build" item in the Project List.


Another useful command for Run Script is DoShellCommand, which allows you to run a shell command.  For example, with OS X you could use DoCommandShell to code sign your application after it is built:


Call DoShellCommand "codesign -f -s ""Developer ID Application: YourName""  ""YourRealStudioApp.app""" 

I hope you find some great uses for Build Automation!

Friday, August 10, 2012

An Italian Real Studio Duo

The Olympics are still going strong and we have enjoyed watching all of the extremely talented athletes and hearing the inspirational stories about how they got to the Games. In that spirit we have asked our international employees to put together pieces on developers from their home countries. We'd like to thank Gilberto for putting together this blog post about two Real Studio developers in Italy.

System-i is a small business run by Sergio Tamborini and Emanuele Piccini. They provide software and hardware support for Apple products. They work closely with loyal customers, mainly located in their area of Italy.


Sergio and Emanuele joined forces and founded System-i in 2004, with the goal of delivering multi-user and cross-platform ERP (Enterprise Resource Planning) solutions for Mac OS X, Windows, Linux and the webThey also offer highly customized content management systems for the web.

System-i avoids ready-to-go open source products- as they hardly adapt to every customer needs and often requires much maintenance to fix security holes- in favor of customized solutions created with Real Studio Enterprise Edition.

One of the key aspects of their work is the extreme attention to details and ease of use of their products. Most of their products intuitively satisfy every customer request, often without the need for a printed user's guide.



Gest-L is one of their powerful stock software apps created using Real Studio Enterprise Edition.

It is a modern ERP solution that can handle customers' and suppliers' contact info, invoicing (incoming invoices, outgoing invoices and due dates), quote generation and graphic reports.


Sergio Tamborini is an IT enthusiast since 1982 and has worked as a freelance consultant since 1997. He started using Real Studio in 2000 to create software for the Mac. He is a self-taught and matured a valuable development experience over the years.

Emanuele Piccini has worked as a freelance developer and system administrator since 1999. More important, he's a true geek since the first time he touched a keyboard. He started using Real Studio in 2004 to create cross-platform solutions.

Thursday, August 2, 2012

Code Signing Real Studio Apps for Mountain Lion

Updated 2012-08-03: You do not have to sign dylibs for GateKeeper, only for Mac App Store submissions.
Updated 2012-11-05: Added note about codesign tool working with 10.6, 10.7 and 10.8.

With the release of OS X 10.8 Mountain Lion last month, the new GateKeeper functionality is now in effect.  This means that new apps that are downloaded or copied to a Mac with Mountain Lion, but that are not digitally signed using your Apple Developer Certificate, display this error when run on Mountain Lion:


Mountain Lion Error for Unsigned Applications

This error can be overridden in System Preferences, by changing the "Allow applications downloaded from" setting to "Anywhere":


Security & Privacy System Preferences


And you can right-click on the app and click Open in the menu to tell OS X, "I'd really like to run this app, thank you very much."

Note that this only matters for new apps that you transfer to a Mac running Mountain Lion.  If you have Real Studio running on Mountain Lion, you'll be able to run the apps you create just fine.  You'll only run into this warning when you copy the app to another Mac, either by making it available for download or by copying it via a USB stick, the network or anything else.

So even though you don't technically need to sign your OS X applications in order for them to run on Mountain Lion, you are probably going to want to.  The truth is that most people will just leave the setting at the default and will not know that when they get the warning message that they can right-click on the app to open it.  You could try explaining all this to them, but either way it is going to be a hassle for your users. Odds are they just won't bother with your app.

Unfortunately, to sign your apps you need a developer certificate from Apple.  And the only way to get a Developer Certificate is to sign up for the Mac Developer Program, which costs $100 a year.  However, the certificate you get is good for 5 years, so it looks like you do not need to pay the $100 fee each year unless you also want to distribute apps in the Mac App Store.

You can find out more about the Mac Developer Program at the Mac Dev Center:

https://developer.apple.com/devcenter/mac

Once you have joined, you can create your own certificates using the Developer Certificate Utility at the Mac Dev Center.  The steps are a bit involved, but essentially you will request a Developer ID certificate on this page:


Developer Certificate Utility page at the Mac Dev Center


And then the Utility walks you through the process of starting KeyChain Access and downloading and uploading files until you have the certificate installed.  It's a little tedious, but relatively straightforward.

That's the hard part.  With the certificate installed, you can now use it to code sign any of your applications.  You do this using the Terminal command codesign (pronounced "code sign").

But before you begin, make sure you have the Intermediate Developer ID certificate installed.  Go to this page:

http://www.apple.com/certificateauthority/

and download the Developer ID certificate.  Double-click it to install it into Keychain Access.

Now you are ready to code sign your Real Studio application.  Navigate to its folder using Terminal.  There you can enter this command to code sign your application and all its libraries.  Obviously you want to replace "YourRealStudio.app" with the name of your application and "Developer ID Application: YourName" with the name of your signing certificate specified in Keychain Access.

codesign -f -s "Developer ID Application: YourName"  "YourRealStudioApp.app"

That's it.  Now you can compress your app and transfer it to another computer with Mountain Lion and you'll be able to run it just by double-clicking on it.

Here is a sample application that I've code signed using the above process.  Feel free to try it out:

https://dl.dropbox.com/u/3867245/TestSign.zip

Update (2012-08-03):
If you are having trouble with these steps, one thing you might try is to download and install the Command Line Tools for either Lion or Mountain Lion.

Update (2012-11-05):
You can use the codesign tool on Snow Leopard (10.6), Lion (10.7) and Mountain Lion (10.8) in order to sign your apps for Mountain Lion.


References

https://developer.apple.com/resources/developer-id/

http://www.apple.com/certificateauthority/

https://developer.apple.com/downloads/

Wednesday, August 1, 2012

Connecting to MySQL using "localhost"

Connecting to a MySQL Database can cause some confusion, especially when different permissions are required for different objects.

We often hear from users who can connect to a MySQL Database using "127.0.0.1" but cannot connect using "localhost", which they expect would work the same way.

The confusion is caused because to MySQL *localhost *and *127.0.0.1* are different objects, so you need to apply permissions to those objects.

You can use the script below to apply all privileges to root:

grant all privileges on *.* to 'root'@'localhost';
grant all privileges on *.* to 'root'@'127.0.0.1';
grant all privileges on *.* to 'root'@'%';
set password for 'root'@'localhost' = password ('yourpasswordhere');
set password for 'root'@'127.0.0.1' = password ('yourpasswordhere');
set password for 'root'@'%' = password ('yourpasswordhere');
flush privileges;

Thanks to Luciano Fontes for this tip.