PDF文書ファイルをページごとに画像化したくて様々な方法を探し（AND 試し）ましたが、なかなか「コレだ！」と思える方法が見つからず、ほぼ１日を費やして（ダメか･･･）とあきらめかけた、まさにその時、やっと出会えたのが Swanman (id:tales)さんの Blog の次の記事でした。

外部ライブラリ無しでPDFを描画する。

https://lyna.hateblo.jp/entry/20160625/1466783114

「それならWeb上の変換サービスを使えば･･･」というご意見はもっともですが、利用目的が「スキャナーでPDFファイル化した個人情報を含むデータの画像化処理」で、それなりに枚数もあるし･･･どこかのサーバーにアップして･･･というのは絶対に避けたいところです。

Swanman (id:tales)さんのBlogの記事を頼りに、何とか目的を実現することができました。これは、その際行ったことの備忘録です。

【もくじ】

１．FireMonkeyならPDFiumがある
２．WinRT
３．まとめ
４．お願いとお断り

１．FireMonkeyならPDFiumがある

最近、何かを調べる時はCopilotさんにお伺いをたてることが多いです。そこで、今回も早速きいてみました。

自分：
DelphiでPDFを画像化したいときはどうしたらいいですか

するとPDFiumというライブラリがあるとCopilotさんが教えてくれました。ただ、紹介されたのは「PDFium Component Suite for FireMonkey」だったので、どちらかというとWindows専用にVCLコンポーネントを使ってプログラムを書きたい自分的には（FireMonkeyはちょっと･･･）という感じだったのですが･･･、「溺れる者は藁をもつかむ」と、まさにそんな気持ちでありましたから･･･記事に目を通してみることに。

Copilot さんが教えてくれた FireMonkey 用の PDFium の紹介ページはこちら。

PDFium – Delphi/C++Builder FireMonkeyアプリケーション向けPDFエンジン

https://blogs.embarcadero.com/ja/pdfium-pdf-engine-for-your-delphi-c-builder-firemonkey-applications-ja/

そこで紹介されていたコードの一部（抜粋して引用）。

  Bitmap := FPdf.RenderPage(0, 0,
    Round(PointsToPixels(FPdf.PageWidth, PixelsPerInch)),
    Round(PointsToPixels(FPdf.PageHeight, PixelsPerInch)));
  try
    Bitmap.SaveToFile(FileName + '_Page' + IntToStr(I) + '.jpg');
  finally
    Bitmap.Free;
  end;

このRenderPageなる手続きが使えれば、目的はカンタンに実現できそう。
それに PDFium はライセンス的にも問題なさそうだし･･･

（VCL版があればなぁ･･･）

ダメ元で探してみるとPDFiumのVCL版を発見。早速、ダウンロード！

ahausladen/PdfiumLib: PDF VCL Control using PDFium

https://github.com/ahausladen/PdfiumLib

大喜びで、使ってみたんだけれど･･･

なんと、PDFiumのVCL版には RenderPageがありません でした！！

（間違えていたら、ほんとうに、ごめんなさい）

必要なものは全部 uses して、exeと同じフォルダに PDFium.dll も用意したのですが、何か足りないものでもあったのでしょうか？

なら、FireMonkey で書けばいいじゃん！って気持ちにそう簡単にはなれないのが人間です。実は、それなりに頑張ってFireMonkeyでいくつかのプログラムをこれまでに書いてみたのですが、エラーの原因解明に手間取ることが多くて、Windows PCしか使わない自分にとって、無理してまでクロスプラットフォームでプログラムを書くメリットはないように思えてきて･･･やはり、書きなれたVCLの方が自分にはあってる･･･と、どうしても、そう思ってしまい･･･

それに、ここでFireMonkeyにすると、この先もずっとFireMonkeyで書くことに。

現在、書き続けている一連の採点処理用途のプログラムは、すべてVCLで書いてきたこともあり、大変残念ですが PDFium の使用は、ここで断念することに決めました。

２．WinRT

Swanman (id:tales)さんのBlogの記事に紹介されていた Windows Runtime（略称がWinRT）なるものの存在を、これまで僕は知りませんでした。Win32 API なら名前だけは知ってましたが、どうやらそれより新しいAPI であるとのこと。難しいことはわかりませんが、このWinRTでPDFの画像化ができるのであれば、Windowsの機能を使ってそれが実現できるのですから、新規に何かライブラリを追加したりする必要がなく、それこそ理想的です。

ようやく発見したSwanman (id:tales)さんのBlogの記事を読んで、とりあえず、上記の内容だけは確実に理解できました。早速、アップロードされていたユニットとサンプルコードを有難くダウンロードさせていただき、Project2 のサンプルコードを実行（F9）してみました。すると･･･

これは困りました。解決方法がまったくわかりません！

（APIだから、もしかしてMicrosoftさんのほうで、ここ数年のうちに何か変更があったのかな･･･）

pas、すなわち必要なユニットはすべてPathの通ったところに置きましたから、これはライブラリ自体が「ない」ということなのかな･･･？

（ない袖は振れないから･･･、ダメもとで外してみようか･･･）

唯一、思いついた解決方法にならない強引な戦法で前進？することに決め、問題の行をコメントアウト。幸い、誰もこのライブラリを参照していなかったようで、「未定義の識別子」エラーは表示されません。これはラッキー！とばかりに、このまま再度、実行（F9）します。

すると･･･、別のユニットでもうひとつ同じエラーが発生。

もう、ムチャを承知で無理やり、前進！　前進!!
この行も // コメントアウト。こちらもラッキーなことに「未定義の識別子」エラーは表示されません。これ幸いと、再び、実行（F9）。

このプログラムが動かなくて困るのは僕だけです。他に誰一人、悲しい思いをする人はいません。それだけが唯一の救いです。

結果は･･･

何の問題もなく、
プログラムは無事に動作しました！

開いたPDF文書はページごとにJpeg画像として保存できました☆

ちなみに Types の他にはどんなメンバーがいるのかと思い、WinAPI.Foundation をコピペして、n の後ろに「 . 」を入力してみると、入力補完機能が表示した選択肢は･･･

もちろん、誰もこのユニットを参照していないことは明らかなので、次のようにしても動作しました。

（もしかして、必要なユニットがまだ他にあるのかな･･･）

（でも、どこからも参照されていなかったし･･･）

（何で uses されてたんだろー？）

結局、Winapi.Foundation.Types の謎は解けませんでしたが、PDF文書ファイルの各ページをJpeg画像として保存したいという目的は実現することができました。

今回、僕が探した範囲ではDelphiを使ってPDF文書の画像化を実現する方法は、FireMonkeyでPDFiumを使う方法と、このWinRTを使う方法の二つしか見つけられませんでした。したがって、FireMonkeyという選択肢を選ばないのであれば、WinRTを使うこの方法しか、選択肢はありません。

そのような意味で、Swanman (id:tales)さんのBlogの記事にあった情報は大変貴重な情報であると思いました。Swanman (id:tales)さんにこころから感謝しております。ありがとうございました。

３．まとめ

（１）Delphiで、PDF文書の各ページを画像化する方法はある。
（２）FireMonkeyでPDFiumを使用。
（３）WinRTのAPIを使う方法もある（VCLで動作確認／FireMonkeyでの動作は未確認）。

今回の記事を書くにあたって、プログラムの動作確認に使用したPCの環境は次の通りです。

【デバイスの仕様】
プロセッサ 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 3.00 GHz
実装 RAM 32.0 GB (31.7 GB 使用可能)
システムの種類 64 ビット オペレーティング システム

【Windowsの仕様】
エディション Windows 11 Pro
バージョン 23H2
OS ビルド 22631.3296
エクスペリエンス Windows Feature Experience Pack 1000.22687.1000.0

【Delphiのバージョン】
Embarcadero® Delphi 12 バージョン 29.0.50491.5718

４．お願いとお断り

このサイトの内容を利用される場合は、自己責任でお願いします。ここに記載した内容を利用した結果、利用者および第三者に損害が発生したとしても、このサイトの管理者は一切責任を負えません。予め、ご了承ください。

画像をほんの少しだけ回転させるプログラムを書いた。そこでの角度の指定は、最大でも１°未満を想定（整数値だと大きすぎ）。そこで、回転角度の値を指定するTEditへ、キーボードから直接入力する場合は、0.01刻みでのインプットを可能としたが、TEditとTUpDown等の数量を扱うVCLを組み合わせての入力、つまり、マウスで▲・▼マークをカチカチクリックして値を増減させて入力する場合には、TEditに設定する値は「0.01」刻みでは小さすぎるから、「0.1刻みで増減」させようと思った･･･んだけれど、これが難しかった。

【訂正】　これが難しかった　→　これが、（僕には）難しかった。

最初はTEditとTUpDownを組み合わせて、これを実現しようとしたが中々上手く行かず、仕方がないから、TEdit１個とTButton２個を組み合わせて、なんとか当初の目的を実現。その後、当初、気がつきませんでしたが、TEditとTUpDownの組み合わせで、Float値を増減させる方法も見つけました。これはその覚え書きです。

【もくじ】

１．TEditとTUpDownでチャレンジ
２．TEditとTButton２個でチャレンジ
３．増減値が０にならない理由
４．コードを修正
５．0.1ずつ増減
６．まとめ
７．お願いとお断り

１．TEditとTUpDown

とりあえず定番と思われるTEditとTUpDownの組み合わせ。

UpDown1のAssociateプロパティにEdit1を設定

Edit1にUpDown1がくっついた！

くっつく位置は左右いずれかを指定できるらしい。

画像の回転が目的だから、とりあえずUpDown1のMaxプロパティは90、Minプロパティは-90に設定。
（実際に使用する値は１°未満の予定）

で、Edit1の値を0.1ずつ増減させる「UpDown1Click手続き」を次のように作成。

procedure TForm1.UpDown1Click(Sender: TObject; Button: TUDBtnType);
var
  Value: Real;
begin
  //注意：このコードは、期待通りに動作しません
  Value := StrToFloatDef(Edit1.Text, 0);
  case Button of
    btNext: Value := Value + 0.1;
    btPrev: Value := Value - 0.1;
  end;
  Edit1.Text := FloatToStrF(Value, ffNumber, 1, 1);
end;

実行（F9）して、▲ボタンを３回クリックしたところ

１ずつ、増加してる･･･。

なんでかなーって、ちょっと思ったけど、UpDown1のincrementプロパティを見て納得。

足したり、引いたりしている 0.1 はどこに消えたのか･･･？

とりあえず、原因の一つはコレだ☆
やりたいのは「１」ずつじゃなくて「0.1」ずつ増減だから、そう！

Increment プロパティを 0.1 に変えてみた *(^_^)*♪

ひー（心の悲鳴）

Incrementプロパティには、整数しか設定できないようだ。

整数･･･　そぉか、０ならOK？
Value（＝Editに表示されている値） に 0.1足したり、引いたりしてるから、これでイケる？

実行（F9）すると･･･

Value + 0.1や、Value – 0.1はどこに消えた？

1.1 とかになってたから、完全に無視されてるわけでもなさそうだけど･･･？？？

Increment プロパティが整数値指定だとわかった時点で、なんか嫌な予感がしたんだよなー
他にも、Maxとか、Minとか、入力を制限する値（こちらも整数値で指定）もあるし･･･

ここで謎を追いかけて、無駄に時間を使うより、TUpDownは「整数値専用」と決めて、他の方法を試すことに決定。※ 実際、TEditとTUpDownの組み合わせで、小数値の増減も可能です（後述）

２．TEditとTButton２個でチャレンジ

Edit2の右に、Buttonを２つ置いて、こんなふうにしてみた。

で、コードは Copilotさん に教えてもらった☆　その質問内容と答えのコードがこちら。
（コード部分はコピー可能だったから著作権的な問題はないと判断）

Q：DelphiでTEditの値を0.1ずつ増減するにはどうしたらいいですか？

A：Copilotさんが教えてくれたコード。

procedure TForm1.Button1Click(Sender: TObject);
var
  Value: Double;
begin
  if TryStrToFloat(Edit2.Text, Value) then
  begin
    Value := Value + 0.1;
    Edit2.Text := FloatToStr(Value);
  end
  else
    ShowMessage('Invalid number');
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  Value: Double;
begin
  if TryStrToFloat(Edit2.Text, Value) then
  begin
    Value := Value - 0.1;
    Edit2.Text := FloatToStr(Value);
  end
  else
    ShowMessage('Invalid number');
end;

これなら間になんにも入らず、直接Editを編集してるから、絶対、大丈夫 だろ？
最初からコレでよかったんだ･･･ みたいな気持ちで、コピペして編集し、実行（F9）。

▲をカチカチ、２回クリックしました。イイ感じです！

で、減算（▼クリック）は、初期値が上の 0.2 のところから始めると･･･

次の▼クリックで、値は「０」になるはず。

ところが･･･

はぁ？ 0.1 – 0.1 = 0.0（ゼロ）になるはずなんだけど･･･
ナニ、コレ？

３．増減値が０にならない理由

そうでした。コンピュータは小数の演算が苦手でした。

僕自身、前にさんざん苦しみました。なんで上の計算が「０」にならないのか？

その理由は、次の記事をご参照ください。

Win11の23H2より前のバージョンなら、正しいと思える答えにたどり着くまでGoogle先生に質問を繰り返すのがこれまでの問題解決の定番と言える方法でしたが、今はとなりにCopilotさんがいてくれます。

期待を込めて、訊いてみました。

Q：Delphiで0ではなく、5.54975987041018E-18と表示されます

以下、Copilotさんの返答の概要です。

・浮動小数点数（DoubleやSingle型など）は完全な精度で表現されない。
・これは、すべてのプログラミング言語で共通の問題。
・解決策の一つは、ある閾値（epsilon）よりも結果が小さい場合は 0 と表示。

完全に納得。

Copilotさん、優秀！
ぼく、きみのファンになりました☆

で、以下、Copilotさんが教えてくれた閾値を設定したコードです（コメント文は短縮）。

var
  Value: Double;
  Epsilon: Double;
begin
  Epsilon := 1E-15;  //閾値を設定
  Value := SomeCalculation();  //計算を実行
  if Abs(Value) < Epsilon then
    Value := 0;
  Edit1.Text := FloatToStr(Value);
end;

４．コードを修正

Copilotさんが教えてくれたコードを読んで、「0.0」と表示されるように修正しました。

procedure TForm1.Button3Click(Sender: TObject);
var
  Value: Double;
  Epsilon: Double;
begin
  Epsilon := 1E-15;  //閾値を設定
  if TryStrToFloat(Edit3.Text, Value) then
  begin
    Value := Value + 0.1;
    if Abs(Value) < Epsilon then
    begin
      Value := 0;
      Edit3.Text := '0.0';
    end else begin
      Edit3.Text := FloatToStr(Value);
    end;
  end;

end;

procedure TForm1.Button4Click(Sender: TObject);
var
  Value: Double;
  Epsilon: Double;
begin
  Epsilon := 1E-15;  //閾値を設定
  if TryStrToFloat(Edit3.Text, Value) then
  begin
    Value := Value - 0.1;
    if Abs(Value) < Epsilon then
    begin
      Value := 0;
      Edit3.Text := '0.0';
    end else begin
      Edit3.Text := FloatToStr(Value);
    end;
  end;
end;

ゼロの時は、’0’ではなく、’0.0′ と文字列指定しているところに「こだわり」ました！

５．0.1ずつ増減

上記コードの実行結果です☆（初期値は 0.2）

閾値が効きました☆

逆（▲クリック）も正しく動作することを確認。

【TEditとTUpDownの組み合わせで実現】

TUpDownのMax及びMinプロパティの値（特にMin）を適切な値に設定し、適切なコードを記述することで、TEditとTUpDownというVCLコンポーネントの組み合わせでも 0.1 刻みの選択肢設定が可能であることを確認しました。その方法は以下の通りです。

※ オブジェクトインスペクタで Increment プロパティの値を予め設定しておくという前提で、

【重要】 負数の入力を想定する場合は、TUpDownのMinプロパティの値に適切な負数を設定します！

【重要】 Increment プロパティに 1 を設定 → ▲をクリック → 値が 0.1 ずつ増加

ちなみに Increment プロパティに 2 を設定した場合は、値が 0.2 ずつ増減します。

procedure TForm1.UpDown1Click(Sender: TObject; Button: TUDBtnType);
begin
  Assert(Sender is TUpDown);
  with TUpDown(Sender) do
  begin
    Assert(Associate is TEdit);
    TEdit(Associate).Text := FloatToStrF(Position / 10, ffNumber, 1, 1);
  end;
end;

上記コードの出典は、こちら

Delphi-PRAXiS

https://www.delphipraxis.net/143779-tupdown-floats.html

貴重な情報をご教示くださいましたこと、投稿者様に対し、心より感謝申し上げます。

上のコードを参考に、使っているVCLの名前を指定して、もっと短くして書けば･･･

procedure TForm1.UpDown1Click(Sender: TObject; Button: TUDBtnType);
begin
  Edit1.Text := FloatToStrF(UpDown1.Position / 10, ffNumber, 1, 1);
end;

増減値に 0.1 ではなく、0.2 以上の値を設定したい場合、Increment プロパティの値は予めオブジェクトインスペクタで指定しておいた方が良いようです。

ちなみにオブジェクトインスペクタのIncrement プロパティに設定してある値は「１」のまま、コードで「２」を指定した場合は･･･

procedure TForm1.UpDown1Click(Sender: TObject; Button: TUDBtnType);
begin
  UpDown1.Increment := 2;
  Edit1.Text := FloatToStrF(UpDown1.Position / 10, ffNumber, 1, 1);
end;

実行（F9）してみるとエラーにはなりませんが、最初の▲押し下げ時に 0.2 ではなく、0.1 と表示されます。また、実行（F9）後、最初の▼押し下げ時には -0.2 ではなく、-0.1 と表示されます。それ以降（▲・▼２回目押し下げ以降）は正しく表示（意図した通り表示）されます。

オブジェクトインスペクタのIncrement プロパティに設定してある値が「１」のまま、コードで値を設定・変更する場合は（実行途中での変更はできませんが）FormCreate時に設定しておけば期待通りに動作するようです（もし、違っていたら、ごめんなさい）。

procedure TForm1.FormCreate(Sender: TObject);
begin
  UpDown1.Increment:=2;
end;

procedure TForm1.UpDown1Click(Sender: TObject; Button: TUDBtnType);
begin
  //UpDown1.Increment:=2;
  Edit1.Text := FloatToStrF(UpDown1.Position / 10, ffNumber, 1, 1);
end;

PCの画面で確認すれば、設定状況がわかりやすいと思います。

以上が、TEditとTUpDownの組み合わせで小数値を増減させる方法のまとめです。

６．まとめ

（１）TEditとTUpDownの組み合わせで0.1刻みの数値の増減は可能。
（２）TUpDownで負の数を扱う場合は、Minプロパティの値も適切に設定する。
（３）TEditとTButtonの組み合わせで小数値の増減計算を行う場合は値「0」に注意する。

７．お願いとお断り

このサイトの内容を利用される場合は、自己責任でお願いします。ここに記載した内容を利用した結果、利用者および第三者に損害が発生したとしても、このサイトの管理者は一切責任を負えません。予め、ご了承ください。

浮かんだままがいいときもあったりして！

【もくじ】

１．フローティングパネル
２．ドッキングさせたくない
３．メモリが解放できない
４．メモリが解放できた（その１）
５．メモリが解放できた（その２）
６．まとめ
７．お願いとお断り
８．【追記】

１．フローティングパネル

手書き答案の採点プログラムで、常にフォーム上に浮かべたまま、自由にその位置を変更可能な、作業補助用のGUI（フローティングパネル）が欲しくなった。

前回、縦書き答案の採点用に作成した横スクロールのフローティングGUIはControlBarの上にToolBarを置いて、その上にToolButtonやBevelを並べたけれど、今回はその名の通り、ベースとなるVCLはTPanelを選択。この上に効率よく採点作業を行うために最低限必要なButton他を置いて、ユーザーの視線やマウスの移動量を極めて限られた範囲に限定。操作に払う注意とストレスをできるだけ軽減して、より快適な作業環境を実現したい･･･。

そう考えて作成したGUIがコレ。

画面をタッチして操作することも考え、各Buttonの高さは44ピクセルに設定。
これを設問毎に、答案画像から切り抜いた画像を並べて表示したTImageのとなりに表示する。

フローティング状態だとTPanelの上に「閉じる」ボタンのあるタイトルバー？（キャプションバー？）が表示される。この部分をクリックして、そのままドラッグすれば、TPanelをForm上の任意の位置へ移動できる。ただし、Formにドッキング（FormのDockSiteプロパティをTrueに設定）した瞬間、タイトルバー？はかき消されたかのように消えてしまう･･･

以前作った（縦書き答案の採点を効率よく行うために左右方向のスクロールを行う）ドッキング・コントロールは、ドラッグ＆ドロップでFormにドッキングするように設計。必要であれば、Bevelをクリックしてそのままドラッグすることでドッキングを解除。任意の位置へ移動できる仕様とした。そんなに頻繁に位置を変更するようなモノでもなかったし。

ところが、今回はFormにドッキングさせると、いろいろ不都合が起きることが判明。

例えば、解答欄の大きさ（特に幅）に合わせて、この入力補助Toolの位置を頻繁に変えるような場合、クリックしてそのままドラッグできる「タイトルバー（キャプションバー）」がないと極めて不便。Formにドッキングした瞬間にこれが消えてしまうと、掴みどころがなくてほんとうに困るのだ。

それから、Formへドッキングしている状態から、引きはがしてフローティング状態になるときの挙動がとにかく急で！ うまく文字に表現できないのだけれど、感覚的には「うわっ」て感じ。GUIをクリックした瞬間に、「びっくりして飛び起きる」イメージでフローティングするのだ。

（数学風？に言えば、GUI上のクリックした位置が、GUIの左上の座標原点（0,0）の位置になるように、Button等のコントロールを載せているPanelの左上隅が瞬時にクリックした位置へ移動する）

また、最初の解答欄を表示している場合、１つ前に戻る「◀」ボタンはEnabledプロパティをFalseに設定し、クリックできないようにしてあるが、この Enabled:= False 状態のボタンをクリックすると上で述べたGUIが「びっくりして飛び起きる」ように瞬間移動する現象がおきてしまう。

さらに（原因はわからないけれど）、縦書き答案の採点時にFormにドッキングさせると、解答欄の表示が部分的にずれて二重に表示されてしまう（ドッキングさせなければ、この現象は起こらない）。

あれや、これやで、どぉーにもドッキング時の挙動が気に入らない。

じゃあ、
ドッキングさせなければいいじゃん！

･･･

そのとおり･･･

そのとおり、なんだけど･･･

そうすると･･･　コレが　･･･

コレが･･･　どぉーしても　消えなくて･･･

T_T

２．ドッキングさせたくない

メモリーリークの原因はわかってる。フローティングさせたTPanelをドラッグし始めた時に発生するStartDock手続きでCreateしているTToolDockObjectだ。

procedure TFormXXX.PanelXStartDock(Sender: TObject;
  var DragObject: TDragDockObject);
begin
  DragObject:= TToolDockObject.Create(Sender as TPanel);
end;

実は、これがなくても、フローティング動作は出来る。出来るんだけど、見た目に問題があって、高解像度画面で表示倍率を200％拡大のように設定している場合、ドラッグ（＝移動）中は灰色の枠だけのフローティングパネルのゴースト？が現れる。（画面のハードコピーがうまくとれなかったので）ゴースト？は、次の図のような感じ。

そして、このゴーストが目に痛い感じでちらつきながら移動する。さらに困ったことに、ドラッグ中はフローティングパネルの本体（ゴースト？でない方）は表示されない。ドラッグしてドロップした瞬間に、まるでテレポーテーションしたかのように（突如として）ドロップした位置にパネルが出現するのだ。

ただし、メモリーリークは起きない。
（なんにもCreateしていないから、起きるわけがない）

一方、メモリーリークを起こすとわかっていても、ドッキング可能なコントロールのドラッグ操作を専門的に管理するTToolDockObjectをCreateして動かすと、動きがたいへんスムーズ！ 気持ちイイ☆

だから、どうしてもドッキングさせたくない！
フローティングさせたまま、使いたい！！

  DragObject:= TToolDockObject.Create(Sender as TPanel);

そうなると、この１行はどうしても削れない･･･。

ただし、裏側では「メモリーリーク」がフローティングさせたパネルをドラッグする（＝位置を変える）度に、発生･･･

表面的には何事もなく、静かなんだけど。

３．メモリが解放できない

解決策はただひとつ。

ドラッグが終了した時点で、StartDock時に確保したメモリを解放すればいい。

ところが、FormのDockSiteプロパティがFalseのままだと
それが、どうにも、こうにも、難しい･･･

ちなみに次のように書いてみたんだけど、上の条件下では、これは、どうやら無効！！！のよう。

procedure TFormXXX.FormDockDrop(Sender: TObject;
  Source: TDragDockObject; X, Y: Integer);
begin
  if IsDragObject(Source) then
  begin
    Source.Free;
  end;
end;

procedure TFormXXX.FormDockOver(Sender: TObject;
  Source: TDragDockObject; X, Y: Integer; State: TDragState;
  var Accept: Boolean);
begin
  Accept:=IsDragObject(Source);
end;

OnDockDropは、「別のコントロールがコントロールにドッキングした際に発生」つまり「DockSite が True の際にのみ、発生する」ということで、そもそもFormのDockSiteプロパティは意図的にFalseに設定してあるんだから、OnDockDropイベントが起きるわけがない。

OnDockOverもおんなじで、「DockSite が True の際にのみ、発生する」とのこと。１００万回ドラッグしようとFormのDockSiteプロパティがFalseである限り、OnDockOverイベントも絶対に起きない。

ダメ元で、OnDragDrop手続きと、OnDragOver手続きを作成して上と同じコードを書いてみたんだけど、手続きの引数をよく見たら･･･

procedure TFormXXX.FormDragDrop(Sender, Source: TObject; X, Y: Integer);

Sourceが、TDragDockObjectじゃなくて、TObjectになってる･･･。ってコトは、こっちで受け取るためには、型キャストが必要ってコト？ なのかなーって思いつつ、FormのDockSiteプロパティをFalseに設定したまま、型キャストなしで次のコードを書いてみたが、Panelをドロップしても反応がない。どうやら、この２つのイベントは、FormのDockSiteプロパティがFalseだとTToolDockObjectのドロップに対しては発生しないようだ。⇦ 間違いだったら、ごめんなさい！

procedure TFormXXX.FormDragDrop(Sender, Source: TObject; X, Y: Integer);
begin
  if IsDragObject(Source) then
  begin
    Source.Free;
  end;
end;

procedure TFormXXX.FormDragOver(Sender, Source: TObject; X,
  Y: Integer; State: TDragState; var Accept: Boolean);
begin
  Accept := IsDragObject(Source);
end;

その他、FormのDockSiteプロパティをFalseに設定したまま、フローティングさせたPanelをドッキングさせずにドロップ時にメモリを解放する方法はないかとさんざん 悩んだが、解決策が見つからない。まさに七転八倒。終いには、ナニをどういじったらそうなったのか、自分でもわからないのだけれど、フローティング状態のパネルをクリックしただけで一般保護違反のエラーが出るようになり、元に戻せなくなってしまった･･･。

フローティング部品がない状態のバックアップをとっていて、ほんとうによかった。

【これが間違いであっても、前に進むために出した、自分なりの結論】

TToolDockObjectを使いたいならOnDockDropとOnDockOverイベント側で、ドラッグ＆ドロップを受け取るしかない。

４．メモリが解放できた（その１）

何かをCreateして使うプログラムを書くとき、FormCreate時に、次のようにメモリーリークがあれば検出する設定を僕は付け加えることに決めている。多数の画像を読み書きする答案処理のプログラムを書いた際に、Createしたオブジェクトの解放を書き忘れ、あとからCreateしている箇所を全部点検することになった「痛い経験」から学んだ予防的措置だ。

procedure TFormXXX.FormCreate(Sender: TObject);
begin
  //メモリーリークがあれば検出
  ReportMemoryLeaksOnShutdown:=True;
end;

メモリーリークがあった場合、実行（F9）したプログラムを終了させると（メインフォームを閉じると）、次の画面がリークを起こした回数付きで表示される。

丸１日がんばって、（この方法じゃダメなんだ）ということがはっきりわかったところで、少し休もうと思い、ベッドに倒れて･･･ そのまま、眠ってしまったようだ。

なんにも考えない時間が数時間あって･･･

目覚めたのは日付が変わる直前。眠って疲れがとれたからか？ その原因はわからないけど、目覚めた瞬間に、あることを思いついた。それは何かと言うと･･･

FormのDockSiteプロパティをTrueに設定すれば、OnDockDropとOnDockOverの２つのイベントが間違いなく？ Panelのドラッグ＆ドロップに反応してくれるから･･･

ドラッグしてるときだけ、FormのDockSiteプロパティをTrueに切り替えて、ドロップした瞬間の位置座標を取得し、そこへPanelをManualFloatさせて、最後にメモリを解放、DockSiteプロパティをFalseに戻せばいいんじゃない？ ってこと。

いろいろ実験的に書いていて（プロパティをあちこち変更）、設定忘れがあると困るので、ドラッグ開始時、コードの中でFormのDockSiteプロパティをTrueに設定。

procedure TFormXXX.PanelXStartDock(Sender: TObject;
  var DragObject: TDragDockObject);
begin
  //これでちらつかなくなった
  DragObject:= TToolDockObject.Create(Sender as TPanel);
  //設定し忘れないための予防的措置
  if not FormXXX.DockSite then
  begin
    FormXXX.DockSite:=True;
  end;
end;

ドロップ時のOnDockDropイベントは･･･

procedure TFormXXX.FormDockDrop(Sender: TObject;
  Source: TDragDockObject; X, Y: Integer);
var
  r:TRect;
begin
  if IsDragObject(Source) then
  begin
    r.Left:=X;
    r.Top:=Y;
    r.Right:=X+PanelX.Width;
    r.Bottom:=Y+PanelX.Height;
    PanelX.ManualFloat(r);
    //解放
    Source.Free;
    if FormXXX.DockSite then
    begin
      FormXXX.DockSite:=False;
    end;
  end;
end;

FormのDockSiteプロパティはFalseに設定。

実行（F9）して、フローティングパネルをドラッグ＆ドロップ。ちょっと気になったのはドロップ時のManualFloat(r)時の挙動。ドロップした場所でなく、ドロップ時にマウスポインタのカーソルがあった位置へ移動して表示されてしまう。次の画像の上がドロップ時、下がマウスの左ボタンを離した際にフローティングパネルが表示される位置。

ドロップ時、XにはPanelのLeftの値、YにはPanelのTopの値を取得するよう、プログラムを修正。

    r.Left:=PanelX.Left;
    r.Top:=PanelX.Top;
    r.Right:=r.Left+PanelX.Width;
    r.Bottom:=r.Top+PanelX.Height;
    PanelX.ManualFloat(r);
    //解放
    Source.Free;

これで表示位置に関する問題は解決できたが、今度は表示される際の挙動が気に入らない。ドロップ位置でPanelの画像が一瞬、最小化され（閉じるボタンだけになり）、それから全体が表示されるので、ドロップするたびにPanelが１回点滅するように見えるのだ。

それはそれで何とかするとして、いちばん何とかしなきゃいけないのはメモリーリーク。

恐る恐るプログラムを終了。

DelphiのIDE画面だけが表示され、リークの警告画面は出ない！
ようやく問題を解決できた･･･。

ただし、一難去ってまた一難。
表示方法を何とかしなきゃ･･･

５．メモリが解放できた（その２）

点滅の原因はわかっている。ドロップ時の ManualFloat(r) だ。

  DragObject:= TToolDockObject.Create(Sender as TPanel);

メモリーリークは起きるけど、上の一行だけでフローティングさせ、ドラッグ＆ドロップしている時は点滅なんてしなかった。要は ManualFloat させなければいいのだ。

（かならず、解決方法はある）

そう信じて、OnStartDockイベントの手続き部分でShift＋Ctrl＋1、OnDockDropイベントの手続き部分でShift＋Ctrl＋2を実行して、Ctrl＋1、Ctrl＋2でそれぞれの手続きへ移動できるように設定。

２つの手続き間を行きつ戻りつしながら解決方法を考える･･･

どう考えてみても、OnDockDropイベント側でなんとかするのは無理そう･･･

TToolDockObjectをCreateして移動させてる時は、ドロップ時に点滅しなかった･･･

表示された位置も、ドロップした場所だった･･･ だから、ManualFloat は不要？

確保したメモリを最後に解放すれば、メモリーリークは起こらない･･･

『最後に解放』？

そうだ「 try　･･･　finally　･･･　end; 」があった。

プロシージャを思った通りに書き換える。

procedure TFormCollaboration.PanelXStartDock(Sender: TObject;
  var DragObject: TDragDockObject);
begin
  DragObject:= TToolDockObject.Create(Sender as TPanel);
  try
    if not FormXXX.DockSite then
    begin
      FormXXX.DockSite:=True;
      Application.ProcessMessages;  //おまじない
    end;
  finally
    DragObject.Free;  //メモリの解放
  end;
  FormXXX.DockSite:=False;
end;

実行（F9）

フローティングパネルは快適に移動し、ドロップ時の挙動もごく自然･･･

祈りながらFormをClose.

見慣れたIDEだけが現れる。

メモリーリークは 起きてない。

やっと、思っていたとおりの ･･･ プログラムになった？

･･･ってか、ちょっと待て。オレ、OnDockDrop手続きの ManualFloat 消してないぞ。

もしかして･･･ OnDockDrop手続き 呼ばれていないんじゃないか？

自分の書いたプログラムを、もう一度、よく読んで考える･･･

  DragObject:= TToolDockObject.Create(Sender as TPanel);
  try
    if not FormXXX.DockSite then
    begin
      FormXXX.DockSite:=True;
      Application.ProcessMessages;  //おまじない
    end;
  finally
    DragObject.Free;  //メモリの解放
  end;

DragObject を、最後に Free してるから、ドロップ時にはもう TToolDockObject は消えてる･･･。
消えてるんだから･･･　もう、『ない』んだから、呼ばれてないんじゃなくて･･･

OnDockDropイベントは起こらない！

･･･ってコトは、もしかして

DragObject:= TToolDockObject.Create(Sender as TPanel);
try
  //何もしない
Finally
  DragObject.Free;
end;  

Createして、Freeするだけで

よかったの？

６．まとめ

今回の状況を何かに例えるならそれはナニ？って、生成AIに訊ねたところ、

　“Still waters run deep”

そう答えてくれました。深く、静かに、感動。

７．お願いとお断り

このサイトの内容を利用される場合は、自己責任でお願いします。ここに記載した内容を利用した結果、利用者および第三者に損害が発生したとしても、このサイトの管理者は一切責任を負えません。予め、ご了承ください。

８．【追記】

  finally
    //DragObject.Free;  //メモリの解放のみ->インスタンス（オブジェクトの実体）はあるので参照可能
    FreeAndNil(DragObject);  //インスタンスも消える！
  end;

.Freeでなく、FreeAndNilすると、何もしなかったコトと同じになってしまいます。
注意してください！！

高DPIに対応しました！

これまでずっとPC画面の解像度は1366×768に固定して、この解像度での使用のみを前提に、僕はプログラムを書いてきた･･･。僕のプログラムが走るマシンは全部、この解像度だったから、それで何も問題は起きなかったのだけれど。

【今回の記事】

１．2880×1920の世界を知る
２．Formの表示がたいへんなコトに･･･
３．問題点を続々と発見！
４．exeを高DPI対応に設定
５．VCLの幅や高さを自動調整
６．まとめ
７．お願いとお断り

１．2880×1920の世界を知る

新しく支給されたPCの画面解像度は2880×1920で、拡大縮小率は150％に設定されてた。持ち運ぶことを考えると、ノートPCの画面サイズはそうそう大きく出来ないから、画面サイズが変わらないまま、解像度だけ上がってしまうと、相対的にアプリや文字の見た目はどんどん小さくなって、目にとてもやさしくない画面になる。だから拡大150％や拡大200％って設定が必要なんだと思うけど･･･。

取り敢えず、この環境で僕のプログラムを動かすとどうなるか、実験してみた。

高解像度画面では、ボタンのCaptionが読めない･･･。

２．Formの表示がたいへんなコトに･･･

しかも、このプログラムから別のFormを呼び出すと･･･

自分的には、こう表示されてほしいのですが･･･
（今までは何の問題もなく、こう表示されていた）

やばい。何としても高DPIに対応させないと、職場のみんなにプログラムを使ってもらうどころか、自分ひとりですら使えない。画面が高解像度になっただけで、こんな問題が生まれるなんて･･･。これまで考えたこともなかった。

けっこうショックが大きくて、心がまた折れかけたけど、この問題をクリアすれば、プログラムも、僕も、もっとよくなれるんだって、必死で自分に言い聞かせる。

３．問題点を続々と発見！

高解像度画面で一通り、プログラムの動作検証を行ってみると、見つけられただけで次のような問題が発生することがわかった。

① Formが設計時とは異なる大きさで表示される。
② 画面表示の拡大設定を行わないと、字が読めないくらい小さくなる。
③ 拡大設定時には、VCLコントロール（Toolbar）の幅や高さが意図しないものになる。

まず、①の問題の解決にチャレンジ。

FormCreate手続きでFormの幅を指定しても無駄。
まるで言うことを聞いてくれない。
いったいナニがどうなると、この問題が発生するのか？
これまで、こんな問題に出会ったこと、ないぞ･･･。

そう思いつつ、いろいろ調べてみると、次の情報を発見。

フォームを新規作成したらまずやる事 (Delphi)

https://ht-deko.com/ft1004.html#100408_02

明らかな既視感があったので、以前、どこかで見た情報に間違いないと思うのだけれど、知識として使ったことがなかったので、情報の有用性に気づいてなかった･･･。

この中に、Scaledプロパティに関して、次の記述が･･･

Scaled
常に False。True にすると OS の DPI (ユーザが指定した DPI) によってフォームサイズやコントロールサイズが勝手に変更されてしまいます。

（たぶん、コレだ･･･）

早速、すべてのFormのScaledプロパティをFalseに変更。なんでこんな問題を起こすような設定がデフォルトでTrueなんだ？･･･何か、大切な理由でもあるんだろうか？

動かして確認。

これで①の問題は解決。思ったより簡単に解決できて、よかった！

４．exeを高DPI対応に設定

②の文字の大きさについて、Google先生にいろいろきいた結果、こちらもベストと思われる対応方法を発見。

Windows11でアプリやメニューが小さい時に行う高DPI設定

https://win11lab.info/win11-high-dpi/

設定方法は、次の通り。

で、OK → 適用 → OK と順にボタンを押して画面を閉じ、アプリを再起動すると、Formが適正な倍率で表示されてアプリやメニューが見やすくなった。ちなみに「システム」ではなく、「アプリケーション」では表示に変化がなく、「システム（拡張）」ではFontが高解像度化された感じに。

いちどexeにこの設定を実行しておけば、画面の解像度をいろいろ変更しても常にFormは適正な大きさで表示されるようになり、たいへん便利！

Windowsには、ほんとうにいろんな画面解像度の設定があるから、exeに対するこのおまじないは必須なのかもしれない･･･。これで②の問題も無事解決。

結局、②の問題は、プログラムではなく、OS側の設定の問題だった。

５．VCLの幅や高さを自動調整

最後に残った③の問題に取り組む。まず、これがどういう現象かと言うと･･･

手書き答案採点プログラムで、画面を横にスクロールさせるために作ったToolbarコントロールが、本来なら次のように表示されるはずなのに･･･

上の４の設定を行わず、かつ、画面の拡大縮小が100％でない場合には･･･

職場のマシンたちは全部！デフォルト設定が「高解像度」で、画面の拡大率150％だから、何にもしないで僕のプログラムを配布されたままの状態で動かしたら、間違いなく、この問題が発生してしまう･･･。

マジ、困った･･･。

すがるような思いでGoogle先生に援けを乞う。すると･･･

03_高 DPI における画像の描画サイズ調整

http://mrxray.on.coocan.jp/Delphi/Others/DisplayDPI_Image.htm#03

またしても、Mr.XRAYさんのサイトに救いとなる情報を発見！

職場では、僕のことを「困った時の〇〇さん･･･」と呼ぶ人がいるけど、
僕にとってMr.XRAYさんは、「本当に困った時のMr.XRAYさん」です。

これまでにいったい何度、僕の窮地を救ってくださったことか･･･。
あらためてMr.XRAYさんに、心から感謝のありがとうです。

Mr.XRAYさんのホームページにあった情報をもとにプログラムを次のように修正。

procedure TFormCollaboration.btnSelectClick(Sender: TObject);

  //--------------------------------------------------------------------------
  //  ディスプレイの拡大縮小の比率を取得
  //  100% の時は 1.0．150% の時は 1.5 を返す
  //--------------------------------------------------------------------------
  function GetDpiRatio: Extended;
  var
    LXDpi : Integer;
  begin
    LXDpi := GetDeviceCaps(GetDC(0), LOGPIXELSX);
    Result := LXDpi / USER_DEFAULT_SCREEN_DPI;
  end;

var
  ・・・
  //高DPIに対応する
  VCL_Width:Extended;
  VCL_Height:Extended;

begin

  ・・・

  //解像度が変わると不具合がでる
  //r.Right := r.Left+ToolBar1.Width;
  //r.Bottom := r.Top+ToolBar1.Height;

  //解像度の変更に対応
  //幅
  VCL_Width := (ToolButton1.Width + 
    ToolButton2.Width + ToolButton3.Width + Bevel1.Width) * GetDpiRatio;
  r.Right := r.Left + Trunc(VCL_Width);
  //高さ
  VCL_Height := ToolBar1.Height * GetDpiRatio;
  r.Bottom := r.Top + Trunc(VCL_Height);

  ・・・

end;

GetDpiRatio関数を使ってディスプレイの拡大・縮小の比率を計算し、これをVCLコントロールの幅と高さに掛けて、コントロールが適切に描画されるように設定。

こうしてプログラム側でも、VCLコントロールの幅や高さを画面の拡大縮小に合わせるように設定しておけば、exeそのものに「高 DPI 設定の変更」を設定しなくても･･･

これで③の問題も無事解決できた！

プログラムも、僕も、よくなれた☆

それは間違いない･･･から、いいんだけれど。
ひとりでも、戦えるかな･･･

Let me see you through.

空を見上げて･･･

I’m missing you.

そう思えてならない時が、あるんだ。

６．まとめ

（１）様々な画面解像度に対応するには、FormのScaledプロパティをFalseに設定。
（２）画面の拡大縮小に対応するにはプロパティの「高 DPI 設定の変更」を利用。
（３）画面の拡大縮小にプログラムコードでも対応可能。

７．お願いとお断り

このサイトの内容を利用される場合は、自己責任でお願いします。ここに記載した内容を利用した結果、利用者および第三者に損害が発生したとしても、このサイトの管理者は一切責任を負えません。予め、ご了承ください。

「画像のクリック位置とグリッドコントロールの連動」

画像を表示したTImageの任意の１点をクリックしたら、そのY座標に応じてStringGridコントロールの適切なセルを選択するようなプログラムが書けないかなー。･･･と思って、実際に書いてみたら、あまりにも簡単に実現できてしまったお話。

１．やりたかったこと
２．作成したプログラム
３．まとめ
４．お願いとお断り

１．やりたかったこと

次のようなGUIのある採点プログラムを作成した。プログラムはスキャナーで読み込んだ複数枚の答案画像から、設問ごとに解答欄をかき集めて表示するもの（答案画像への書き戻しも可能）。で、採点作業をより一層効率的に行うには、各々の解答欄画像をクリックした際、自動的に採点結果を入力するGridコントロールのセルが選択されたらイイなーと思ったことが、この連動プログラムを書こうとしたきっかけです。

２．作成したプログラム

まず、思ったことはTImageのOnMouseDownイベントを利用すればイイ（画像上でクリックした位置のX, Y座標が取得できる）ということです。早速、imgAnswerという名前をつけたTImageをクリックして選択し、OnMouseDownイベントの右側をダブルクリックして、imgAnswerMouseDown手続きを作成。

次のようなコードを書いてみました！

procedure TFormCollaboration.imgAnswerMouseDown(Sender: TObject;
  Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
begin
  //imgAnswerの高さは、解答欄１つの高さ × 解答用紙数 だから
  //クリックした場所の(Y座標 div 解答欄１つの高さ) + 1 が解答用紙の番号になるはず
  OutPutDebugString(PChar(IntToStr((Y div 解答欄１つの高さ) + 1)));   
end;

実行（F9）して、確認。

必要と思われる変数 i, j を宣言して･･･
あとは Gridコントロールへ SetFocus するコードを書くだけ！

procedure TFormCollaboration.imgAnswerMouseDown(Sender: TObject;
  Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
var
  i,j:integer;
begin
  //imgAnswerの高さは、解答欄１つの高さ × 解答用紙数 だから
  //クリックした場所の(Y座標 div 解答欄１つの高さ) + 1 が解答用紙の番号になるはず
  OutPutDebugString(PChar(IntToStr((Y div 解答欄１つの高さ) + 1)));
  i:= (Y div 解答欄１つの高さ) + 1;
  //SetFocus
  j:= StrToInt(現在選択している解答欄の番号);
  StringGrid1.Col:= j;
  StringGrid1.Row:= i;
  StringGrid1.SetFocus;   
end;

上のコードでは、わかりやすさのため変数（記号）ではなく、そのかわりに「解答欄１つの高さ」等のように説明の文字列で記述しています。また、採点ミスを防止する観点から、Gridコントロールに表示する入力可能な列は、現在選択（＝画像として表示）している解答欄に対応する１列のみとしています。

これで理想としていたカタチの採点プログラムに一歩近づけたように思います。ユーザーに案内したい採点方法は、サっと見て全員が良く出来ている設問であれば、最初に全員正解として得点を一括自動入力し、誤りの解答のみ、解答欄画像を見ながらチェックしてクリック、自動選択された採点欄のセルにゼロ（得点）を入力する方法です。

３．まとめ

案ずるよりナントカといいますが、ほんとうにその通りで、内心、ずっとできるかなー？　なんて思っていたことが、案外、基本的な知識だけで簡単に実現できてしまいました！

//Integer 型で、割り算をしたいときは、整数除算の演算を行う div を使う
A div B  //A ÷ B の商が取得できる

あとは、やりたいことを実現するアルゴリズムを考えるだけですね！
プログラミングしていて、いちばんしあわせで、楽しい時間を過ごせました☆

【注意！】
画像の表示倍率の変更が伴う場合には、表示倍率に合わせてプログラムの変更が必要です。完璧には動作しませんが、ある程度使える（と思われる）表示倍率の変更に対応するコードは次の通りです（クリック位置が画像の下へ行くほど、誤差が大きくなります）。

procedure TFormCollaboration.imgAnswerMouseDown(Sender: TObject;
  Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
var
  i,j,w:integer;
  k:double;
begin
  //imgAnswerの高さは、解答欄１つの高さ × 解答用紙数 だから
  //クリックした場所の(Y座標 div 解答欄１つの高さ) + 1 が解答用紙の番号になるはず
  OutPutDebugString(PChar(IntToStr((Y div 解答欄１つの高さ) + 1)));
  i:= (Y div 解答欄１つの高さ) + 1;
  //表示倍率が100％の時
  if Edit1.Text='100' then
  begin
    i:=(Y div 解答欄１つの高さ)+1;  //このアルゴリズムは記録として残したい
  end else begin
    //表示倍率が100％ではない時
    k:= 解答欄１つの高さ * (StrToFloat(Edit1.Text)/100);
    i:=Ceil(Float(Y)/k);  // <- とりあえずこれで使えるカモ？
  end;

４．お願いとお断り

このサイトの内容を利用される場合は、自己責任でお願いします。記載した内容を利用した結果、利用者および第三者に損害が発生したとしても、このサイトの管理者は一切責任を負えません。予め、ご了承ください。