In a previous blog post we already took a first look at “Fix-It” support and some related editor enhancements centering around error reporting that are coming to Prism XE2 and Project Cooper later this fall.

Today, I want to focus on one specific new detail in error reporting that – while not technically tied to fix-it – certainly is made possible and useful by it. And that is spell checking, or more precisely the detection of mistyped identifiers or keywords by the compiler.

As most of my readers know, my own typing skills are particularly bad , but I would wager that almost everybody mistypes a type name once in a while. So let’s say you’ve declared your new variable of type “Stirgn” when you really meant “String”, and all hell breaks loose: not only do you get a compiler error for the bad name (as you rightfully should), but chances are that all throughout your code, you’re getting dozens of extra (and usually bogus) errors about all those valid members of String supposedly not being defined. What’s worse, as you plow on through your code, Code Completion is broken too, so you need to stop typing, build your project, find the error and fix it to continue to be productive.

All that is a thing of the past with Oxygene 5’s new Spellchecker feature, as can be seen in the following screenshot:

As described, I (deliberately, I promise!) mistyped “String”, so my code has problems. The screenshot shows three individual aspects of how the spellchecker improves your development life in this situation:**#1**: In addition to telling you “sorry, I really don’t know what you mean by ‘Strign'”, the compiler recognizes that there actually *is* a type it does know that sounds pretty similar, so it suggests “Hey, did you by any chance mean to type ‘String’, instead?”, and offers you to fix the typo for you with a single click. That’s pretty cool already, but since you’ve [seen Fix-It support before](, this is pretty much what you expected when you read “spellchecker” in the headline. Meh.

But let’s look on:

#2: As the code continues, there’s two lines of code that try to call methods on our “x” variable. Using old Oxygene (or any other number of languages), you’d get two errors on this code, as the compiler would tell you that, since it doesn’t know what type “x” is, it certainly won’t let you call “ToLower” or “ToUppper” (sic) on it. Which is silly, if you think about it – if the compiler doesn’t know what type “x” is, how can it even begin to know what you can or cannot do with it?

Oxygene 5, instead, gives you only one error, on the call to “ToUppper”. Which makes sense, because “ToUppper”, with three “p” doesn’t actually exist on Strings, and the compiler figured, from the previous error, that “x” pretty likely is supposed to be a “String” (had we not mistyped “ToUpper”, there would’nt be any follow-up errors at all).

There’s really two benefits here, disguised as one: (a) you’re not getting overloaded with bogus error messages that are follow-ups of a badly typed name and (b) much more importantly – you do get reliable error messages for things that actually are wrong. So you can fix both typos in one go and move on (normally, you would most likely have missed the error on “ToUppper” until you fixed the first one and hit rebuild again).

Note that, indicated by the little “Magic Wand” icon, the spell checker of course kicked in for “ToUppper” as well; if your code had been more complex, say assigning the result of “x.ToUppper” to a new variable and doing more work with it, all of these benefits would keep cascading down into the rest of your code.

#3: Finally, and an improvement that’s very dear to my heart, you see at the very bottom of the screenshot that Code Completion is fully functional on “x” as well. That’s a huge productivity boost, as you can keep writing your code, and deal with the typo once you are finished – while under the old compiler, you would have to stop your current thought process, hit build (possibly, to even find the error) and fix the error. That, or carry on writing code without useful Code Completion, which is never nice.

Being the keyboard-dyslexic I am, I am really excited about these enhancements to the coding flow, and I’m sure I will benefit from this daily, if not minutely. I hope you will find this helpful, as well – let me know what you think!

Stay Tuned for More

Read more about Delphi Prism at
Read more about Project Cooper, currently in beta, at