Undocumented Changes - From Delphi 2007 to Delphi XE–TRadioGroup

When I was trying  Evert Etienne's sample application for demonstrating all AnimateWindow possibilities (http://delphi.about.com/od/delphi-tips-2011/qt/hide-slide-fade-away-controls-delphi-form.htm), I noticed there was a difference of TRadioGroup in Delphi 2007 and Delphi XE(XE2).
This difference is in the below code snippet in Delphi XE:

procedure TCustomRadioGroup.ReadState(Reader: TReader);
begin
  FReading := True;
  inherited ReadState(Reader);
  FReading := False;
  if HandleAllocated then //<--- Delphi 2007 has no this checking!!!
    UpdateButtons;
end;

So, what is the deal of above difference?
The difference is, because of the checking, in Delphi XE and later version, the radio buttons will not be created until the handle of the radio group is allocated. The handle is not allocated when the radio group is just created, which means when TRadioGroup.Create is called, the buttons are not created yet. So the code like the below which is similar to  Evert Etienne’s sample will failed in Delphi XE as the controls is not nil but has no items at all:

procedure TForm1.FormCreate(Sender: TObject);
begin
…
TRadioButton(RadioGroup1.Controls[2]) …
…
end;

It is mystery to me that why it is doing that checking in Delphi XE.

Delphi, Win.Ini and Windows7 (1)

Today I came across the following code:

var
  LDeviceList : TStringList;
  LIniFile : TIniFile;
begin
  LDeviceList := TStringList.Create;
  LIniFile := TIniFile.Create('win.ini');
  with LIniFile do
    try
      ReadSectionValues('devices', LDeviceList);
      ButtonPrinter.Enabled := LDeviceList.Count <> 0;
      …
    finally
      Free;
    end;

What  I was wondering was why it was using Win.Ini? I thought it had been discarded since long time ago, but above code is still working well on my Windows7 system.
So I did a search on my hard disk, there were three Win.Ini files. One was in C:\Windows, one was in C:\Users\<current user>\AppData\Local\VirtualStore\Windows, another one was in C:\Windows\winsxs\amd64_microsoft-windows-coreos_31bf3856ad364e35_6.1.7600.16385_none_814737ee58024dde. The one in Windows folder looked like the one above code was referring to. But what surprised me was that there was no [devices] section in the file at all, not either in the other two:

; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
[Mail]
MAPI=1
CMCDLLNAME32=mapi32.dll
CMC=1
MAPIX=1
MAPIXVER=1.0.0.1
OLEMessaging=1
[MCI Extensions.BAK]
3g2=MPEGVideo
3gp=MPEGVideo
3gp2=MPEGVideo
3gpp=MPEGVideo
aac=MPEGVideo
adt=MPEGVideo
adts=MPEGVideo
m2t=MPEGVideo
m2ts=MPEGVideo
m2v=MPEGVideo
m4a=MPEGVideo
m4v=MPEGVideo
mod=MPEGVideo
mov=MPEGVideo
mp4=MPEGVideo
mp4v=MPEGVideo
mts=MPEGVideo
ts=MPEGVideo
tts=MPEGVideo

But the printer button was on when I ran the application and there was definitely no other code  controlled the printer button.

So I thought I had to debug the code. I put a break point on the line “ButtonPrinter.Enabled := LDeviceList.Count <> 0;” and it did run to there, and the LDeviceList did contain the correct printers installed on my Windows7!
So where was the real Win.Ini file it read from? Could not be the one in Windows folder. And the LIniFile does not tell you where the Win.Ini file was.
Then I launched VMMap.exe to view the memory and files were using by the application. I use it a lot to find out which DLL files the application is using to confirm the application is using the right one when there are a few versions of the same DLL stored in the system. But there is no sign of Win.Ini file in VMMap. Maybe FileMon is more proper for this case, so I ran FileMon and set its filter to show Ini file’s activity only, but there was no sign either!
That became  very interesting now. The code was reading something from the file but the system basically told you that sorry there was no such file has been opened and read.
What would you do then if you were me?

My old blogs

My old blogs can be viewed from http://lbcsy.wordpress.com/