困ったことが起きた。

何が困ったことかというと、とある会社のソフトがDelphiで作られていたのだが、midasを利用してデータベースアクセスするように作られていた。これ自体は何の問題も無いごく普通のことなのであるが、このソフトのmidasが非常に古いものであった。
midasはシステムに1つしかもてないので、通常はシステムフォルダのmidas.dllを置き換えるものであるが、そのソフトはソフトウェアのインストールフォルダにmidas.dllをコピーし、レジストリにその場所を登録していた。
※midas.dllはSide-by-Side(複数バージョンのソフトウェアコンポーネントの衝突を避けるための仕組みである)ができない。

このようなことをされると、他のDelphiアプリケーションもそのmidas.dllを参照することになる。Delphi 2010や、Delphi XE付属のmidas.dllは多くのバグが修正されていたり、また新機能に対応するように変更が加えられているはずにもかかわらずである。

こんな、midas.dllではあるが回避方法がいくつかあることがわかった。

TBrushStyleやTPenStyleなどの列挙型の値を文字列に変換するには次のように行う。

uses TypInfo;
function GetBrushStyleName(Value: TBrushStyle): String;
begin
    Result := GetEnumName(TypeInfo(TBrushStyle), Ord(Value));
end;

逆に文字列から値に変換するには次のようにする。

uses TypInfo;
function GetBrushStyleValue(Name: String): TBrushStyle;
begin
    Result := TBrushStyle(GetEnumValue(TypeInfo(TBrushStyle), Name));
end;

表題の通り、「ジェネリックのTListに格納したrecord型変数は解放する必要が無い」らしい。

DelphiでCreateOleObjecteにより起動したExcelが終了しないケースがあるかと思う。
くろねこの自宅ではExcel 2010を使用中であるが、幸いなことながらExcelが正常動作している際にはこのケースに遭遇したことは無い。しかしながら、勤務先のExcel 2003ではExcelの参照をもっている変数に対してunassignedを代入してもプロセスが解放されないと言うことが発生している。

このような際には、処理終了後Delphiの方からExcelプロセスの強制終了が必要になるかもしれない。
今回はこのようなときに役立つ処理を作成した。

また、この処理はハングアップしたExcelプロセスを強制終了する際にも役に立つだろう。
通常、ハングアプリケーションの明確な定義ない。しかし、通常ハングアップという状態では、該当のプロセスはいくつかの処理が"ビジー"になっていて、ユーザーから見た際に応答を停止している状態であると思われる。

次の処理は、アプリケーションがまだ一定時間で応答する際には通常に処理を実行しているとみなし、そうで無い場合にはハングアップしていると見なすこととした。