Tag Archives: Cocoa

Formatted Text Control 3.1.0 Alpha 1

Posted on by

If you work with Canvas objects that need text handling in Real Studio/Xojo Cocoa builds you quickly realize that it works vastly different than in Carbon builds.  This is because Carbon apps (through Apple Text Services) gives you a bunch of information for free.  In Cocoa only text controls get that information and that presents some issues to Xojo developers creating custom controls that do keyboard handling.

The Formatted Text Control is a word processor control for Xojo that is based on a canvas subclass and it works in Cocoa – somewhat.  If you try to do any international characters such as é or ü you quickly discover it doesn’t work like it should.  This problem is not unique to just the FTC because the Xojo Code Editor is also based on a Canvas subclass.

Xojo released an open source plugin on Friday for those who want to create custom text controls with international support (and integration with some Cocoa features).  The plugin is available on GitHub for anyone to use.  That page is at https://github.com/xojo/TextInputCanvas and the direct download for the plugin is at https://942ca60ce8039dc2659a-a2bc01947b765e9363feed443ae584ec.ssl.cf2.rackcdn.com/b1a9e16622/TextInputCanvas.xojo_plugin (this may change soon).

Formatted Text.debugScreenSnapz001

We’ve been fortunate to work with Xojo Inc in getting the Text Input Canvas plugin for early testing and integration.  This plugin works on Mac, Windows, and Linux and adds a number of events to the canvas control that you have to implement to get it to work.  Among one of the more important events you now need to handle is the DoCommand event.  The OS passes in all of the keyboard events the could happen including arrow key movement, delete and backspace keys, and insert new line to name just a few of the possibilities.  If it’s actual text to be inserted (rather than cursor handling or selection changes) the InsertText event passes in the text as well as the range of the text.  Incomplete text (such as the é and ü) that requires multiple steps in Cocoa get inserted using the SetIncompleteText event.

The control itself then wants to retrieve some data that Cocoa needs by way of several events such as the IncompleteTextRange and SelectedRange events.  This allows the FTC to not only support international text in Cocoa but to also get use some OS level Cocoa goodies.  Hover the cursor over a word and then press Control + Command + d to see the definition of the word just like any other Cocoa app.

Unfortunately, the current download for the plugin doesn’t have much in the way of documentation for how the new events work and what is required for it to function in Cocoa.  This is unfortunate because it’s rather complex and we’ve spent a lot of time working with the plugin and with the Xojo engineers to get the FTC working properly (and we still have some things to work on).  I guess this means that the best example/documentation currently available is the Formatted Text Control.  Again, I expect this to change in the near future.

Today we are releasing FTC version 3.1 alpha 1 for Xojo.  Since this requires the use of the Text Input Canvas plugin this is a Xojo-only solution.  For those still on Real Studio you need to stick with version 3.  Version 3.1 is a free upgrade to anyone that already owns version 3.  All previous versions are eligible for a discounted upgrade.  If you do not have an upgrade coupon from us, please send us an email at support at bkeeney dot com.

If you already are on version 3.0 you should have received email notifications from our File Share application.

UPDATE:  I need to note that building for Carbon isn’t supported in FTC 3.1.  The new plugin is Cocoa, Windows, and Linux compatible.  If you’re building for Carbon you should continue to use version 3.0.

Long Live Cocoa (or is sandboxing killing carbon?)

Posted on by

Real Software posted an article on changes to the Mac App Store.  Starting in November apps submitted to the Mac App Store must be sandboxed.  This is a huge change and currently, according to Real Software, the carbon implementations to accomplish sandboxing are broken.

More information the Apple sandboxing can be found at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/ApplicationSandboxing/ApplicationSandboxing.html and I highly recommend you read it.

At the very bottom is a caveats section: apps can’t send AppleEvents from the sandboxed app (though they can receive them).  This seems rather extreme.  If your Mac app can’t send AppleEvents does this mean that Apple is killing AppleScript?  I doubt it, but it does seem to limit the usefulness of the service and I suspect that there will be a workaround.

Apps cannot work with non-bundled projects that reference other files.  Does this mean that services like Kagi and eSellerate will no longer work?

So what does this mean for a vast majority of Real Studio developers?  Not much really – unless you happen to be selling your apps in the Mac App Store.  For you, the changes are important and you’ll need to start compiling for Cocoa.  Cocoa is much improved in Real Studio 2011 R2 than any previous Real Studio release but unfortunately it still not complete.

So the bottom-line is that if you are developing Mac apps and hope to put it in the Mac App Store then you’d better start testing your builds in Cocoa.  While your app may not ship using Cocoa yet, Real Software needs the feedback on what’s not perfect so they can fix it.

It’s a good idea to start using Cocoa now because in November you’ll need it.  Long Live Cocoa!

Cocoa Tip

Posted on by

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?

Minimal Review For REAL Studio 2010 R5

Posted on by

I said back in December that I’d write a review of REAL Studio 2010 Release 5 when 5.1 was released.  Well, that didn’t quite happen as I expected.  For one thing, the 5.1 release didn’t happen until January and now we’ve discovered more information about the main component of R5 – Web Edition and its deployment problems..

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.

REAL Studio to Include Cocoa as Beta

Posted on by

Official word from REAL Software about Cocoa.  2010 Release 3 will include the option to build for Cocoa.  Officially this will be labeled as ‘beta’.

I think this will generate a LOT of Feedback reports for them.  Sure, it’s ‘beta’, but will users really take that into account when they start bitching about it not doing something?  I guess only time will tell.

REALbasic and Cocoa Ruminations

Posted on by

There are hints from posters in the RB forums that they think that when Real Software releases REALbasic with Cocoa support that everything will be awesome and that it will be the second coming of sliced bread.  I hate to burst their bubble.

In their June newsletter, Real Software said that Cocoa was taking longer than they anticipated and would happen sometime this summer.  I read this as “not happening in R3.”

Before you get your panties in wad, the switchover from Carbon to Cocoa is ugly.  It’s not simple nor straightforward.  I predict that it will take at minimum two releases before it’s really usable and perhaps three before you can really release apps with it.  I say this not as someone who’s trying to bag on the engineers doing the work, I say this because it’s that big of a deal.

If RS only had to deal with Macintosh OS X it would be easier.  In fact, it would probably already be done.  However, since REALbasic is all about cross-platform, anything that’s changing for Cocoa will also affect Windows and Linux applications because all controls for Cocoa need to be updated so it’s a seamless as possible for those platforms.

Real Software is correctly taking their time with Cocoa support because it needs to be done correctly.  If not, we might as well start looking for another development platform.  It’s worth it for them to not rush Cocoa support and to get it done properly so that when we finally start using it it ‘just works’.  That still means that we (the developers using it) will find many, many issues that they’ll have to fix, tweak, and modify.

So be patient and be understanding.  RS has been planning for this transition for years now.  Will it be painful?  Probably.  Will there be outrage and indignation from certain segments of the community?  Count on it.  Will 3rd party controls, plugins and classes break?  Absolutely.  Will Cocoa be worth the wait?  I have no doubt because Apple has said that Carbon will go away.  And that you can take to the bank.