I am using XE2 since it is available to me, but the stuff I am doing at home is different from the stuff at work and also different from the stuff my co-worker is doing. We have switched to XE2 almost two weeks ago and thatswhy we discover some more XE2 issues now. Here are some of the issues we discovered and I try to provide some information that may help you to help yourselfs when you are affected by the same issue. If this information is not enough for you – I am sorry, but I cannot and will not provide “works for everyone” solutions here. I am glad that we solved the issues for us. There might me more posts about XE2 issues and so I have added the “Part #1″ to the subject. This time the topics are:
and apart from the last issue these issues are new in XE2. There are not that much QC reports mentioned in this post, but Embarcadero knows already about most of the mentioned issues.
TDBNavigator glyphs
The TDBNavigator got new glyphs in the XE2 release and the following screenshot shows the difference between XE and XE2.

Delphi XE TDBNavigator at designtime without a TDataSource assigned

Delphi XE2 TDBNavigator at designtime without a TDataSource assigned

Delphi XE flat TDBNavigator at runtime in browse mode

Delphi XE flat TDBNavigator at runtime in edit mode

Delphi XE2 flat TDBNavigator at runtime in browse mode

Delphi XE2 flat TDBNavigator at runtime in edit mode

Delphi XE2 flat TDBNavigator at runtime in browse mode with non default colors
The opinions of the team members that used the XE2 build of our application were different regarding this new glyphs:
Well these icons does not look bad, but which meaning do have the colors?
I see blue, aqua, a mixture between red and orange, green and red. My co-worker started with the following guess
blue are harmless actions, red are harmful action
well but is adding a new record something bad or posting a record necessarily something good. Hey Embarcadero please explain!
It is hard to see the difference between the enabled and disabled Post button!
I have to add here that this team member is affected by partial red-green color blindness. (in german it is “Rot-Grün-Sehschwäche”)
The shadow looks ugly with non default colors. Haven’t they still fixed alpha transparency issue.
This is from co-worker, he does have non default colors and we have had looked into an alpha transparency issue with TSpeedButton sometime ago with 2010 or XE. I think due to other more important stuff I have never looked if there is already a report for this and so on. As you can see above on the last screenshot the shadow looks very ugly with non default colors.
In order to fix the issue I have replaced the resources in $(BDSLIB)\win32\release\dbctrls.res with the resources from the XE release and copied it to the win64 folder as well. Well XE does not have resources for the new ApplyUpdates and CancelUpdates buttons, but we do not use them. Other options would be to patch TDBNavigator.SetButtonGlyph at runtime or to create a TDBNavigator descendant and override TDBNavigator.SetButtonGlyph. In the IDE are still the new icons, but that does not bug us and if we want to have fancy new TDBNavigator glyphs we can have them when we start using VCL styles.
The good thing about the XE2 TDBNavigator is the new property Kind and now one can have a vertical navigator out-of-the-box.
TRect scope issue (Delphi lib recompiling issues)
The TRect record and other records do now have some additional methods and properties. TRect for example does have the properties Width and Height. At first that does sound like something good, but in combination with the “with” statement it can be something very bad and may cause failures in your application. Since the reason for a failure was a TRect scope issue did I want to identify such scope issues by the help of the compiler. In order to achieve that I have changed the following piece of code in $(BDS)\source\rtl\sys\System.Types.pas from
TRect = record
...
// changing the width is always relative to Left;
property Width: Integer read GetWidth write SetWidth;
// changing the Height is always relative to Top
property Height: Integer read GetHeight write SetHeight;
...
end;
to
TRect = record
...
// changing the width is always relative to Left;
function Width: Integer; deprecated 'Check TRect.Width scope';
// changing the Height is always relative to Top
function Height: Integer; deprecated 'Check TRect.Height scope';
...
end;
Since System.Types is part of the Delphi core RTL it was necessary to recompile the RTL. That can be done with the batch file $(BDS)\source\rtl\buildrtl.bat, which is provided since XE2 Update #2. Even that step was not free of issues for me – the build process did not found the zlib C object files. I had only Delphi (Pro) installed at work and since I was sure that I had successfully rebuild the RTL at home I tried to add C++Builder too via the installers upgrade function, because C++Builder installed yes/no was the difference between the installation at home and at work. The upgrade somehow failed, because bcbwin32.7zip could not be downloaded correctly and even before I have started the setup it was in the download folder. I had to abort the installation, my Delphi installation was completely broken and I have reinstalled Delphi and C++Builder. Afterwards the batch file recompiled the important RTL files and stopped with a problem in a Winapi DirectX unit, but did not care about that. Then I tried to compile our application, the compiler told me that there is a problem with the TeeChart units and that is completely okay – when you want to repeat the steps you need the source of all the components and there is no source provided for the TeeChart Embarcadero edition. TeeChart was only used in a few units and I just removed it in this units. Then another Delphi installation issue did bite me – the C object files for Vcl.Imaging.jpeg are not delivered even not when C++Builder is installed, I did use the files from Delphi XE and faked three missing methods.
Side note: I hate such delivery issues and over the years I have told Embarcadero several times the automation steps that would catch almost all source or lib file delivery issues. Great for you Embarcadero that you have all the files you need.
Well back to topic – afterwards I continued the attempt to compile our application and actually found some TRect scope issue, but not in our code. I found one issue in Vcl.DBGrids in the WriteText procedure and some other issues in 3rd party components. This WriteText issue might be only in theory an issue, because the code branch might never be execute – is there a way to make the following “if” be False?
I := ColorToRGB(ACanvas.Brush.Color);
if GetNearestColor(ACanvas.Handle, I) = I then
How get the TRect scope issues detected by the change?
Actually my changes detect the usage of the new TRect properties, but for code that compiled with pre XE2 releases it means in almost any case that there is a TRect scope issue. When TRect.Width or TRect.Height are accessed then the compiler puts out the warning
[DCC Warning] Foo.dpr(line): W1000 Symbol 'Width' is deprecated: 'Check TRect.Width scope'
and that tells you that there is supposed to be a problem. To make sure that there is actually no problem in our code I have just placed some sort of elephants in Cairo.
“Package Foo.bpl can’t be installed because it was created with a different version of Delphi or CBuilder.”
That the Delphi reinstallation did not make me too angry is just a result of the fact that I have build an installer that does setup the IDEs paths, compiles and installs the component packages and compiles the library DCUs for the components. However we had not installed all the necessary components in the IDE from the very beginning and once when adding some missing components I forgot to add a package to the requires section of the package with our own components and received the message
“Package Foo.bpl can’t be installed because it was created with a different version of Delphi or CBuilder.”
when starting the IDE.
Hey I have just compiled all the packages with XE2!
Actually the message is trying to say that our package did contain an unit that is also included in another package. So when you receive that message it maybe actually because of a duplicate unit issue. The best advice I can give you here is that you try to compile the package in the IDE and hope it tells you which packages needs to be added to the requires section.
I have not checked with XE2 versions before Update #3, but at least XE showed the message
Cannot load package ‘%s.’ It contains unit ‘%s’, which is also contained in package ‘%s’
and so this is regression. That message is still in System.SysConst.pas in XE2.
BTW, it is “cannot” and “C++Builder” and not “can’t” and “CBuilder”.
F12 performance
We do use data modules and in contrast to XE switching between Code and Design for them is very slow. It seems to be the slower the more components are on a form, frame or data module. Since fields on a data module are components too a data module can have a lot components. It is also the slower the more components are installed into the IDE and the time to switch seems to be the product of the amount of installed components and the amount of components on form, frame or data module. I have debugged the IDE with the IDE and have hit F12 to break into the debugger to find out what the IDE is doing when switching between Code and Design and yes F12 is the key to switch between Code and Design and when running under the debugger I have used the menu to switch. (Note the F12 debugger hotkey requires Andy’s “Delphi F12 Debug Hotkey support” expert when using Windows 6.x.) Whenever I hit F12 I saw the method “@Comppalmgr@TComponentPalettePageItemDelegate@CheckValid” in delphicoreide160.bpl. That lead me without a look into that method to the conclusion that the IDE is filtering the available components. That also explained why setting the ClassGroup property improves the switch times. Without that set the switch took about ten seconds for our largest data module and after setting it to Vcl.Controls.TControl it took about three seconds. That is still pain and so I have looked into “@Comppalmgr@TComponentPalettePageItemDelegate@CheckValid”. I did not try to find out how it is actually working, because understanding assembler is not my easiest exercise, but what I understood was enough to fix the issue for our needs. The solution has a lot disvantages, but they do not affect us because we do only develop for Windows with the VCL and seeing TButton on the Tool Palette or Component Toolbar for data modules is absolutely no problem for us. The rewritten version looks like this and brings for us the speed back to the XE level.
procedure NewCheckValid(Self: TObject; const AIntf1: IInterface;
const AW: WordBool; AIntf2: IInterface);
var
ComponentPalettePageItem: TObject;
PIntf: IOTABasePaletteItem;
begin
ComponentPalettePageItem := TObject(PDWord(Integer(Self) + $30)^);
if Assigned(ComponentPalettePageItem) and
Supports(ComponentPalettePageItem, IOTABasePaletteItem, PIntf) then
PIntf.Visible := Assigned(AIntf1) and
(Pos('TComponentBased.FMX', PIntf.IDString) = 0);
end;
The advice I can give you regarding this issue is setting the ClassGroup property of the data module.
Excel automation
One of the first bug reports that came in for the XE2 build was about the export to Excel. It failed with “Add method of Workbooks class failed”. I know that there is a dataset to Excel function in the JVCL (ExportDataSetToExcel in JvgExport), I have tried it and it worked. The difference between our code and the code in the JVCL is that we pass xlWBATWorksheet as parameter. After removing the parameter our code worked too, but now there were three worksheets instead of one. I did remember a thread in embarcadero.public.delphi.oleautomation, which I have had “read” a few days ago and did remember something about a change in XE2 regarding the passed parameter type. I have changed the following code from
XLApp.Workbooks.Add(xlWBATWorksheet);
to
XLApp.Workbooks.Add(Integer(xlWBATWorksheet));
and afterwards it worked with that Integer typecast. The thread is “EOleException on XE2 Update 2 (works fine under XE)” and this particular message from the helpful Bruneau (Jean-Marie Babet) explains the problem and provides workarounds. Some hours after I have made the fix Bruneau posted a promising message in this thread that there might be an option (System.Variants.DispatchUnsignedAsSigned) in the next update which enables the old behavior. Meanwhile there is a section about the problem and this option in the preliminary Update #4 release notes. My suggestion is that you test your Excel automation code properly and in case of problems use one of the workarounds provided. In case you would have to touch too much calls then hope that the DispatchUnsignedAsSigned is actually in the Update #4 release.
Open File At Cursor
We do have not added our own (component) library units with the “in” clause to our projects. Their path is in the IDEs library path and for some reason trying to open these units ended up with the open dialog poping up and showing “LibUnit” without the “.pas” suffix. That was an ugly issue in Delphi 2007, had been fixed Delphi 2009 and still worked in XE, but it is back in XE2.
I have tried it at home and could not repeat the problem. After six or seven RAD re-installations I found the reason – this issue occurs when you have only installed Delphi or only use the Delphi personality (-pDelphi) when Delphi and C++Builder are installed. I have filed the issue into QC as QC 102434. Luckily I found a workaround and this is enabling “Replace Open File At Cursor…” in DDevExtensions. So if you have also C++Builder installed then start RAD Studio with both personalities and otherwise try DDevExtensions.
TDBGrid cell painting
We have had an XE Unicode build with enabled theming for quite a while and noticed that the text in the focused grid cell was somehow bold, but we never looked into it. Now we have started to look into it and it turned out that this is no feature. It is rather a bug in our OnDrawColumnCell event handler. First some screenshots that you know what I am talking about.

Themed TDBGrid without OnDrawColumnCell event handler

Themed TDBGrid with supposed to be wrong OnDrawColumnCell event handler
In the second screenshot you should see that “Foo” in the focused cell is bolder than it is in first screenshot. The OnDrawColumnCell event implementation is just this:
procedure TForm21.DBGrid1DrawColumnCell(Sender: TObject; const Rect: TRect;
DataCol: Integer; Column: TColumn; State: TGridDrawState);
begin
Column.Grid.DefaultDrawColumnCell(Rect, DataCol, Column, State);
end;
Well this is not the code we use, but it is enough to demo the issue.
So why is the text in the focused column bold?
The reason is that TDBGrid sets in themed mode TDBGrid.Canvas.Brush.Style to bsClear for the focused column when DefaultDrawing is True. This happens in TCustomGrid.DrawCellHighlight. After drawing the focus rect the text is drawn and afterwards the OnDraw events are called. With DefaultDrawColumnCell and Brush.Style bsClear the text is painted twice to the same place and I guess antialiasing in themed mode does make it bold then. We have not finished the work on this topic and for now my advise is that you look at your Draw events and try to understand the code in the grid units.
More?
Yes, there might be more. I have other issues that we have experienced (debugger does stop on breakpoints that have been removed, “File | Reopen” does not like forms with open descendants) or task like the ModalResult check on my list.