As I checked the bugs list, at least one bug regarding BiDi support (QC # 97965) is fixed in VCL Styles. No other BiDi related bugs are fixed in this update. Embarcadero staff mentioned in Embarcadero newsgroups that the company is planning to release monthly updates for XE2 product, so we should wait to see if any of the BiDi related bugs will be fixed in the coming updates or not.

• Added support for Win64 and Delphi XE2.
• Added TProcessItem.CloseProcess method to close a process normally (not forcefully).
• Added TProcessItem.CurrentProcess property. This property always refers to the current process in the list of running processes.
• Added PrivateWorkingSetSize property to TProcessItem.MemoryInfo.
• Added global  ProcessInformation function. This function returns a global instance of TProcessInfo. The instance will be freed when the application is terminating.
• Fixed a few minor bugs.

To download ProcessInfo 1.5, please go to ProcessInfo page.

First of all I should mention that I didn’t expect any BiDi support in this version, so my initial intention was to highlight the bugs for BiDi support in FireMonkey and report them to be hopefully fixed in the future releases. The first impression was that FireMonkey is not as bad as VGScene in supporting BiDi text. It was a surprise because I didn’t really expect any BiDi support after reading Andreano’s comment. There is very limited and half baked support for BiDi text in the initial release and it still has a long way to go for fully supporting BiDi text. Here I am going to discuss support for BiDi text in FireMonkey version 1.0, highlighting the bugs which should be fixed regarding this support, and the QC report regarding each bug.

Before I discuss BiDi support, I should mention that according to Michael Swindell, Senior vice president of marketing and product management at Embarcadero, FireMonkey will be updated frequently. The first update is expected before the end of September, and the other updates will be published more often than quarterly [Source]. That means, we will see several updates for FireMonkey before the new version of RAD Studio is published next year. That is really exciting and makes me very hopeful that all or at least many of the bugs mentioned here might be fixed before the next major release of RAD Studio in 2012. It is important to be hopeful about evolution of a product, and feel that your feedbacks are really considered by its developers. Years ago many of my friends tried to notify Borland about some of the existing bugs in VCL regarding BiDi and right-to-left languages support, but they never got fixed, and many of those guys migrated to .NET, abandoning Delphi. I myself stopped reporting any new bug to QC when Embarcadero deleted my EDN account just because my country in my profile was mentioned as Iran. Now I feel the team listens more to user feedbacks. It doesn’t really matter if I am Iranian or American or whatever when I am reporting a bug or when I am discussing some technical stuff. Anyways, that is another story and I discussed that in an older blog post. Let’s go back to FireMonkey and its support for BiDi text:

The first thing that I noticed in FireMonkey regarding BiDi support was a new BiDiMode property added to FireMonkey forms. This property determines if the whole form is right-to-left or left-to-right. When it is set to bdRightToLeft, it changes TextAlign property of the child controls inside the form, and set the text inside them aligned right to left. It also enables BiDi reading in the text for many of the controls so that a text containing a mixture of Latin and a right-to-left language (e.g. Arabic, Persian, Hebrew) characters is read correctly. If you remember from the older post on this subject, VGScene lacked such a feature. Having this effect makes FireMonkey a little more useful in right-to-left applications. At least in many cases your users will be able to read the text shown to them properly.

However the idea of having a single BiDiMode property to govern all the child controls inside a form is not practically appealing, because it is very common for a right-to-left from to contain Latin or numeric elements which should be laid out left-to-right rather than  right-to-left. Actually all FireMonkey controls should have a BiDiMode property governing the layout of that particular control and its children; something similar to BiDiMode property in VCL controls.

Another problem that is visible when BiDiMode of a form is set to bdRightToLeft is in the form title; the title is not BiDi-aware so if it contains a mixture of Latin and right-to-left characters, it will show the text incorrectly. Also layout of the title is not right; in a right-to-left window the default coordinates system starts from the upper right corner, form icon is on the right side of the title bar, form title is next to it, and window buttons (min, max, close) are on the left side of the form, that means mirroring the position of title bar elements. Right now the title bar for right-to-left forms are aligned the same way as left-to-right forms which is wrong:

BUG: FireMonkey form title does not change when BiDiMode is bdRightToLeft

VCL forms have the same problem. It gets even more irritating when you use a right-to-left VCL form with Ribbon controls; Ribbon application button overlaps with Close button, making it very hard for the user to click on Close button.

Now let’s see how child controls react when BiDiMode is set to bdRightToLeft. First of all, I checked TEdit control. It is the common control for receiving text input. There are two type of textual edit controls in FireMonkey; TEdit, and TClearingEdit. The latter has a button at the end of the control which clears the text inside the control, when clicked:

Right-to-left edit boxes in FireMonkey have a couple of minor visual bugs.

As you can see in the picture above, BiDi text is shown correctly in those edit controls, but they have two other bugs; first of all, when an edit control receives focus, the cursor remains on the left side of the edit box, blinking. The cursor should be at the right corner of the edit box when the control is set right-to-left. Even when an edit box is focused and input language is changed, if the input language is right-to-left, the cursor should jump to the right side of the box.  This false behavior is not exclusive to TEdit, actually all controls that receive text input (e.g. CombBoxes, Memos, etc.) have the same problem with their cursor position. The other problem is with TClearingEdit control; clear button inside the control should be positioned on the left side when text is right-to-left, and on the right side when text is left-to-right.

ComboBoxes have an additional bug beside the other one I mentioned for edits; the items in the drop down list are left-aligned and not BiDi-aware (i.e. mixing Latin and right-to-left characters destroys proper text reading):

BUG: Items are left-aligned and item texts are not BiDi-aware.

Unfortunately right-to-left Memo is useless in FireMonkey. This memo control is really buggy, even when it is not right-to-left. Anyways, as you can see in the picture below, a right-to-left memo does not show the text at all. The text is there as the cursor is blinking where the text is ended, but no text is visible:

BUG: Right-to-left text disappears in FireMonkey Memo control.

TreeView in FireMonkey acts similar to TreeView in VGScene, the items are right-aligned, but the arrow icon indicating each node sub-items, and the indentation for each sub-item are drawn on the left-side, making the right-to-left TreeView looking weird. The only improvement here is in BiDi text reading; as you can see in the picture, BiDi text is read correctly when Latin and right-to-left characters are mixed together:

BUG: Arrow icon and indentations for the sub-items remain on the left side.

As I mentioned in the first part of this investigation, it is been so many years that TreeView in VCL has problem with right-to-left too. I hope we see it fixed someday soon too.

TabControl in FireMonkey isn’t any better than PageControl in VCL; they both ignore right-to-left setting, and remain left-aligned:

BUG: Tabs are shown left-to-right rather than right-to-left

Now the menus; both FireMonkey and VCL have problem in showing right-to-left menus properly. They both draw the menu (either main menu or popup menu) left-aligned, so that the icon is shown on the left side of each menu item rather than the right side. FireMonkey has two additional bugs in its menu; first of all, BiDi text reading in the menu is not implemented, so mixing Latin and right-to-left characters in a text makes the text unreadable. Beside that, menu items in the main menu are always started from left to right:

BUG: Menus have no BiDi support and is left-aligned.

The last control I investigated was TStringGrid; TDBGrid in VCL was one of the rare controls which had nice right-to-left support, but such a nice support does not exist in FireMonkey; TStringGrid in FireMonkey can be attached to a dataset thanks to the new Live Binding feature, but columns are always drown left-to-right. What’s more, having separate BiDiMode property for each column is more important here, because each column might have right-to-left, Latin, or numerical data, and we cannot expect all such data to be aligned either left-to-right or right-to-left:

BUG: Grid columns are always laid out left-to-right

Conclusion

With all these bugs in right-to-left support, is FireMonkey 1.0 really usable for right-to-left applications? The short answer is, No. The longer answer is; there is some basic support for reading BiDi text, so at least you can have some single-lined text in your application. With this basic support you can create some limited demo applications or some trivial fun stuff, but not really any serious business application. However, as I mentioned earlier, the good news is that FireMonkey is supposed to be updated frequently, so we can be hopeful that many of these bugs might be fixed in the coming months.

In this article I mentioned many VCL bugs regarding right-to-left support too, I hope Embarcadero consider these old VCL bugs too, and fix them eventually.

Anyways, here is a list of QC reports regarding the bugs I mentioned in this article. If you need proper right-to-left support in your Delphi or C++ Builder applications, please take a few minutes, and vote for these reports in Quality Central, so that Embarcadero would deal with them more seriously:

• QC #98647: BiDi support in FireMonkey is broken.
• QC #97604: Cursor position always left with BidiMode = bdRightToLeft.
• QC #98644: All FireMonkey controls should have BiDiMode property.
• QC #98638: TMemo does not render BiDi text.
• QC #98770: Clear button is positioned incorrectly when BiDiMode is set to bdRightToLeft.
• QC #98771: ComboBox has no proper BiDi support.
• QC #98772: TreeView is not properly right aligned when BiDiMode is set to bdRightToLeft.
• QC #98773: TTabControl is not right aligned when BidiMode is set to bdRightToLeft.
• QC #98774: Both main menu and popup menu have serious problems in supporting bi-directional text.
• QC #98775: TStringGrid has no proper support for bi-directional text.

BTW, here is a request in Delphi UserVoice website demanding better support for bidirectional user interfaces in Delphi. Please vote for this one too:

• Better support for Bidirectional user interfaces

And here  is download link for the 30-days trial version from Embarcadero. Before installing the final version, if you already have XE2 beta installed, make sure you uninstall it completely and remove all of its folders which might remain undeleted; otherwise, you might have to deal with weird installation issues.

I hope this will be a new start for Delphi

Before I describe my experience with VGScene, let me explain what supporting bi-directional text really means, why is it important, and what kind of support for it exists in MS Windows…

What is support for BiDi , and why is it important?

First of all, you probably know that, not all languages in the world are written from left to right; a few languages including Arabic, Persian, Urdu, Hebrew, and Maldivian are written from right to left. Some languages like Chinese can be written in any direction; left to right, right to left, or top to down.

Displaying a right-to-left text in computers is not as simple as flipping the screen order, because in some cases, your right-to-left text may contain left-to-right character too. That way, either the left-to-right or the right-to-left characters would be displayed incorrectly. Such a text which is a mixture of left-to-right and right-to-left characters is called Bi-directional (BiDi) text, and supporting bi-directional text in computer means displaying and inputting BiDi text correctly. You can read more about it in Wikipedia.

But why is BiDi important?

Right-to-left languages are widespread in Middle East, North Africa, and Central Asia. Arabic has the third largest population of official usages in the world, after English and French, with 26 countries using it as their official language, and more than 280 million people speaking it as their first language. It is also language of Quran (Koran), the holly Muslims’ book. Quran and Islamic prayers are read in Arabic, so every Muslim in the world should have a basic knowledge of Arabic to say his/her daily prayers. Islam is the second largest religion in the world with more than 1.5 billion followers all over the world, and the one with the fastest pace of growth.

Persian is the official language in 3 countries with more than 100 million population. Urdu is the official language in Pakistan, with more than 60 million speakers. Hebrew is the Jewish language, and language of Torah. There are more than 13 million Jews around the world.

Summing all of these, more than 400 million people in 30 countries all over the world are using a right-to-left language as their first language, and more than 1.5 billion people are using a right-to-left language as their religious language.

From software development point of view, if you are writing a software targeting any market in Middle East, Central Asia, or North Africa, or writing a religious software for Muslims or Jews; you need BiDi support in your software.

BiDi support in Windows

Win32 always have had adequate support for right-to-left languages. Currently Windows supports Arabic and Hebrew scripts. Persian uses Arabic alphabet, so supporting Arabic is enough to support Persian too. Since Windows 2000, Windows started to fully support Unicode, which made supporting displaying and inputting right-to-left text in Windows easier. Win32 also supports right-to-left layout for controls and windows using some extended styles. Particularly, Win32 provides four extended styles regarding BiDi support in Windows controls:

• WS_EX_LAYOUTRTL
  Arabic and Hebrew versions of Windows 98/Me, Windows 2000/XP: Creates a window whose horizontal origin is on the right edge. Increasing horizontal values advance to the left.
• WS_EX_LEFTSCROLLBAR
  If the shell language is Hebrew, Arabic, or another language that supports reading order alignment, the vertical scroll bar (if present) is to the left of the client area. For other languages, the style is ignored.
• WS_EX_RIGHT
  The window has generic “right-aligned” properties. This depends on the window class. This style has an effect only if the shell language is Hebrew, Arabic, or another language that supports reading-order alignment; otherwise, the style is ignored. Using the WS_EX_RIGHT style for static or edit controls has the same effect as using the SS_RIGHT or ES_RIGHT style, respectively. Using this style with button controls has the same effect as using BS_RIGHT and BS_RIGHTBUTTON styles.
• WS_EX_RTLREADING
  If the shell language is Hebrew, Arabic, or another language that supports reading-order alignment, the window text is displayed using right-to-left reading-order properties. For other languages, the style is ignored.

Using these styles, you can have right-to-left windows and child controls with proper BiDi text displaying and input. Microsoft provided the same support for BiDi in .NET WinForms, and WPF windows too.

BiDi support in Delphi VCL

In Delphi, BiDi support is basically provided in TControl class by exposing BiDiMode property which specifies four different modes of displaying and layouting controls for left-to-right or right-to-left text. Beside that, TWinControl class provides FlipChildren method which flips children of a container control from left to right or vice versa. Also TApplication class has two properties; BiDiKeyboard, and NonBiDiKeyboard which specify keyboard layout which should be loaded automatically based on a BiDiMode value of a control when user focuses on that particular control. For example, you can specify Arabic layout code for Application.BiDiKeyboard, and English layout code for Application.NonBiDiKeyboard in your source code, and whenever the user focuses on a right-to-left control in any of application forms, the active input keyboard changes to Arabic, and when he/she focuses a left-to-right control, the active input keyboard changes to English. Take note that Application.NonBiDiKeyboard and Application.BiDiKeyboard are kinda useless in Windows Vista and Windows 7, because they call LoadKeyboardLayout API function every time a control is focused, instead of ActiveKeyboardLayout API, and in such versions of Windows that causes a big delay which makes the forms load slower, and flicker when focus is changed; but that is another story.

There are some other methods and functions in VCL that can help you to write a BiDi-enabled application. You can read more about BiDi support in VCL in RAD Studio documentation.

As you can see, BiDi support is built into VCL deep from its base class for all controls. The problem is that, not all controls in VCL hierarchy implement this feature properly; that means, there are many different controls that while being created or being drawn, do not take BiDi support into consideration, so changing their BiDiMode property have no effect on them, or in some cases brings up unexpected behaviors. For example, attaching a right-to-left DBGrid to ClientDataset will draw the grid totally useless:

Left-to-right DBGrid with BiDi text.

Right-to-Left DBGrid attached to ClientDataset

Setting BiDiMode for Delphi Ribbon, or PageControl, or TreeView control has no effect on them. PageControl and TreeView are standard Windows controls with support of right-to-left layout, but they are not wrapped properly in VCL:

VCL: BiDiMode is set to bdRightToLeft, but PageControl is still left-tot-right.	WinForms: TabControl is properly set to right-to-left alignment.
VCL: BiDiMode is set to bdRightToLeft, but TreeView, and CategoryButtons are still left-tot-right.	WinForms: TreeView is properly set to right-to-left alignment.

Sometimes setting BiDiMode for a control to bdRightToLeft makes its text BiDi-enabled, but the control itself is not layouted right-to-left:

BiDiMode is set to bdRightToLeft, but main menu control is aligned left-to-right.

WinForms: Menu is properly set to right-to-left alignment.

BiDi support in third-party components is not consistent either; some components like FastReport have very nice support for BiDi text. Raize components are usually good in right-to-left layout thanks to their custom rendering methods. VirtualTreeView and EhLib have nice BiDi support too. I like TMS components a lot, specially their Smooth Controls, but BiDi support in TMS components is weak, except their grid component. I don’t use DevExpress components, but I heard their components are quiet good in handling BiDi.

BiDi support in KSDev VGScene

OK, examining this one was the main reason of writing this blog post; the truth is, unfortunately, VGScene has no BiDi support, yes you read it right, NO support. I checked properties in VGScene controls several times; no such BiDiMode, or RightToLeft, or RTL property exists. VGScene is not able to render BiDi text properly, or set proper right-to-left alignment for its controls.

There is a property called TextAlign in some controls, at first I thought that is the property I was looking for, but later on I found out it just aligns text in the control to either left or right side, but does not set text direction accordingly, that means no BiDi support!

If you don’t know Persian, you might think text in the pictures below is drawn correctly; however, if you look carefully, you will notice the dot (.) character at the beginning of the right-to-left text in VGScene screenshot. You may also notice that text shown in VGScene is not the same as the text in WPF.Actually the text in WPF screenshot means “This is a Test”, and Test is written in English while the rest of it is written in Persian. The text in VGScene screenshot is meaningless; that is because VGScene has no sense of BiDi, and when you mix a Latin character or punctuation symbol with your right-to-left characters, it draws the whole text as a mess.

VGScene

WPF

Well VGScene is not able to properly change layout of a control to right-to-left either. The screenshot below shows two TreeView controls in VGScene, in the left control TextAlign is set to left, and in the right control it is set to right. As you can see, when you right-align a treeview item, its text goes to the right side, but the arrow icon and children indentation remain on the left-side, making the TreeView to look something like a simple ListBox:

Even if TextAlign property was supposed to be a property to define BiDi mode, Unlike BiDiMode in VCL or RightToLeft in WinForms or FlowDirection in WPF, it does not affect other controls hierarchically; that means, you should set it for every control separately, even in TreeView case, for every tree node.

For VGScene to support BiDi mode properly, it needs to add a property similar to BiDiMode in VCL in the base control class, and it should change the code for drawing a control or its text according to the value of this new property. How WPF implemented support for BiDi mode in the user interface can be a good template for modifying VGScene (or FireMonkey) to properly support BiDi text. You can read more about BiDi support in WPF here: Bidirectional features in WPF overview.

Conclusion

It is obvious that BiDi support was not a goal in VGScene design. VGScene is not in development anymore. It is sold to Embarcadero, and now its sequel is called FireMonkey. As I mentioned earlier, it is not clear whether FireMonkey will bring proper support for BiDi text or not. I am personally doubtful about it; because some of the new VCL controls are designed with no BiDi support in mind, and many obvious BiDi-related bugs in the older controls are remained unfixed for years. To me that is an indication that such a support is not a big concern for Embarcadero developers. What’s more, Andreano Lanusse somehow ignored answering my question regarding this support in FireMonkey, which can be another indication that such a support does not exist. I really hope my doubt is proved wrong, because if BiDi support in FireMonkey is the same as what I saw in VGScene, this tool will be useless in BiDi environments.

Update (08/24/2011)

As you can read in the comment; Andreano Lanusse from Embarcadero confirmed that FireMonkey in RAD Studio XE2 will not have BiDi support, but they included it in their RoadMap. The roadmap is not  published yet, thus we gotta wait for it and see when is BiDi support supposed to be included in FireMonkey. I hope they do it in an update pack for XE2 rather than postponing it to future releases of RAD Studio. Here I also should appreciate Andreano’s efforts for informing me and trying to include this feature in their roadmap.

It was obvious that XE2 will bring 64-bits support to Delphi, along with supporting Mac OS as a new target platform. Mac OS support was supposed to be added to Delphi XE, but it was postponed to this release. Although 64-bits and Mac OS support are cool, they were both expected. The big news was FireMonkey!

When Embarcadero announced their plan for adding Mac OS support, the original plan was a continuation of the old CLX framework which was based on Qt. The difference was, the new CLX was supposed to bring just cross-compiling for Mac OS (and later on Linux), not like original CLX which had a Linux-based IDE (Kylix) for compiling the same source code for Linux. However the plan changed, Embarcadero bought KSDev company, creator of VGScene and DXScene components, and hired its programmer. They decided to provide a vector-based, GPU accelerated, cross-platform GUI framework based on the recently bought KSDev products; and that is FireMonkey.

FireMonkey is the new cross-platform GUI framework for Delphi. You can create Windows (32-bits, 64-bits), Mac OS (32-bits), and iOS (32-bits) applications using FireMonkey in Delphi XE2. iOS addition was a surprised, and I didn’t expect it; although it is not a direct compilation to ARM code. Actually you have to export your iOS code to a XCode project, and compile it with XCode, to be able to run it on your iPhone or iPad devices. Also, 64-bits support for Mac is not ready yet. It seems they are still working on it.

On Windows platform, FireMonkey uses Direct2D for 2D renderings, Direct 3D for 3D renderings; and OpenGL on Mac OS. If Direct2D is not available, FireMonkey will fall back to GDI+ to render the GUI.

Here is a video by Andreano Lanusse demoing 3D capabilities of FireMonkey on Windows, Mac OS, and iOS :

You can also read more about FireMonkey on Andreano’s weblog (Do not miss the comments) :

A little bit about FireMonkey and Delphi XE2

However that is not the whole story; in XE2 we don’t need to deal with a separate set of components as data-aware components. Now in XE2 we will have Live Binding. It means we can bind any data source to any visual control. If you are familiar with .NET controls, you probably saw this binding property. Now the same thing exists in Delphi too.

What’s more, DataSnap and DBX are also enhanced; for DataSnap, AFAIK, proxy class generators are added for many platforms (i.e. Android, iOS, JavaScript, .NET, BlackBerry, etc.). Also I heard some features are added for deployment to could.  For DBX, it seems a driver for ODBC is added.

Beside all of these new features, the popular reporting tool, FastReport, will be shipped by default with Delphi XE2 too.

There must be many enhancements and additions to Delphi RTL too, but I haven’t heard anything about them yet. So we have to wait for other worldwide tours Embarcadero is conducting in August to get more detail information about this exciting release.

It seems XE2 might be the most significant Delphi release in the past decade. It is not officially announced when XE2 will be released, but I can guess it will be some time in September.

http://www.embarcadero.com/products/delphi/64-bit

According to their latest published Delphi roadmap by Embarcadero, they had planned a beta version of the 64bits compiler to be released in the first half of 2011. Currently there is only a sneak preview video available, but you can fill a form to receive more information, or participate in its beta testing program. Seems this time Embarcadero are stick to their published roadmap, unlike what we saw for Delphi XE release.

ProcessInfo 1.3 is released. The changes in this release are:

• CPU usage is added to TProcessItem.
• Is64Bit is added to TProcessItem.
• IsAccessible is added to TProcessItem.
• Setting thread priority is added to TThreadItem.
• Setting process base priority class is added to TProcessItem.

To download ProcessInfo 1.3, please go to ProcessInfo page.

You might have thought it is your ISP, or maybe Iranian filtering system, or maybe your browser, which are causing the problem, because other visitors are using the website with no such problems, and nobody has reported such problems. Well, if you thought that way, you are wrong!

It was some months (or maybe a year) ago that I noticed I cannot log into Embarcadero forums (web interface for their newsgroups). It was telling me that my username\password was not valid! I retried my username\password several times, and even tried to make it to email me my password, but no success! Eventually I decided to create a new username, and tell them about my problem in the forum, but when I was creating the new account, I noticed that Iran is not in Countries list, and I have to choose another country if I want to create an account in their website. It was there that I found out they deleted my previous forum ID without any notification just because Iran was chosen as my country!

Days passed and April 2010 came, I noticed that some Iranian Delphi developers were reporting problems about accessing EDN (Embarcadero Developers Network). EDN provides some articles, news reports, and white papers about Embarcadero products for software developers. I thought it must have been some ISP problems, but since I wasn’t sure, I created a topic in Embarcadero forums, and asked if EDN is down. Some users mentioned they have no problem accessing it in Europe, and later on, my topic got deleted from their forum, and I received an email from one of Embarcadero employees that this is due to their respected company’s policies in complying with US embargo, and I should keep it as a confidential note!

Now it’s been some days (maybe 1 or 2 weeks) that I found out accessing weblogs belonging to Delphi team members on Embarcadero website, and also documents wiki website (online version of Delphi documentation) is not possible from Iran.

So, if you use any of Embarcadero products (either buying it legally or not) and you travel to Iran for a visit or live in Iran, you are not allowed to check their website, their weblogs, or their online documentations, put aside downloading trial versions or updates from their website! OK, they say it is so to comply with US embargo against Iran, but it is weird, as far as I know, when someone does something nice and according to law, they must be usually proud of it, but Embarcadero is not (!!) because they do not like you to know that they put such restrictions on some people; they do not bother redirecting you to a page saying this content is not available to you due to US embargo. They rather you think it is a server or Internet connection issue, not an organized restriction imposed by the company. That’s why you don’t see any explanation from them, or you do not receive any notifications when your accounts are removed from their website, or your post gets deleted when you ask them about it in their forums.

It is also interesting to know why they are restricting access to such contents as online help or their employees weblogs? Because if they are following US laws, then banning product downloads from Iranian IP ranges should be enough. Why banning access to developers’ weblogs or online help documentations?! Companies like Google, Oracle, or Yahoo impose restrictions on downloading their products to Iranians too; for example you cannot directly download Google Chrome, or Yahoo Messenger from Iran, but they do not restrict their employees weblogs, or announcements for new coming products. Actually it seems Embarcadero likes ambiguity, as they expressed this interest in their published roadmap which was more confusing than clarifying. You can read about it more here.

Maybe the reason Embarcadero decided to ban their website content on Iranians was popularity of Delphi in Iran, and they thought making such restrictions make Iranian people feel the pressure more, and as you might know, US government believes such stupid pressures will eventually lead to people uprising in Iran, and making the country to agree with US demands! I know you might say nowadays Delphi’s popularity is not as before, and Visual Studio and .NET are currently the most popular development tools there, but so far Microsoft hasn’t imposed so called US embargo on Iran that way; that is they do not sell their products in Iran, but they haven’t banned MSDN or their download pages, or their online services for Iranians yet. So if they are supposed to put pressure, why not restricting Microsoft contents in Iran? Maybe Microsoft is kept for later stages of pressure on Iranian people, or maybe they are afraid if they ban very popular websites or tools, the result might get reversed, and people might feel more enmity toward US government.

BTW, If you are a software developer in Iran, you already know how to nullify so-called US sanctions; so I didn’t go for explaining how to do so!

I have a lot to say about US embargo against Iran, that I think I should write about in another post some other time.

Have Fun!

P.S. 1. Today (May 26, 2010) I tried to read Craig Stuntz’s blog post on TeamB website, and this site makes the same restrictions on Iranians as official EDN website. So you can add TeamB to the list too.

P.S.2. Today (June 18, 2010) I found out Embarcadero forums are added to the restricted websites too. If Embarcadero had took developing their products as seriously as they took banning Iranian users, they would have probably had better products by far!

I don’t know if we can call it a roadmap or not. It does not give any time schedule or estimation on when each mentioned feature might be available (except a rough estimation for 64-bit compiler preview availability in the first half of 2011). To me, the published roadmap does not clear any ambiguity regarding Delphi future. It just adds more to it! Really, what was the purpose of publishing this?! Maybe just to  muffle those Delphi users who were complaining about not having any updated roadmap.

Now, let’s take a look at this so-called roadmap…

I skip those unnecessary slides which say the focus of product in future is on this or that, because as far as I know, almost all RAD development tools focus on stuff like better performance, Rich GUI, Cutting-edge data access, and so on. So to me, such pages don’t add anything to reader’s knowledge about the product.

Then in page 8, we see the the projects R&D team are working on:

• Fulcrum
• Wheelhouse
• 64-bit compiler preview
• Commodore
• Chromium

According to other pages in the roadmap, and what we already heard from Delphi team, there are teams working on these projects in parallel. This is good that they are working on these projects in parallel, but that adds some more ambiguity, because you don’t know what features of which project will be available in each release. For example Chromium is the last project in the list, and one of the features it will focus on is documenting OTA. Since the works are done in parallel, then they might finish documenting OTA while the main focus is on the Fulcrum or Wheelhouse or Commodore. So you might see OTA documentation released with one of the earlier projects. It can be taken the other way too, you might see a feature in Fulcrum or Wheelhouse projects not being ready at the time they are supposed to be, and postponed to Commodore or Chromium, or post-chromium release!

So you have no time frame, and no info when each mentioned feature is supposed to be released. Your desired feature might come into product in a few months to a couple of years (maybe even more, who knows?). I don’t know why Embarcadero likes to be so ambiguous!

Project Fulcrum

The main focus right now is on project Fulcrum. It is said that Fulcrum is currently in private Beta phase, and will be available as public Beta some time soon, and will probably go Final in summer. According to the roadmap, the main theme of Fulcrum is building cross-platform applications. The old roadmap was mentioning Windows, Linux, and Mac OS X, but the new roadmap only talks about Windows and Mac OS X. There is no Linux. Linux support is postponed to Wheelhouse project. It is not clear if at least building console applications in Linux is supported in Fulcrum. But it is clear that even Mac OS X support is about client applications in Fulcrum, and you can’t use technologies like DataSnap servers in Mac OS X until project Wheelhouse is released. So again Embarcadero is proving that they are not good at setting  project goals, and estimating projects. As we saw with 64-bit compiler, Linux support will not be available on time, and is going to be postponed. It might be available very soon after Fulcrum release, or it might go the same path 64-bit compiler went, and be postponed for a couple of years. No one knows.

Beside its main theme, Fulcrum is supposed to bring some other features to RAD Studio. First of all, it is mentioned it will provide remote debugging for Mac OS X. I don’t know why is this mentioned here because when they mention they are going to target Mac OS X platform, then they either provide a Mac-based IDE, or a Windows-based IDE cross-compiling for Mac OS X. They took the second approach, and with that, it is obvious that they should provide a remote debugging mechanism. It is a must-have feature for a cross-compiling tool, not a subsidiary feature.

Then we have “Cross-platform VCL-like component library. According to Michael Rozlog in his interview with Jim McKeeth for Delphi Podcast #37, this cross-platform component library is a continuation of CLX library which was a wrapper for Qt GUI framework back in Delphi 6 and Delphi 7. There are no further details about this CLX based component framework except that again according to Michael Rozlog, most of old CLX based Delphi applications should be able to upgrade to this new framework easily, putting aside Unicode migration which is a different story.

The other feature which is supposed to be available in project Fulcrum is better integration with version control software, specially Subversion. It seems OTA is extended to provide a better version control support, and a SVN integration extension will be published with RAD Studio using the new OTA features. According to Nick Hodges in Delphi Podcast #40, this SVN extension is based on open-source DelphiSVN project, and will be published as an open-source tool. The good thing about this new feature is that it will be integrated into History tab of code editor. It seems cool!

Another feature in project Fulcrum is supporting UML Sequence diagrams. That’s good, but well it’s been a while that I use Model Maker for modeling. I do admit that modeling support in RAD Studio 2010 is also very cool.

Next feature is Automatic unit test generation. This is another unclear feature. What is this feature supposed to do?  Automatic unit test generation is already integrated into Delphi using DUnit. What extra stuff is this feature supposed to bring to RAD Studio?

Again another unclear feature is “RESTful Server creation”. This is already provided in RAD Studio 2010, and it is not clear what other stuff regarding to RESTful servers are going to come with project Fulcrum. I think Embarcadero should had gone into more details with these two features in their roadmap.

And the last feature mentioned in project Fulcrum is supporting cloud computing by providing Microsoft Azure integration, which is a nice addition to project Fulcrum.

Project Wheelhouse

Project Wheelhouse is supposed to bring full Linux support to RAD Studio. It will also complete Mac OS X support by providing server side support on both Linux and Mac OS X along with Windows.

64-bit Compiler Preview

64-bit support will not come to RAD Studio sooner than the first half of 2011. Even at that time, you will have a command-line only compiler preview. It is not clear how this compiler preview is going to be shipped; Are Embarcadero going to release a new Delphi version in 1st half of 2011? Or are they supposed to release this compiler preview as an update? As far as I know, they do not ship new features in updates, and usually RAD Studio is released once per year.

Project Commodore

I’m not going to spend that much time on project Commodore and Chromium, because they seem far away, and probably will see many changes in future. Project Commodore is supposed to bring full 64-bit compiler support. If you follow Delphi news, then you probably know project Commodore from previous Delphi roadmaps. It’s been a couple of years that Commodore is there on the roadmap. According to previous roadmaps, we should have had it in 2010, but now according to the current roadmap, it is at least 1.5 to 2 years away from us.

Better multi-core support, and Delphi Parallel Library are other features being worked on in project Commodore. I hope we see DPL sooner; because within 2 years a parallel library wouldn’t be considered as an advantage, but a must-have feature. So it wouldn’t be an advertising point for Embarcadero in 2012 to say, hey we also have this cool parallel library in our product!

Social Networking Integration is another feature for Commodore. Again this is a cool feature if delivered on time, otherwise it wouldn’t make any advantage for Delphi.

And the last feature mentioned for project Commodore is  Better Documentation. I hope they don’t mean people should wait at least 2 years to have better documentation in RAD Studio! It seems this is one of those features that we probably will see sooner, because as we saw in RAD Studio 2010 documentation, the documentation team is working hard to provide better documents in each release, and even with help updates.

Project Chromium

Well, this one looks so far away. This project is supposed to enable Delphi target other hardware platforms rather than Intel X86. Specially mobile platforms. It is also supposed to provide better support for other natural inputs (beside gesture and touch) like voice, video motion, and location (probably supporting GPS in mobile devices). These stuff are cool, but it is not clear or even estimated when such things are supposed to be provided.

Some other features in project Chromium are already being worked on, and we see their progress in each release; like improving look & feel of VCL controls, and IDE, or more integration with database tools. I also expect OTA documentation to be available sooner than other features in this project, and I guess we will see it in the next release or the release after next release (This is just an assumption).

DataSnap (Adaptive) Application Server, and Extended RIA Approach are also mentioned in Project Chromium, but again they lack any detailed specifications.

So it was my take on the newly published document, called roadmap, by Embarcadero. If you want to make any estimated plan for your carrier with Delphi, this document is, to me, quiet useless, and doesn’t really give you any insight.

Entry-level SKU

As you might know, one of the recent hot debates in Delphi community was around Embarcadero providing a free or cheap entry-level SKU for RAD Studio. Michael Rozlog mentioned in his Delphi Podcast #37 that they are working on it, and probably we will see that in next major release which is project Fulcrum.

But according to Nick Hodges in Delphi Podcast #40, they haven’t made their mind yet, and it is not still clear how this entry-level SKU would be. But something is clear; a free version is not on the table anymore. They are just working on a cheap entry-level SKU which its specifications are still unclear. So we won’t see free Delphi anymore!

I hope at least they provide the command-line compiler free, and make it available in all three major platforms they are going to support (Windows, Linux, Mac OS X). This way hobbyists and students could use a free editor like NotePad++ and write Delphi code on their preferred platform for free.

Regards