2026/01/28(水) [n年前の日記]
#1 [lazarus] Lazarusで作ったアプリにSTRINGTABLEを含めたい
Windows11 x64 25H2 + Lazarus 4.4 で作成したWindows用スクリーンセーバに、リソースファイルを含めたい。
リソースファイル内の STRINGTABLE にスクリーンセーバ名を記述してバイナリに含めてしまうことで、「スクリーンセーバーの変更」ウインドウのリスト上に表示される名前を指定できるはず。
Delphiなら、.rc ファイルをテキストファイルとして書いて、リソースを追加することで含めてくれるのだけど…。Lazarus ではどうすればいいのやら。
リソースファイル内の STRINGTABLE にスクリーンセーバ名を記述してバイナリに含めてしまうことで、「スクリーンセーバーの変更」ウインドウのリスト上に表示される名前を指定できるはず。
Delphiなら、.rc ファイルをテキストファイルとして書いて、リソースを追加することで含めてくれるのだけど…。Lazarus ではどうすればいいのやら。
◎ windresでresに変換 :
AI(Google Gemini)に尋ねてみたら、windres を使って .rc を .res に変換しろと言ってきた。
windres はFPC (Free Pascal)に同梱されている。自分の環境では、D:\Dev\lazarus\ に Lazarus をインストールしてあるので、以下にFPC(とwindres)が入ってる。
DOS窓上で FPC が使えるようにするためのbatファイル、D:\home2\bin\fpcenable.bat を作成しておいた。とメモ。実行すると環境変数PATHの先頭にFPCのパスが追加されて、FPCに同梱されたアレコレが利用できるようになる。
リソースファイル(リソーススクリプトファイル) strings.rc を作成。中身は以下。スクリーンセーバ名を記述してる。
windres で .rc を .res に変換。
.lpr にリソースファイル strings.res を読み込むように記述を追加。
この状態でビルドして、出来上がった .scr を所定の場所にコピーして確認。「スクリーンセーバーの変更」ウインドウのリスト上に、今回指定した名前が表示された。
しかし、ソース内では *.res が記述されているから、プロジェクトフォルダ内に .res があるだけで読み込んでくれそうな気もするのだけど…。わざわざ別途指定しなくてもいいのかな…？
windres はFPC (Free Pascal)に同梱されている。自分の環境では、D:\Dev\lazarus\ に Lazarus をインストールしてあるので、以下にFPC(とwindres)が入ってる。
D:\Dev\lazarus\fpc\3.2.2\bin\x86_64-win64
DOS窓上で FPC が使えるようにするためのbatファイル、D:\home2\bin\fpcenable.bat を作成しておいた。とメモ。実行すると環境変数PATHの先頭にFPCのパスが追加されて、FPCに同梱されたアレコレが利用できるようになる。
@echo off @rem FPC (Free Pascal) enable set FPCPATH=D:\Dev\lazarus\fpc\3.2.2\bin\x86_64-win64 set PATH=%FPCPATH%;%PATH% echo Enable FPC (Free Pascal). Add path : %FPCPATH%
リソースファイル(リソーススクリプトファイル) strings.rc を作成。中身は以下。スクリーンセーバ名を記述してる。
STRINGTABLE BEGIN 1, "Lazarus SSaver 1" END
windres で .rc を .res に変換。
windres strings.rc strings.res
.lpr にリソースファイル strings.res を読み込むように記述を追加。
{$R *.res}
↓
{$R *.res}
{$R strings.res}
この状態でビルドして、出来上がった .scr を所定の場所にコピーして確認。「スクリーンセーバーの変更」ウインドウのリスト上に、今回指定した名前が表示された。
しかし、ソース内では *.res が記述されているから、プロジェクトフォルダ内に .res があるだけで読み込んでくれそうな気もするのだけど…。わざわざ別途指定しなくてもいいのかな…？
◎ 自動で変換 :
頻繁に .rc を修正するなら、自動で .res に変換するように指定することもできそう。
これで、ビルドする前に strings.rc を strings.res に変換してからビルドしてくれる。
ただ、これだと毎回変換されそうな…。そう頻繁に変換するものでもないよな…。手作業で .res に変換してもさほど困らない気もする。
- プロジェクト → プロジェクトオプション → コンパイラオプション → コンパイラコマンド。
- 次の前に実行、の「コンパイル」「構築」にチェックを入れて、「実行」のチェックを外す。
- コマンド入力欄に windres strings.rc strings.res と打ち込んでおく。
これで、ビルドする前に strings.rc を strings.res に変換してからビルドしてくれる。
ただ、これだと毎回変換されそうな…。そう頻繁に変換するものでもないよな…。手作業で .res に変換してもさほど困らない気もする。
◎ .rcを直接記述 :
以下を眺めていたら…。
_Lazarus Resources - Free Pascal wiki
FPC 2.4 以降、かつ、windres にパスが通っていれば、ソース中に直接 .rc を記述してもいける、と書いてあるように見える…。
また、FPC 3.3.1 以降なら、コンパイラに -FF を指定することで、windres ではなく fpcres を使うように指示できる、とも書いてあるような…。でも、その -FF ってどこで指定すればいいのやら…。
_lazres - Free Pascal wiki
lazres なるツールもあるっぽい。tools/ の中にあると書いてある。
試しに .res を削除してから、ソースコード内に .res ではなく .rc と書いてみた。
ビルドが通ってしまった。もしかして、これだけで良かったのか…。
_Lazarus Resources - Free Pascal wiki
FPC 2.4 以降、かつ、windres にパスが通っていれば、ソース中に直接 .rc を記述してもいける、と書いてあるように見える…。
また、FPC 3.3.1 以降なら、コンパイラに -FF を指定することで、windres ではなく fpcres を使うように指示できる、とも書いてあるような…。でも、その -FF ってどこで指定すればいいのやら…。
_lazres - Free Pascal wiki
lazres なるツールもあるっぽい。tools/ の中にあると書いてある。
試しに .res を削除してから、ソースコード内に .res ではなく .rc と書いてみた。
{$R *.res}
{$R strings.rc}
ビルドが通ってしまった。もしかして、これだけで良かったのか…。
◎ 余談。Perl側のwindresのほうが新しかった :
余談。自分の環境の場合、環境変数 PATH の中に Perlのインストール場所も入っているけれど、その Perl も windres を持っているので、Perl と FPC のどっちの windres が使われてしまうのかちょっと分からないなと…。手作業で .res に変換したほうが確実だろうか？
確認してみたら、Perl のほうが windres 2.32 で、FPC のほうが windres 2.28 だった。FPC側よりPerl側の windres のほうが新しいから、仮にそちらが使われても問題は無いのかもしれない。とメモしておく。
確認してみたら、Perl のほうが windres 2.32 で、FPC のほうが windres 2.28 だった。FPC側よりPerl側の windres のほうが新しいから、仮にそちらが使われても問題は無いのかもしれない。とメモしておく。
> which windres "D:\Perls\strawberry\5.32.1.1-x64\c\bin\windres.exe" > windres -V GNU windres (GNU Binutils) 2.32 Copyright (C) 2019 Free Software Foundation, Inc. ... > fpcenable Enable FPC (Free Pascal). Add path : D:\Dev\lazarus\fpc\3.2.2\bin\x86_64-win64 > which windres "D:\Dev\lazarus\fpc\3.2.2\bin\x86_64-win64\windres.exe" > windres -V GNU windres (GNU Binutils) 2.28 Copyright (C) 2017 Free Software Foundation, Inc. ...
[ ツッコむ ]
#2 [lazarus] Lazarusでスクリーンセーバを作りたかったけどまたハマった
Windows11 x64 25H2 + Lazarus 4.4 でWindows用のスクリーンセーバを作れそうか試していたけれど、また問題が…。
フルスクリーン表示モードが、期待通りに動かない…。
AI君に尋ねながら色々試していたのだけど、どうやらフォームの OnCreate でフルスクリーン表示を指定するとダメらしい。OnShow のタイミングでフルスクリーン表示を指定したところ、期待した動作になってくれた。
Delphi でスクリーンセーバを作った際は、OnCreate のタイミングでフルスクリーン表示を指定したら問題無く動いてくれたのだけど…。Lazarus は処理するタイミングが違うらしいなと…。
つまり、スクリーンセーバを作りたい場合、Delphi と Lazarus では以下の違いがある、ということになるのかな…。
Lazarus は Delphi の100%互換を目指して開発されているわけではなく、Windows、Linux、Mac上でも動作させられることを目指して開発されているらしいので、他のOSとの兼ね合いで、細かいところでは動作が違ってくるのだろう…。たぶん。
フルスクリーン表示モードが、期待通りに動かない…。
- Lazarus IDE から「/s」付きで .exe を実行して動作確認。
- 「スクリーンセーバーの変更」ウインドウでプレビューボタンをクリック。
AI君に尋ねながら色々試していたのだけど、どうやらフォームの OnCreate でフルスクリーン表示を指定するとダメらしい。OnShow のタイミングでフルスクリーン表示を指定したところ、期待した動作になってくれた。
Delphi でスクリーンセーバを作った際は、OnCreate のタイミングでフルスクリーン表示を指定したら問題無く動いてくれたのだけど…。Lazarus は処理するタイミングが違うらしいなと…。
つまり、スクリーンセーバを作りたい場合、Delphi と Lazarus では以下の違いがある、ということになるのかな…。
- フルスクリーン表示を指定する場合、Delphi は OnCreate、Lazarus は OnShow のタイミングで行う。
- プレビュー画面モードは、Delphi の場合、.ParentWindow にウインドウハンドルを渡すだけで済む。Lazarus は、TTimer 等を使って、親ウインドウが存在していない or 自身が非表示に設定されたかを常時監視して終了するように作らないといけない。
Lazarus は Delphi の100%互換を目指して開発されているわけではなく、Windows、Linux、Mac上でも動作させられることを目指して開発されているらしいので、他のOSとの兼ね合いで、細かいところでは動作が違ってくるのだろう…。たぶん。
[ ツッコむ ]
#3 [nitijyou] ケアマネージャーさんとレンタル業者の方が来訪
ケアマネージャーさんとレンタル業者の方が来訪。12:00-13:30まで作業してたっぽい。
レンタル業者さんが、玄関とトイレに手すりをつけていった。
玄関の手すりは、床と天井を使った突っ張り棒のような仕組みで、縦方向に一本ポールが立っているような見た目。結構太い…。邪魔…。
トイレの手すりは、以前つけていた物と違って取り外しが比較的楽なタイプになった。以前レンタルしていたタイプは便器にガッチリとベルトで固定されていたので、外そうとしてもちょっと無理で掃除が難しかったけれど、今回のタイプは便器の手前に置いてあるだけなので、一旦どかして掃除ができるはず。
レンタル業者さんが、玄関とトイレに手すりをつけていった。
玄関の手すりは、床と天井を使った突っ張り棒のような仕組みで、縦方向に一本ポールが立っているような見た目。結構太い…。邪魔…。
トイレの手すりは、以前つけていた物と違って取り外しが比較的楽なタイプになった。以前レンタルしていたタイプは便器にガッチリとベルトで固定されていたので、外そうとしてもちょっと無理で掃除が難しかったけれど、今回のタイプは便器の手前に置いてあるだけなので、一旦どかして掃除ができるはず。
◎ 床面の材質が不安 :
トイレに設置した手すりだけど、床に接地(?)してる部分が絨毯っぽい材質で…。これは絶対に親父さんが汚すだろう…。小便や大便がくっつくけれど、いいのかな。いいわけないよな…。
こういった製品は表面を拭き取れる材質にしておかないと掃除できないと思うのだけど、設計者はこの手の製品が使われる現場の現状を今一つ分かってないのではないか。いや、滑らないことを優先してこの材質を選んだ可能性もあるか…。考えてみたら排便障害云々よりそっちを優先するよな…。手すりなんだし…。でも、こういう物が必要になると言うことは、利用者の年齢からして周囲を汚しまくる状況にもなるわけで…。もうちょっとどうにかならなかったのか…。
こういった製品は表面を拭き取れる材質にしておかないと掃除できないと思うのだけど、設計者はこの手の製品が使われる現場の現状を今一つ分かってないのではないか。いや、滑らないことを優先してこの材質を選んだ可能性もあるか…。考えてみたら排便障害云々よりそっちを優先するよな…。手すりなんだし…。でも、こういう物が必要になると言うことは、利用者の年齢からして周囲を汚しまくる状況にもなるわけで…。もうちょっとどうにかならなかったのか…。
[ ツッコむ ]
以上、1 日分です。