変数定義をするときに、下のようなコードを書いたらエラーが発生しました。

var
hWnd: HWND;

[dcc32 エラー] xxxx.pas(26): E2007 定数または型が必要です

HWND は定義されているのになんでだよ！
みたいに怒っていました。
しまいにはこのコンパイラ壊れている！！！なんて...

おバカすぎましたね。
Delphi ですから、大文字小文字とかないし...
まさか変数名側でエラーが起きているとはつゆとも思わなかったのです。
こんなことで10分以上悩むとか...
(いや、実際は HWND ではなくもっとめっちゃ長い識別子だったんですが)

FireMonkey にも VCL にも TBitmap というクラスがあり、 それぞれ VCL.Graphics, FMX.Graphics に入っています。
同じ名前なので同じようなものと思ってしまうのですが、だいぶ違うんです。

FireMonkey の TBitmap はビットマップをカプセル化したものです。
VCL の TBitmap はWindows ビットマップ (HBITMAP) をカプセル化しています。
FireMonkey の TBitmap の親は TInterfacedPersistent です。
VCL の TBitmap の親は TGraphic です。
つまり VCL の TBitmap は、TIcon や TMetafile, TJPEGImageの兄弟です。

FMX.Graphics.TBitmap

FireMonkey の TBitmap は CreateFromStream や CreateFromFile で、ファイルからビットマップデータを読み込むことができます。
(扱うことのできる画像形式は TBitmapCodecManager を参照)。

VCL.Graphics.TBitmap で画像ファイル読み込み？

VCL.Graphics.TBitmap の LoadFromFile は BMPファイルからの読み込みしかサポートしません。
VCL.Graphics.TBitmap に 様々な画像ファイルから画像を読み込みたい場合は TPicture を使います。

var
  Picture: TPicture;
  Bitmap: TBitmap;
begin
  Picture := TPicture.Create;
  Picture.LoadFromFile(AFilePath);
  Bitmap := TBitmap.Create;
  Bitmap.Width := Picture.Width;
  Bitmap.Height := Picture.Height;
  Bitmap.Canvas.Draw(0, 0, Picture.Graphic);
  ...
end;

TPicture は TGraphic のコンテナで、グラフィックを保持するために使用されます。
TGraphic はアイコン，ビットマップ，およびメタファイルなどのイメージを格納および表示するオブジェクトの抽象基本クラスですから、TPicture はこれらのグラフィックを統合的に扱うことができます。
なお、TPicture の親は TInterfacedPersistent です。
ちなみに FireMonkey には TPicture や TGraphic はありません。
FireMonkey はマルチプラットフォームですから当然ですが...

必要な領域 18,282MB
使用可能なディスク領域 28,556MB
残りのディスク領域 10,273MB

[dcc32 警告] xxxx.pas(n): W1000 シンボル 'FileAge' を使用することは推奨されていません 

function FileAge(const FileName: string): Integer;

function FileAge(const FileName: string; out FileDateTime: TDateTime;
  FollowLink: Boolean = True): Boolean;

知ってはいたんですよ。
TInterfacedObject の自動破棄については…
いえ、知っているつもりだったんです。

TInterfacedObject を継承して作ったクラスを使うときには Free をしちゃだめ！
という知識はありました。
ただ、それは局所変数で処理しているから、局所変数がなくなったときに自動破棄されるものだと思っていたのです。

知っていたサンプル

たとえば下に示すようなクラスを作ったとします。
単に Test というプロシジャだけを持つ interface と、それを実装した TInterfacedObject を継承したクラスです。

interface

uses
  System.Classes;

type
  ITestInterface = interface
    ['{7723B047-28A4-4EF1-8836-0BE06092F2F5}']
    procedure Test;
  end;

  TTestClass = class(TInterfacedObject, ITestInterface)
  public
    constructor Create;
    destructor Destroy; override;
    procedure Test;
  end;

implementation

uses
  Vcl.Dialogs;

{ TTestClass }

constructor TTestClass.Create;
begin
  inherited;
  ShowMessage('Create!');
end;

destructor TTestClass.Destroy;
begin
  ShowMessage('Destroy!!');
  inherited;
end;

procedure TTestClass.Test;
begin
  ShowMessage('Test');
end;

end.

問題が起きるのは次のような書き方をした場合だと思っていました。

procedure Test;
var
  T: TTestClass;
begin
  T := TTestClass.Create;
  (T as ITestInterface).Test;
  T.Free;
end;

大丈夫だと思っていたサンプル

フォームからこのクラスを使おうとして、フォーム生成時にクラスを作成し、ボタンが押されたら Test メソッドを呼び出す、というコードを書いてみました。

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    { Private 宣言 }
    FTest: TTestClass;
  public
    { Public 宣言 }
  end;

implementation

procedure TForm1.FormCreate(Sender: TObject);
begin
  FTest := TTestClass.Create;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  FreeAndNil(FTest);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  (FTest as ITestInterface).Test;
end;

このコードを実行すると、２回目にボタンを押すと例外が発生してしまいます。
(FTest as ITestInterface).Test; を実行すると、Button1Click を抜けるタイミングで FTest の実体が解放されてしまうためです。
えー！そんなぁ！！！
このサンプルくらいなら FTest を ITestInterface で宣言するという手が使えますが、複数の Interface を持つクラスを保持するためにその数分の変数を用意するのはないなぁ…と思うのです。
やはり TInterfacedObject を Java の Interface 的に使うのは、どんなときでもだめ！ということですね。

今回、かなり複雑な仕組みのプロジェクトに、TInterfaceObject と Interface の機構を後から組み込んでしまい、わけのわからないバグに悩まされてしまいました。
もう絶対 TInterfacedObject は使わないことを心に誓いましたよ。

解決策は？

参考サイトの情報を参照してください〜

[参考サイト]

Delphi/interfaceを使おう/何が問題になるか？
TInterfacedObject で自動破棄....の前に

インストールにはシステムドライブに 約18GB必要ということでした。
ぎりぎり入るかなと思ってやってみたのですが、途中で止まってしまいました。
システムドライブの容量を見てみると 0になっていました。
インストール失敗です。
インストールをキャンセルしたのですが、ディスクの空き容量が増えません。

インストールの仕組みとしては、radstudio_xe5_upd2_esd.exe が zip ファイルをダウンロードしてきて、それを一時フォルダに展開してからインストールするようです。

上記のように インストーラが途中で止まってしまった場合、それらの中間ファイルが削除されないようでした。
zip ファイルがダウンロードされるパスは、デフォルトでは
c:¥ユーザ¥ユーザ名¥マイ ドキュメント¥Rad_Studio_XE5_Upd2_Downloads
で、このパスはインストール時に指定できます。
そこで、まずこれらのダウンロードされたファイルを別のドライブに移動させました。
容量はエンタープライズ版で 2.5GB 程度？でした。

これで再度挑戦しようと思いましたが、ディスク容量が減ったままでは気になるので、zip を展開したファイルを削除することにしました。
これらのファイルは c:¥ProgramData¥{GUID?}¥ というフォルダ以下にあるようなので、フォルダごと削除します。

これでもまだディスク容量が足りなそうなので、システムドライブの不要なファイルを根こそぎ削除してから、インストールを実行してみました。
今回は順調にいきそう…と思ったら boost をインストールするには最低 3GB 必要などと言われてしまいました。
ドライブを見てみると残り 1.8GB とか…
たしか25GB くらいはあったはずなのに…
それでもなんとかインストールは終わりました。
(boost を除く)

システムドライブの残りは 1.4GB になっています。
これではすぐ具合が悪くなりそう。
zip が展開されたフォルダを見てみると、そのまま残っていて 11.8GB も使っています。
えーーーーーー
これは要るのでしょうか？
このままではディスクがすぐに一杯になっていまいそうなので、消してしまうことにします。
消してしまってもとりあえず不具合は起きないようです。

それにしても開発環境はディスクを食うなぁ….
あのゴミは一体なんなんだろう...

Generics の TObjectList を使ったプログラムをデバッグしていて気がつきました。
TObjectList のコンストラクタで inherited の書き方によって、動作が違うことがあるの？

書いていたのはこんなコードです。

TDangerObjectList = class(TObjectList<TBar>)
public
  constructor Create;
  destructor Destroy; override;
end;

constructor TDangerObjectList.Create;
begin
  inherited;   // inherited Create; でなければならない!!
end;

destructor TDangerObjectList.Destroy;
begin
  inherited;
end;

コンストラクタで inherited Create と書けば TObjectList.Create が呼ばれますが、 inherited だけ書くと TList.Create が呼ばれてしまうようです。
それって子供たちが解放されないってことですよね？

inherited とだけ書くと、自分と同じシグネチャのメソッドである Create() を呼び出そうとしますが、TObjectList には Create() はありません。(注)
そのため TObjectList の親の TList.Create() が呼ばれてしまうのでしょう。

(注)
TObjectList.Create と書けるじゃないか。と思いますが、実際には
Create(AOwnsObjects: Boolean = True)
が呼ばれているだけで、 Create() はありません。

意外にこの辺りは適当に書いてしまうことがあるので注意しなければ...