野鳥紀トップページへ 野鳥の写真集・総合目次へ 観察野鳥一覧表へ 制作メモのページへ ご案内のページへ 一シギ二タカ三ツグミへ移動 動画集「ビデオカメラと野鳥」のサイトへ移動

ページ制作の半自動化メモ(2019年以前)

191022
Runtime Error!

HSPで、珍しく、英語のエラーメッセージに出会いました。
以下の内容で、ダイアログが出て、止まりました。

Microsoft Visual C++ Runtime Library
Runtime Error!
Program:略
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application support team for more information.

困りました。
意味は、翻訳ページで翻訳させた以上には分かりません。

当初、発生したのは、実行ファイルでしたが、試してみると、スクリプトからの実行でも同じメッセージが出ます。
つまり、行番号が出ないので、どこで発生しているのか分かりません。
それこそ、一寸刻みに調べて、ようやくわかりました。

bcopyでした。
コピー対象のファイルがない時に発生していました。
もっとも、プログラムでは、他にも怪しいことを実行しています。
oncmd、onexit、onkeyなどです。
他にも、ユーザー定義関数も見よう見まねで入れています。たいして必要もないのに、です。
これらが、複合しているのかもしれません。

bcopyだけ取り出して試してみました。
普通にエラー番号と行番号付きのエラーがでます。
#Error 12 in line 8()
-->ファイルが見つからないか無効な名前です。

つまり、bcopyのせいではなく、何やら複合的な問題のようです。
先の割り込みなど、ひとつづつ試してみればいいのでしょうが、結論が出るのか分かりませんし、ここで終了とします。




191011
ラベル、変数に日本語が使えることについて

HSPでは、いえ、最近ではどの言語もそうなのかも知れません、変数やラベルに全角日本語が使えます。
使えることは、薄々知っていましたが、ここまで、使っていませんでした。
FEPを起動するのが面倒で、ローマ字で充分と考えていました。

今日、便利な使い方に気付きました。
全角のラベルです。
ここまで、ラベルはアルファベットで、半角のローマ字と片言の英語で作り上げています。
HSPでは、そのラベルの一覧表示ができ、指定するラベルの行へジャンプできます。
しかしながら、プログラムが大きくなると、そのラベル一覧を眺めても、どれが目的の場所なのか、よくわかりません。

そこで日本語のラベルを使います。
サブルーチンのラベルの場所には、普通、コメントを入れて、動作の説明をしてあります。
そのコメント部分をラベルにしておくといいのです。
これで目的の場所がよく分かるようになります。

また、普通に置いているコメントについても、プログラムの区切り等であれば、ラベルにしておくと、目的の場所へ移動する時、分かり易くなります。
例えば、
*配列宣言
*画面作成
*以下サブルーチン
などです。

190821
サイト内検索窓、JavaScript

写真集の総合目次のページにサイト内検索窓を設置しました。
詳しい経過は、別にページを作るつもりです。

本来は、検索窓は、トップページに置きたいところです。その方が機能的で、一般的です。
ところが、トップページはいくつもの作業で書き換えています。
その作業に影響がないようにしないといけません。
そのプログラムを見直した際のメモです。

観察メモ(多分、新規以外は同じ)
GENERATOR行のチェック、書き換え
「☆最近の更新状況」という文字列がある行、およびその前後をチェックする。
更新メモの末尾のデータを削除
メモの先頭に今回のデータを挿入。

新規写真追加
「(写真図鑑)を作りました。(ただ今、」の行をチェックし、この行の数字を書き換える。
あとは上と同じ。

トップページ月々の一枚を更新、
☆月々の一枚、の行をチェック
これの下のリンク行や日付の行もチェックしている

つまり、上の3点を動かさないようにしておけば、変更は可能です。
しかしながら、今更という感じもあります。移動は保留して、リンクを作っただけでお茶をにごしました。

190701
METAタグ、HPB15

HPB15で編集すると、METAタグのMETAが小文字metaに変換されてしまうことに気付きました。
どうやら、総合的には小文字が正しいようです。
<META http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
となっているものが、HPB15で編集が終わると、
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
に変換されてしまいます。

しかしながら、我がサイトでは伝統的に大文字を使っています。
通常は、大文字だろうと小文字だろうと、結果に問題はありません。
しかし、この半自動化作業に影響するケースがある事を心配しました。
プログラムでMETA文を引用したり、修正したりする場合を、数は少ないですが、作ってあります。
昔は大文字(META)が普通だったのだと思います。小文字(meta)のケースを考慮していませんでした。(私の勘違いかも知れません。)

普通は、自動化されているページはHPB15を通さないので、大文字小文字が変換される事はありません。
逆に、現在のこのページのように、自動化できず、HPB15で編集するページは、適当な文章を手書き入力して保存します。
大文字だろうと小文字だろうと、影響なしです。

ただ、稀に、自動化で生成したページに修正を入れる時があります。これにHPB15を使うことになります。
そこで、METAが小文字に変換されてしまうと、ちょっと心配です。

ま、実際に困ったことは、まだありませんし、HPBに解決策がありました。
HPB15の、ツール、オプション、ソース編集のタブで、大文字小文字の指定が出来ます。


190128
Debugウインドウ

HSPのエディタにDebagウインドウなるものがある事を初めて知りました。
マニュアルにもしっかりと書いてありましたけど。

このメニューにチェックを入れておくと、assertで出てくる変数などを表示する窓が常時出ています。
dialogなどで止めるとゆっくり見られるようです。
要するに、assertをあちこちに埋め込んである状態といえるようです。
今まで、assertで苦労したのは何だったのでしょうか。

190110
HSP、戻り値、return、stat、dirlist

HSPでサブルーチンを作ります。
そのサブルーチンで何やら失敗に気づいた時、return 9、として戻るようにしています。
呼び出した側で、帰ってきた時、stat=9なら、何やらまずいことがあったという事で、それなりの処理をします。

さて、そのサブルーチンの中で、dirlistを使いました。
フォルダのリストを取るためにdirlist云々、としたのです。

たまたま、調べ上げたフォルダの数が9個でした。
この数がstatにも入るのですね。
これがいつまでも残っていて、サブルーチンから帰ってきて、呼び出した側でstatを調べると9になります。
これを知らずに、随分悩みました。
正常に帰ってきた時も、エラーが出るのです。

正確には、サブルーチンでの戻り値が9になるだけなのですが。
スクリプトを新しく作る際も、以前作ったスクリプトからコピーして持って来ることが多いものです。
その際、消すのも面倒、残しても実害はない、と思いますね。
結果、偶然、エラーが出てしまいます。


181207
画像読み込み、imgload

これも、画像ビューアのメモです。

スクリプト内での処理速度を調べて、画像をpicloadで読み込むより、imgloadで読み込んだ方が早い事がはっきりしてきました。
picloadで0.8秒程度かかる写真の場合、imgloadだと0.4秒程度で読み込んでしまいます。

で、起動時にまず、全部の画像のサイズを調べる事にしました。
簡単なのはpicloadです。これを使って読み込むと、サイズも取得出来ます。
picloadで、連続で読み込んで調べると、ファイルサイズにもよりますが、読み込み時間が1枚当たり0.8秒で、200枚の写真だと、2分40秒ほどです。
これだと実務上微妙な時間ですが、写真が1000枚にもなると13分以上かかりますので、こうなると実用的ではありません。

そこで、もっと早く画像サイズが手に入らないか調べて、ネットに公開されているモジュールを使わせていただきました。
構造の理解は出来ませんが、多分、ファイルを直接覗いているのだと思います。
これだと、1枚当たり0.13秒です。
200枚程度の写真なら25秒程度で終わります。1000枚でも2分と少々です。
これなら、我慢の範囲でしょうか、実用に耐えるとします。
このように、起動時にまず全部の写真のサイズを取得して、後は全部、imgloadを使って読み込むことにしました。

不思議なのは、同じフォルダを読み込ませるとき、2度目からは極端に早くなります。
先ほどの25秒ほどかかっていたフォルダーが数秒で終わります。
奇怪な話です。
PCを再起動し、実行すると、また25秒程度に戻ります。で、もう一度試すと数秒です。

ただ、1000枚の写真で試すと、2度目の効果はほぼありません。やはり2分ほどかかります。
どこかでキャッシュされているという事でしょうか。HDDでしょうかね。
まあ、実用上は2度読み込むことはありませんので、あまり意味はありません。

読み込み時間は、写真のサイズにも左右されます。
D800Eの1000枚のフォルダも試してみました。サイズが大きくなっています。3分ほどかかります。
そこで、同じサイズの写真ばかりで、枚数が多く、時間がかかりそうな場合は、キー割り込みで止めて、以降を省略できるようにしました。

サイズが混在して、数も多いという場合は、お手上げです。
2000枚の写真がそうであったら、4分あるいは6分待つことにします。
この様な事はめったには無いでしょうし、いざというときは、サイズごとにフォルダを変えて保存しておけば、なんとか処理できます。
お世話になっている、XnViewでも、新しいフォルダの場合、サムネイルを作るために数分待たされますので、なんとなく安心します。
とにかく、imgloadだけで作り上げていきます。

なお、NikonのJPGは特殊な構造の様です。
ネットで提供されているツールには、普通のJPGは読み込めるのに、Nikonの写真だけがエラーを返すものがありました。
少し古い時代のツールなのかも知れません。

詳しく調べたら、バッファもサイズも必要ない高速読み込みのツールがありそうなものです。
勉強不足かもしれません。

サイズ取得に関して、190119追記
写真のサイズ調べ、およそ9MBの写真700枚で試しました。初回では60秒かかりました。2回目は12秒でした。
同じく、サイズ取得に関して、190127追記
写真のサイズ調べ、平均7.5MBの写真514枚で試しました。初回では51秒かかりました。2回目は9秒でした。
PCを再起動して、3回試しました。いずれも1回目51秒、2回目(以降も)9秒でした。
同190203追記
336枚の写真、1回目は31秒、2回目は6秒、
メモリカードからPCに読み込んだ直後も6秒。
キャッシュは共通という事か。



181129
HSP、imgload、ループの回数と時間

引き続き、画像ビューアに関するメモ(思い付きや行き当たりばったり)です。

imgloadを活用したい
最近、写真をバッファに読み込むには、picloadの他にimgloadというコマンドが用意されている事を知りました。
このimgloadはpicloadより高速に読み込めるそうです。
実際に試してみると、picloadのの半分ぐらいの時間で読み込めます。
しかしながら、条件があり、画像のサイズが分かっていないと使えません。
画像サイズを取得するには、一度picloadで読み込めば分かります。
他にもう一つ、直接ファイルを調べてサイズを取得できる方法があるようです。
しかしながら、こちらはちょっと面倒そうなので、現在保留中です。

XnViewについて
ここで、XnViewの動作に思い当たります。
XnViewでは、新しいフォルダを指定すると、まず、キャッシュ作成の作業が始まります。
このキャッシュの意味が今一つなのですけど、サムネイルを作っているようです。当然、画像サイズも分かるのでしょう。
この作業、今調べたら、350枚の写真で1分ほどかけて作業していました。
この間ほぼ何もできません。ただ待つだけです。
しかしながら、一旦キャッシュが出来上がってしまうと、2度目からは瞬時に表示されます。

そこで、唯一私が知っているpicloadを使って、起動直後に全部の写真のサイズを取得するという手はどうでしょうか。
下で計測結果を出しています、写真1枚当たり0.8秒かかっています。
350枚の写真の場合、0.8x350で5分近くかかる事になります。
これでは使い物になりません。

imgloadを使うために
この方法を二つ考えました。
まず一つは、サイズを固定、あるいはその都度指定する事です。
サイズが変わったら、変わるようなら、ボタンか何かでpicloadさせるか、手書き入力でサイズを求めます。

以前はカメラが同じなら、ほとんど同じサイズの写真が出来上がっていましたので、それほど心配することはありませんでした。
ところが、昨今、カメラ側で撮像範囲を簡単に変更出来ます。たまにですが便利に使っています。
野鳥写真はトリミングする事が大半です。私の場合640x480で作っているので100%トリミングです。
どうせトリミングするなら小さい範囲で撮影しておけば、資源の有効利用になります。
連写速度、電池、撮影枚数などに影響するはずです。
ただ、運よく撮影対象に近づけたり、対象が大きかったり、群れだったりすることもあります。
この場合は、出来るけ大きいサイズで撮影します。
つまり、違うサイズの写真が混在する場合が、少なからずあります。
さらに、カメラが複数あると、更に種類が増えます。
サイズが違うとき、その都度、手入力で数値を指定してしまえばいいのでしょうが、ちょっと躊躇します。プログラムらしくありません。

もう一つの方法は、一回目の読み込みにはpicloadを使って、写真のファイル名とサイズを保存して行きます。
2度目からは、その保存しておいたサイズのデータを使ってimgloadで読み込ませる、というものです。
現在、この方式で稼働中です。

時間を測ってみると
この方式で、どの程度効果があるのか、気になります。
そこで、実際にどのくらいの時間を使っているのか調べる事にしました。
プログラム中に時間を測るコマンドを埋め込むことから始めました。

その結果です。
まず、当然、作業時間は写真のサイズ、ファイルの大きさに左右されます。
私の写真のサイズで平均的な、10MB程度の写真の場合を計上してみると、

一つの写真を表示するのに、まずバッファへ読み込みに0.8秒、それを画面の大きさに縮小して表示するのに0.2秒、合計で1秒程かかります。
ここで、次の写真の為に作業はまだ続きます。その次の写真をバッファに先読みしておきます。それにも0.8秒、合計1.8秒程度かかります。

一連の作業に1.8秒かかるのは起動直後の一枚だけです。
普通に、2枚目の表示の時は、先に読み込んであるバッファからコピーします。そのコピーの時間は先と同じ0.2秒程度です。写真は0.2秒で表示されます。
これと、3枚目の新しい写真の読み込みに0.8秒かかりますので、合計1秒という事になります。
3枚目以降も同じです。

さて、バッファ領域を10個分確保してあり、写真が10枚以内の場合はメモリに全部残ります。
つまり、10個全部を表示して一巡した後では、バッファ読み込みの必要が無くなりますので、一つの写真の表示は0.2秒で終わります。

しかしながら、やはり普通は数百枚の写真があります。
11枚目からは、最初のバッファ領域に上書きして、前の写真のデータは無くなります。
この状態で最初の写真を指定すると、バッファのデータは無いのですが、2度目ですので写真のサイズが分かっています。imgloadが使えます。
imgloadでは読み込みに0.4秒程度です。このバッファから写真を表示するのに0.2秒です。つまり、写真の表示は0.6秒で終ります。
その後の、先読みの写真にも、imgloadが使えます。こちらも0.4秒です。合計でも1秒程度で終わります。
つまり、画像サイズが分かっていれば、確実に効果はあります。

読み込み時間はサイズ次第
この間の計測時間は全てファイルのサイズ次第です。
同じサイズでも写真によってかなりの変動があります。
ここでは平均的で分かりやすい数字にしました。
例えば、12MBのファイルの場合だと、picloadの時間は1秒、8MBだと0.5秒程度です.。

実際の表示時間
なお、最初の一枚が1.8秒かかる問題に関して、もう少し詳しく解説すると、
これは実際には、プログラム起動直後の1枚目の写真の場合と、
リストにたくさんの写真があり、バッファもサイズの記憶もしていない場所の写真をマウスで指定した場合に発生します。

この場合にはpicloadで、1枚目の写真を読み込み、更に2枚目の写真を先読みとして読み込みますので、約2倍の時間がかかります。
しかし、写真は1枚目の写真を読み込んですぐ表示されます、遅くても1秒で表示されています。
実際の作業では、表示された写真を残すか削除するか検討する時間がありますので、その間に先読みをすることになります。

1秒で表示されるとしても、実感としてはとても遅いです。
しかしながら、次の写真からは、先読みしたバッファが使え、指定された写真はほぼ瞬時(0.2秒)に表示されます。そして、その写真を眺めているうちに先読み(0.8秒)をする、という段取りです。

まあ、正確にはこれにも条件があります。リストで隣接する写真を表示する場合です。
実際の作業では、カーソルでポインタを移動させますので、普通はこのケースにはまります。

ループに要する時間
この状態でプログラムは出来上がっていて、稼働中です。
しかし、ここで、一つ、気になる問題が有りました。
プログラムにはimgloadも組み込んであり、一回目の、つまり新規の読み込みの時、画像サイズとそのファイル名を配列に入れて保管していきます。
写真を読み込む前に、その配列を調べ、過去に読み込んだものであれば、その画像サイズを使ってimgloadで読み込む、そうでなければpicloadを使うという分岐になります。

気になったのは、この画像サイズが保存されているか調べるループに消費される時間です。
これが、0.4秒に近い物であれば、imgloadを使う意味がなくなります。
先に書きました、picloadで0.8秒、imgloadだとその半分、0.4秒程度ですので。

そこで、ミリ秒までカウントできるコマンド、d3timer()があり、これを埋め込んで調べました。
といいますか、ループの部分だけ取り出して、色々条件を変えて計測してみました。

結果、ループが、つまり写真の数が1000や2000程度では計測できません。0ミリ秒です。
10000回程度から数ミリ秒の時間がかかります。
私の撮る写真は、一日数100枚です。これが、2000枚程度になる事は1年に数回でしょう。
つまり、ループを使ってもimgloadの効果がある、という結論です。

感想
imgloadはスクリプトに埋め込んではあるものの、実用上はほとんど使う状態になりません。
ここでは、imgloadの効果を調べるために、あえてマウスで条件に合う状態を作り上げて計測しました。
実用上は、カーソルキーを使って一つずつ下に移動していきます。
見直すこともめったにありません。

もう一つ、PCの早さです。
8ビットのころのPCですと、1000回もループさせるような作業では、大変でした。
回数を減らせないか、中の演算を省略できないか、悩んだものです。
今では、この程度(12文字の文字列比較を1000回実行)の作業だと計測できない時間なのです。

今後の思い付き
このメモの文章を推敲しながら思いつきました。
サイズ別にフォルダを変えればいいはずです。
極端な話、フォルダ名をその中の写真のサイズにしておけば、プログラムで簡単に判別できます。これでimgloadが使えます。後は、他の作業に影響しないか調べるだけです。
今回の作業が終わったら、この方法で試す価値がありそうです。
違うサイズの写真が1、2枚しかないような場合には抵抗がありますけど。

181005
HSPのバッファ(buffer)の上限

下にもメモしているように、画像ビューアに挑戦しています。
ディスプレイの全画面を使います。
扱う写真は大体12MB程度のものです。しかしながら、全部同じ大きさではありません。
実際には、ほとんど同じ大きさ(画像サイズ)ですが、一応、サイズの違いに対応させます。
そこで、bufferを使います。
写真のサイズを取得するためにもバッファに読み込みます。
それに、小手先の対策ですが、別のバッファに先読みさせています。
そこで、折角バッファに読み込んだものを上書きしてしまうのももったいないので、出来るだけたくさんのバッファを使うようにと考えました。前に読み込んだ写真を見直すことも多いのです。
バッファに読み込む、あるいは直接表示する際には多少の時間がかかります。
しかしながら、バッファにデータがあれば、高速に表示されます。

このバッファに、どうやら上限があるようです。
ただ、厄介なのは、この上限が一定しません。
例えば、12000KB(12MB)の写真では22枚目で失敗します。画素数は6144x4080。
17000KBのファイルでは15枚目で失敗します。画素数は7360x4912。
ここまでは掛け算すると、おおよその上限が見えています。
しかし、5000MBのファイルでは23枚目で失敗します。画素数は6144x4080。
どうやら、原因はファイルのサイズでは無く、画素数起因する感じです。


181018追記
これと同じような現象が(だろうと思います)、XnViewでも発生しました。
試したのは、6144x4080ピクセルの写真です。
XnViewで写真を何枚も開いていると、18枚目でした、メモリ不足というダイアログが出て、開けなくなりました。
用語が分かりませんが、この場合の開くとは、編集できる状態に開く事です。同時に複数開くことは無駄ですけど開けます。これを何枚も同時に開いていきますとエラーが出ます。
さらに、この状態では、プレビューというのでしょうか、大きな写真も表示されません。
7360x4912でも試しました。13枚目か14枚目で失敗します。
やはり、バッファに使えるメモリに限度があるようです。

181204追記
写真の数だけバッファ領域を使えれば、読み込んだ写真のバッファを全部残しておいて、再度必要な時に使うという方法が総合的な写真表示時間としては一番早いと思います。
しかしながら、バッファの領域には何故か限度があります。私の使う画像サイズなら、多少大きくても、10個ぐらいまでがトラブルの出ない範囲の様です。ですので、バッファは10個だけ確保して作業を進めています。

今、私のPCのシステムを調べたら、メモリを8GB積んでいて、残り6GBが使えると出ています。
まあ、何やらあるとして、その半分の3GBでもバッファ領域に使えるならば、写真ファイルは10MB程度ですので、3000/10=300、300枚程度はバッファに使えそうなものだと、まず考えました。
6GB全部なら、600枚をバッファ出来るので、実用上はこれで十分なはずです。

ここで、画像ファイルを調べてみると、
12MBのファイルは、5568x3712=20,668,416ピクセル
10MBのファイルは、4272x2848=12,166,656ピクセル
になっています。

ここから、一つのピクセルに対して、RGBとか24ビットカラーとかありますので、更に何倍か何十倍かが必要なのでしょうか。(あくまで個人の想像です。)
ただ、リソースモニタなど見ても、実行中の使用済メモリはさほど増えません。
という事は、使うのは、メインメモリではなくVRAMのメモリなのでしょうか。
VRAMのメモリは2GB積んでいるようです。
2GBを10分割すると、200MBです。これは20Mピクセルの10倍ですので、なんとなく符合します。
これも個人の想像です。

だんだん悪乗りして、仮説が正しいなら、メモリの多いグラボに変えればいいのでしょう。
調べてみたら、32GB積んでいるものもあるようです。
上の計算が成り立つなら160個ほどのバッファに使える事になりますけど、どうでしょうか。
わたしのPCで使えるのか調べる気にもなりません。値段が120万ぐらいと書いてあります。

181209追記
その後、いろんなサイズの写真で試していて、D800Eの一番大きな写真:7360x4912で試験をしていたら、10枚目でバッファ読み込みに失敗します。ファイルサイズは14MB から18MBぐらいのものです。
9枚目まで大丈夫でした。
よって、今後はバッファ8枚で行きます。

180826
観察野鳥鳥名順目次

観察野鳥鳥名順目次のページを少し改良しました。
データが増えて、ページが広くなって、一画面に入りきりません。
対策は色々考えました。

最良の方法は、ページを分割することでしょう。既に写真集の目次は、そのように分割しています。
ただ、これはプログラムの追随が面倒です。一から作らないといけない部分も出てきそうです。

そこで、今回は、広いページを移動しやすいように、リンク付きのボタンとリンク先のラベルを付ける事にしました。
50音のボタンを作り、ボタンをクリックすると、その頭文字の所までスクロールする、という事にします。
50音です。そのリンクとラベルをそれぞれ作ります。数が多いので、ひたすら面倒な作業でしたが作りました。
今回はボタンを、INPUT type="button"で作りました。一行作って、コピーをして、多少の変更をする、
これを繰り返すと、出来上がります。

ここまで、各所に配置してある同じようなボタンは、文字付の小さな画像を作って、その画像にリンクを設定していました。
こうすると、紛れがありません。ボタンの大きさとか、フォントとかオプションのあれこれに迷わされることなく、思い通りの形で出来上がります。
ただ、数が多いと面倒です。
その為、先の方法で作ってみました。

作業中、文字の大きさで苦労しました。font:12pt、としても反映されません。
正式には、font-size:12pt、でした。

仕上げて、既存のプログラムを走らせてみました。
そのままで動きます。
ただ、特殊な鳥名の時、失敗します。
鳥名の頭文字が変わるたびにラベル用のボタンを置いています。
例えば、あ行の最後、い行の最初にジャンプ先のラベルを置いています。全部の文字に関して配置してあります。
この為、あ、の頭文字での最後の位置に配置するケースで、間にあるラベルのボタンを飛び越えて、い、の頭文字の鳥の最初に配置されます。
当然です。これまでは、そのボタンは無かったのですから。

これに関しては、現在、対策をしていません。そんなケースは、それほぞ多くはないだろうと踏んでいます。
あったとしても、手書きで修正できます。ページでエラーが出るわけではありませんし。

プログラムの対応は、ゆっくり考えていきます。

180912追記
プログラムも対応させました。

180921追記
ツツドリのメモを追加したところ、クロハラアジサシの後ろに新規で挿入されていました。
ク、の列の末尾です。
デバッグした所、ひらがなからカタカナへの変換テーブルで、たちつてと、とすべきところ、たちくてと、とタイプミスしていました。
つまり、ククドリみたいな鳥名に変換されていた模様です。
対応しました。


180818
スマホ用のページの追加、更新

このサイトには、スマホ用のページも作ってあります。まあ、略式というか、簡易的なものです。
今はスマホの時代の様です。しかしながら、対応させるための知識も乏しく、やむを得ず、見まねで作ったものです。
ここまでは写真集のページだけを作ってあり、PC版のページと同期させていました。
つまり、プログラムでPC版と同時にスマホ用のページも生成しています。それだけです。
スマホで写真を見る場合には、まあ使えるはずです。

今回は、もう少し進んで、
観察野鳥一覧表(スマホ版)のページを作る。
当然、スマホ版トップページにそのためのアイコンを追加。
最近の更新状況をスマホ版にも入れる。
という作業を進めます。

調べると、ページは同じものを使い、CSSでスマホとPCとを分けるのがスマートみたいです。
残念ながら、CSSが分かりません。ページを別々に作っていきます。
というか、CSSと表組と、どこが違うのか、表組でも同じようにできるけど、と居直っています。
まあ、それこそ3行前の作業が簡単に出来る、という事でしょうか。

手書きで作る分には簡単です。既に作ってあります。というか、横幅を制限しただけの物です。
ただ、関連するページ数が多いので、いちいち作るのは面倒なのです。
ですので、これを今後、プログラムで生成する、というのが、この一連の自動化の流れです。

プログラムが完成するまでは手書きで対応していきながら、自動化を目指します。
今、プログラムを見た感じ、かなりの部分、PC版のルーチンを引用できそうです。

180821追記
スマホ版観察野鳥一覧表のページの更新と、
これに対応して、スマホ版トップページの最近の更新状況のブロックの書き換え、
をプログラムで対応させました。

また、これに関してのFTPの作業は変更の必要ありませんでした。
ページ生成作業で書き換えるページを、まずバックアップします。
このバックアップと新規に追加するページのログが作ってあります。
このログファイルを使って作業をFTPのプログラムに引き継ぎます。
新しく作ったものを適正にバックアップログに追加すると、FTPは正しく動作しました。

試してみると、まあ、見た目ではですが、正しく動いているように見えます。

最近の更新状況には、観察メモだけでなく、写真集への写真の入替や追加に関するものも含まれます。
もちろん、スマホ版のトップページの更新状況欄にもこれを対応させる必要があります。
ぼちぼち、こちらにも取り掛かります。

180826
写真入替のルーチンは完成、しかし、実行ファイルは未生成。
実際に使う時がいいかなと思って。
180902、若干のバグを修正して、実行ファイルを生成することにしました。


180806
HSPで画像ビューア、oncmd、状態変化の捕捉、onkey、DELキー

作ろうと思ったプログラムは、恐れ多くも画像ビューアです。
画像ビューアには、フリーのXnViewがあり、とてもお世話になっています。
これを真似て、といいますか、真似た物は到底作れませんが、見るだけ、削除するだけの作業なら何とかなるかもと思って始めました。
XnViewに不満といえば更に恐れ多いのでしょうけど、たくさんの画像を処理していくと、途中で重くなることがあります。
これについての原因追及の糸口でも、と思いました。
もう一つは、画像の中心を出すのが、ほんの少しですが、面倒です。
ですので、画像の中心を表示する事が出来、削除が簡単に出来る、この2点に限っては、同じ程度には操作できるようなものができないかとの野望です。

一応完成はしました。
問題は誰でも予想できる、picloadでの画像読み込みの速度です。
こればかりはHSPに関しての私の知識ではどうしようもありません。
1秒は無いと思いますが、それでも多少は待たされます。

この対策は、私なりに考えました。
普通には、画像を表示して削除するか、残して次の画像に移るか判断するのに、多少の時間が必要です。
この時間を利用して次の写真を先読みすることにしました。
通常、ビューアの作業はほぼ100%、上から順番に見ていきます。
ですので、先読みしているなと思える時間を耐えられれば、まあ普通に動きます。
本来は、このpicload若しくはbufferの部分だけでも、他の言語の力を借りるという事なのでしょうが。
あるいは、割り込みとやらで、作業が止まっている隙を見つけて別に作業する、なのでしょうけど。
ただ、picloadの画質に関しては、問題ありません。XnViewとの違いはありませんでした。

また、私のディスプレイ、23インチ、1920x1080専用です。
画面割の関係で、起動時にチェックするようにしました。
更に、私が使っているカメラの写真のサイズ、6144x4080を基準に画像表示部分の枠を決めました。
最初から全画面で使う前提です。そこで写真の比率で最大限の画像を表示させると、横に少し余裕ができます。
この余裕を使って、ファイル名用のリストボックスやボタンなどを配置します。

そういう事で、以下、具体的な手順です。
まず、リストボックスに画像ファイルの一覧を表示します。
そのリストから一つのファイルを指定して画像を表示します、
ボックスでのポインタの上下の移動用にボタンを二つ作りました。
ボタンをクリックするとポインタを加減して移動、表示します
更にもう一つ、削除用のボタンを作って、写りの悪い写真を削除する、という作業です。

これにマウスクリックでのジャンプ移動を追加します。
これにはネットに公開されている、oncmd gosub *aaa,$111(WM_COMMAND)、
を引用させていただきました。
これで、ボックス内でマウスの左クリックを捕捉する事ができます。
具体的な理解の無いまま引用しましたので、トラブル発生は仕方がない話でしょう。

実際、これで簡単にマウスの左クリックを捕捉出来、当然ポインタも動きます。
行を一行ずつ移動する際は、先の上下のボタンも使え。
離れた行への移動はマウスを使えます。
ここまで、マウスだけを使っての操作には何の問題も出ませんでした。
実際、ここまでの分は実行ファイルも作って、まあ稼働させています。

ただ、マウスだけでの作業だと、実際にはかなり窮屈なものがあります。
この手のものは、マウスでも操作できると同時に、キーボードの上下のカーソルキーにも反応して、行を移動できる事が当然です。

また、理想ですけど、この作業は速度が大事です。その為にはカーソルキーでの操作が不可欠です。
実際には、picloadで時間がかかり、快適とは言えません。
この問題は横に置き、キーボードも使えるようにします。
そこで、onkeyやgetkeyを使ってカーソルキーを押した場合を捕捉するようにしました。

iところが、これがうまくいきません。
カーソルキーだけの操作では問題は出ません。
もちろん、マウスだけの操作でも問題なしです。
ただ、マウスを使って行をポイントし、その後、カーソルキーで行を移動しようとすると問題が発生します。
一挙に2行動動いてしまうのです。
スクリプトでは、onkeyで下カーソルを捕捉したとき、
ポインタをインクリメント(+1)して、次の行に移動させます。
しかしながら、実際にはその次の行まで移動してしまいます。+2されます。
この現象は、onkeyでやってもgetkeyでも全く同じです。

さて、私はスクリプトを組む時、プログラムの動きが分かるように、
作業経過を記録する文字型の変数を用意しています。

具体的には、例えば、
ファイルを読み込みました。
リストを表示しました。
画像を表示しました。
oncmdでマウスを捕捉しました。
onkeyでカーソルを捕捉しました。
など、それぞれのステップを実行するたびに記録していきます。

実際には、この際の各種の変数の内容も記録しますので、もっと記録の内容は複雑になります。
そして、実際のスクリーン内にこの変数専用のメッセージボックスを作って随時表示させています。
更には、この変数を、つまり作業の経過を、随時、クリップボードに転送しています。
ですので、プログラムの終了後にテキストエディタに張り付ける事で、作業経過の全容が分かります。
まあ、スクリプトの行動をトレースしながら実行しているようなものです。

しかしながら、原因が分かりませんでした。
経過を見てみると、カーソルキーを押した時、2行スキップしている場合は、
まず、oncmdでマウスのクリックが捕捉されます。この時、ポインタ変数を参照すると、既に1行進んでいます。
その次に、onkeyのルーチンで、カーソルキーが捕捉されています。これでもう1行進みます。
結果、1回のカーソルキー押し下げで、2行進む結果になります。

原因を理解するまでに何日も必要でした。
もちろん私の現在の理解です。これが正しいとは限りません。

前述のoncmdから呼び出すスクリプトは、($111、WM_COMMAND)、
通知コード1の場合は「選択状態変化」 (LBN_SELCHANGE)
if (wparam >> 16 & $FFFF) = 1、となっており  
これは、要するに、「リストボックス内のポインタが動いた」場合に
発生するイベントだという事です。

もう一つ、これらの割り込みに優先順位があり、
oncmdが優先され、その後、onkeyは後回しになる、
前後はするがonkeyの方も実行される、模様なのです。
これが原因だと、私なりには結論しています。

具体的には、
カーソルキーを使うと、まず、oncmdで選択状態が変更されたことに気づきます。
下カーソルの場合は、当然ポインタが一つ増えます。
で、その次に、onkeyが実行され、下カーソルが捕捉され、更にポインタを増やします。
結果、カーソルキー1回で2行動くことになります。

まだ、分からないことがあります。
実行中、カーソルキーだけしか使わない場合には、この問題は発生しません。
カーソルキーが意図通り動きます。
ただし、一回マウスを使って行を指定すると、その後は先ほどの状態になります。
良く分かりませんが、そんなものなのでしょう。

もう一点、カーソルキーを使った場合、onkeyのルーチンに飛び、
そこで、ポインタ変数をインクリメントする段取りなのです。
私の意図としては、カーソルキーを押すと、onkeyのルーチンに飛んで行き、
その中で初めてポインタが動かされます。
しかしながら、前述のトレースの結果を見てみると、oncmdでの割り込みの方が
先になっています。
oncmd、onkeyの順番に実行されています。
不思議な話です。
それと、マウスを使うまでは、この現象が発生しないのは、多分、こういう事だろうと思います。
プログラムの起動時にはこのoncmdの割り込みは準備されておらず、一回、マウスが使われる事で、アクティブになる、のでしょう。

さて、対策は、フラグを立てる事で解決できました。
oncmdのルーチンで、状態変化が認識されたら、フラグをオンにします。
次に、カーソルキー押し下げが捕捉された場合、その直前にoncmdでのルーチンで
状態変化が認識されていないかを調べます。
フラグを参照するだけです。
状態変化が発生していたら、カーソルキーでの移動はスキップします。

このフラグ、試行錯誤ですが、何か所かで初期化が必要でした。
起動直後はもちろん必要です。他にも、一行削除した場合にリストが作り直されます。
この、リストが再表示されたときにも必ず初期化が必要でした。
この時にもoncmdで状態変化を把握されていると解釈するといいのでしょうか。
しかしながら、このリストを再表示したときには、先の状態変化のルーチンに飛んだ形跡はありません。
ただ、リストを作り直した時にも、結果的に、フラグを初期化すると意図通り動きます。

DELキーにも問題がありました。
onkeyの問題というべきでしょうか。
構想では、onkeyでキーボードのDELキーを捕捉して、削除のルーチンへ飛ぶようにしています。
この削除のルーチンで、削除対象のファイルが無いと言って、エラーを出します。
普通、何の問題も出ないところです。

経過を調べてみると、ファイル名のフルパスの先頭の一文字が無くなっています。
このように、文字にしてみると、原因追及のヒントにもなっていますね。
そうです、DELキーが文字列の先頭の文字を削除していたのです。
オブジェクト配置で、最初にmesboxを置いて、ファイルの一覧を作成するフォルダ名を入れてあります。
フォーカスがそこに当たっていて、小さなカーソルがフォルダ名の先頭で点滅していました。
で、まずDELキーが、そこの文字列の編集をした後で、onkeyに引き渡されている、という事でしょう。
理屈では納得は出来ません、不審な動きをする前にonkeyで割り込んでくれ、と思います。
仕方がありません、mesboxの設定で、ボックスを書き換え不可にして、解決しました。

このくらいで、バグ取りは勘弁してもらって、肝心のpicloadのスピードの問題を何とかしたいと思います。

180922追記
objprm msid,mdata
gsel 0

上のobjprmで、エラー3、パラメータの値が異常です。が出ます。
これだ悩まされるのは2回目です。
今回は3日程悩みました。

原因は、gsel 0が下にある事。objprmの上に置けば解決です。
オブジェクトはscreen0に配置します。
写真データはバッファに読み込んでいきます。
読み込んだ直後に、gsel0を使わず、オブジェクトにデータを入れると、そのままではエラーです。


180721
FTP単独作業

単独でFTPだけをするプログラムに改良の必要があります。
独立したページを作成した時、その単独のページをFTPするものです。
作業経過が分からず、心配して、中断してしまいそうになります。
めったに使わないプログラムで、手抜きでした。
こんなものほど丁寧に作らないといけないという事です。

180630
oncmd
HSPで、マウスクリックを取得しようと、ネットの見よう見まねでスクリプトを組みました。
公開していただいている方には感謝しかありません。

以前に同じものを使わせていただいています。その時は思い通りに動いたので、それをコピーして、新しいスクリプトに挿入しました。
リストボックスにフォルダの一覧を入れ、そのリストの一つをクリックすることで、フォルダを移動し、フルパスでフォルダ名を取得する、というものです。
これが動きません。
スクリプトの要点を書き出してみると、こんな感じです。

listbox ptr,100,fbox : リストボックス配置、
hListbox=objinfo(stat,2) ;ウインドウハンドル取得
oncmd gosub *mrtn,$111 ;メッセージ発生時のジャンプ場所宣言
・・・
stop
・・・
*mrtn
if lparam!hListbox:return * ;目的のリストボックスのウインドウハンドルでなければ帰る
if HIWORD(wparam)=1{ ;変化があれば
 sendmsg hListbox, $188 ;リストボックスの行番号を受取る
}
return

この*の場所のreturnをreturn 9、とすると、安定して動きません。
同時に配置している他のボタン類が乗っ取られたみたいで、反応しなくなります。
原因追及に3日ほどかかりました。
スクリプトをコピーするとき、何の気なしに付け足したものでしょう。
全体的に見直す際に、サブルーチンからエラーなどで帰る場合を区別するために9を追加する事はよくあります。
これをしたかもしれません。

もちろん、何故かということは全く分かりません。結果的にそうでした。
深く理解も出来ないものを使わせていただくことの恐ろしさです。

180728
上の、Listboxでのマウスクリック情報取得ルーチンと、onkeyを使ってのキー入力情報の取得ルーチンとの併用がうまくいきません。
見よう見まねで、理解できないも構造を使っている弊害ですね。
何故かキー入力時にマウス情報を二重に取得してしまいます。
私の理解力では対応できません。やむを得ず、onkeyを止めて、getkeyに変えてみる事にします。
(PCメモに書いていた記事を、こちらにコピー。200112)

180531
月々の一枚

月末に使う、月々の一枚のプログラムでは、起動すると候補のリストが表示されます。制作メモなどから当月分の日付の写真を抜き出しています。
そのリストの中から一枚を指定するようにしています。

これについて、今回気付いたバグがありました。
古い日付の写真も候補に挙がってしまうのです。
例えば、4月に撮影した写真を5月になってからアップした場合です。制作メモではアップした日付を記録していますので、このように、古い写真をアップしても当月分とみなしてしまいます。

現在、HSPで他の作業をしていますので、この対策は後回しです。
さしあたっては運用に注意しておきます。

180630
この月々の一枚のFTPに関して、バグがありました。
サーバとローカル側が同じ日時だと、アップロードしようとします。
確か、どれかのFTPでは同じ日時はアップロードの対象に含めないようにしたつもりです。
トップページの更新作業は単純なので、分単位までだと同じになるケースが今後もありそうです。
FFFTPで試すと、ミラーリングアップロードの対象になりません。同じようにしたつもりでしたが。

あれ、スクリプトを見たり、再度実行ファイルを試しても、正しく動きます。
同じ日時の場合は、サーバ側が新しいとみなしてアプロード対象にしない、としています。
AVGを入れ替えた直後で、例の15秒調べます、が出ていた時でした。
誤動作の様です。


180419
プログラムの分割、統合

この自動化のプログラム群に関して、すべて統合するべきか、という事をいつも考えていました。
今、各作業に応じて単独のプログラムを作ってあります。7種類の作業があり、7本のプログラムがあります。
また別に、それぞれに応じたFTPのプログラムを作っていますので、これも7本あるはずです。
他にも補助的な作業が数個あります。全部で20本近くのプログラムがあるはずです。
一応、ランチャーを作ってあり、見た目は統合され、メニューから目的の作業に行きつけます。
ページの生成作業が終わると、それに対応するFTPのプログラムを呼び出すようにしてありますので、さすがに迷うようなことはありません。

ただ、どのプログラムにも同じようなルーチンがあります。プログラムを統合してしまえばスマートだろうと、いつも考えていました。
しかしながら、最近、基本はこのままでいいという事に気づきました。
何故なら、ここにメモしている通り、常に、バグの修正や機能の追加変更などが発生しています。
このために、プログラムは出来るだけ単独の方がいいと思います。
ただ、共通の作業があれば、サブルーチン化、関数化して、どのプログラムからも使えるようにすると、いいのかもしれません。
これからは、各ルーチンの関数化の作業を進めていくつもりです。



180414
新規写真の追加

写真集のページに登録されていない鳥の写真を追加する作業が、時たまあります。この作業用のプログラムも作ってあります。
要するに、新しい鳥種の写真が撮れた時の作業です。

鳥の場合、これで問題はないのですが、更に数少ないケースで、対象が動物だった場合です。
今回、ニホンカモシカの写真を追加しました。写真は何度か撮ってあり、既に2年前に観察メモには入れてあります。
当時の事は覚えていませんが、何故か写真集に写真がありません。今回、写真集にも追加しようとしました。
ここで、問題が有りました。
新規の追加の際には、トップページなどある、ただ今、306枚掲載中、の数字を更新します。
ところが、この数字は鳥以外のものは含まないと公言しています。
しかしながら、このケースでも、数字が繰り上がってしまいます。そのように作っています。

対策は、正式には後で考える事にして、
手書きで全部書き換える事を検討しました。
プログラム化する前は、そうしていたのです。しかし、今となっては自信がありません。
まあ、出来ないことはないでしょうが、面倒さが先に立ちます。ログファイルを見ると、9ページを生成、更新する必要があります。

実際にやった作業は、
作業前にバックアップを作っておいて、
プログラムで、普通に全部作ってしまいました。
作り上げた後で、数字が入っているページ、トップページと制作メモは手書きで修正しました。
写真を入れてはいけないページ、分類順のページです。PC用に2枚、スマホ用に2枚あります。
これを、バックアップの方に差し替えました。
これで、うまくいったはずです。

さて、さしあたっては、首尾よく終わりました。
やはり、プログラムで対応させなくてはいけません。今後の課題です。
ただ、それを使うケースが今後いつ発生するか分かりませんので。


180227
月々の一枚、観察メモ生成

トップページの月々の一枚を更新するプログラムで今月、エラーが出ました。
例によって、実行ファイルでは内部エラーとしか出ませんので、スクリプトに戻って調べました。
スクリプトではエラーの行番号が出ますので、場所は分かります。
そこからさかのぼって調べると、最近追加した鳥名からカタカナ以外を外すルーチンで原因を作っていました。

カタカナ以外をどうやって判別するのか、といいますと、本来は文字コードの大小を比較するものなのでしょうが、コードなどの資料がありません。いえ、探せばどこかにあるのでしょう、面倒です。それに比較するためのコマンドを知りません、調べるのも面倒です。

そこで、よくやる事ですけど、まずカタカナの全部、アからンまでの文字列を作っておきます。
勿論、濁音や半濁音、ッなどの促音なども全部入れておきます。
katakana="アイウ・・・ンッ・・"、といった具合です。

次に、調べる対象の鳥名を一文字ずつ取り出して、この文字列に含まれているならカタカナ、という判定をします。
カタカナ文字列に含まれていれば、新たに鳥名として組み立てていきます。
含まれていなければ、仮名や漢字です、省かれます。

ここを間違っていました。
2バイト文字列が前提です。2バイトずつ取り出して、2バイト単位で比較しないといけないのです。
これを1バイト単位で比較し、組み立てていました。
ここまで、これで動いていました。カタカナ文字列が組み立てられていくのも不思議です。

ところが、今月分に含まれるキレンジャクがうまくいきません。
1バイト単位で比較、組み立てしていくと、出来上がる文字列が、キレンジャャク、になってしまいます。
内部構造の不思議な所です。試してみましたが、他の促音のュとかッ等では正常に通過してしまいます。
とにかく、2バイトで比較していくようにして、解消されました。

ここで気づいた事があります。解決策ではありません。
こういうルーチンは関数にするといいのでしょう。
ここまで、関数についでは不得手で、ほとんど関わっていません。
こういったものを関数化して、末長く使うべきものでしょう。多分。
IsKatakanaとかいうものです。

観察メモ生成に関して、
観察メモの生成でトップページと制作メモへの書込みをスキップする選択が出来るケースがあります。
古い写真を追加する時に使います。

ここまで、FTP以降、使った事は無かったのですが、昨日使ってみたら、FTPでエラーです。
要するに、トップページと制作メモを更新せずに観察メモを作ると、FTPの作業で、この二つがサーバのファイルより古いと判断され、止まってしまいます。

もう少し詳しく解説すると、
問題の発生する直前、前回の観察メモでは普通にトップページも更新し、FTPもします。
すると、サーバーのファイルがローカルより若干新しい日付時間になります。普通は差は1分か2分です。
次に、直後でもいいのですが、別の新しい観察メモを作ります。
この時、トップページをスキップするケースだった場合には、当然、ローカルのトップページは日付が変わりません。
普通に更新されたファイルは、その時の日付時間になります。
これで、当然、サーバより新しい日付になる訳で、FTP作業では、この日付を比較するようにしています。
何かのエラーで古いファイルをサーバに上書きしてしまうといけませんので。
その為、更新をスキップしたファイルをアップロードしようとすると、このチェックに引っかかって、止まってしまう訳です。

元もと、この更新しなかったファイルをアップロードしなければいいのです。
しかしながら、処理が面倒だったので、以下の様な作業になっています。

まず、大きくは、ファイル生成とFTP作業を別々に作りました。
FTPの方では、何をアップするのか調べるのに、本来ならミラーリングでしょうが、時間がかかりそうなのと面倒そうなので、FTPするファイル名などの受け渡しを、生成時に作られたバックアップログでやっています。
バックアップしたものが、今回更新されたファイルです。ログにはこれに加えて新規に作られたファイル類も記録しています。
ただ、スキップしたのを除外する処理が面倒だったので、通常更新するファイルは、一括して全部ログに入れてあります。
これが原因です。

という事で、解決方法は簡単、生成作業の中で、更新していないものはログに入れない、です。
しかしながら、ここで更に問題を見つけました。
バックアップ作業は当然、各ファイルを更新する前に、つまり、全体作業の初めの方で済ませます。
そこで、全部更新される前提で、一緒にログも作っていました。
つまり、スキップするか判断する時にはバックアップに関する作業は、全部終わっているのです。
現状では、スキップしたものをログから外せません。

まあ、改良は試みるつもりですが、さしあたっては、FFFTPの力を借りくことになりそうです。
メモ類をスキップする事は、めったにありませんので。

解決しました。
やむを得ず、個々の作業に応じて、ログを作るようにしました。
専用のバックアップルーチンを作って、逐次、更新対象ファイル名を貰って、ログファイルを作っていくスタイルです。関数にするといいのでしょうが。

180202
sortnote

sortnoteに関して、直下の記事に、エラーを出した話をメモしています。
データの無い変数をソートするとエラーになる、というものでした。
この件に関して、新しい発見がありました。

HSP最新のバージョン3.5安定版では、sortnoteが標準命令に組み込まれて、外部ファイルが必要なくなっています
このメモを遡ると、HSP3.5安定版をダウンロードさせていただいて、使い始めたのが昨年の11月3日です。
10月22日付の実行ファイルがあり、問題のソートが入っているものです。これを実行してもエラーにはなりません。
この時は、当然、3.4か3.5ベータを使っていて、それでコンパイルして実行ファイルを作っているはずです。

ところが、本日、同じ日付のスクリプトから実行すると、このsortnoteの行でエラーになります。
スクリプトは古いものですが、現在は3.5上で動かしています。
同じフォルダにあり、当然、データは同じものです。といいますか、空のデータです。

つまり、3.5のsortnoteの仕様が多少変わっている、多少不親切になった、ものと思います。
対策は簡単で、変数が空の場合はスキップする、を入れるだけです。

180104
年次更新に関するエラー

年末年始に様々な更新作業があります。
プログラムの方にも、毎年スクリプトを追加しないといけない物があります。
今回は、年が変わる事が原因で、というか、その事を考慮していなかったので、エラーを出したプログラムが複数ありました。このまとめを書いておきます。

まず、観察メモのプログラム
毎年年始にファイル名を変える必要のあるページがあります。これに合わせてスクリプトにファイル名を追加する必要があります。ここまでは例年通りで、面倒ではありません。
その上で動かしてみたら、エラーが発生しました。

原因はsortnoteでした。
年始から始まり、データの無い変数をソートするとエラーになります。
新年には観察メモファイルが1個もありません。
このsortnote命令を導入したのが昨年の2月で、この時はファイルが入っている状態でした。
という事で、if分で回避しました。
まだ、完全には整合性を確認できていませんけど、新年最初の観察メモのページは無事生成できました。

ところで、毎年スクリプトを追加する事に関し、そこまで考慮したスクリプトを作れるような気もします。
今後の課題です。

次に、写真集追加のプログラム
これは、新年次という事ではなく、偶然この時期に見つけたもので、元もとあったバグだと思います。
listboxの空白部分をクリックすると、このlistboxのポインタに-1が入るというものです。
その状態でポインタを利用した配列変数にアクセスすると、当然エラーです。
試行錯誤の結果、原因はまずこれに間違いありません。
ただ、この無駄な操作をしなければ意図したとおりに動きますので、もう少し落ち着いてから対策します。

もう一つ、観察メモFTPのプログラム
観察メモの生成では、旧年次の観察メモも生成できるようにしています。
昨年分の観察メモを、年が変わってから生成することもありますので。
このFTP関係のプログラムも、昨年5月ごろ、新しく追加したものです。
つまり、古い年次への対応を考えていなかったものだと思います。
こちらも、頻繁に発生する事ではないので、ぼちぼち対応させます。
もしくは、使い方を考えます。

年次がらみではないのですが、同時期に発生した、見つけたバグがありました。
観察メモに掲載した鳥種が、写真集に何枚登録されているかを調べるプログラムです。
観察メモのタイトルにある鳥名を収集する際に、今回作った、メジロの舌云々、で引っかかりました。
そのような鳥はいないのです。対応できなくなります。
確かに、観察メモ生成では考慮しました。観察メモを生成する途中でタイトルを変更できるようにしています。今回のようなタイトルが作れます。
しかしながら、こちらでは完全に忘れていました。
そこで、付け焼刃ですが、鳥名の欄にあるカタカナ以外の文字は削除することにしました。
今回はこれで解決しましたが、今後に課題が残りました。

同じく、年次に関係なく、トップページの月々の一枚の更新作業にバグがありました
候補になる写真を6枚ずつ表示出来るようにしています。写真が7枚以上あった場合、ボタンを押すごとに次の6枚を表示するようにしていました。
これが6枚ずつ表示はされますが、7枚目がスキップされてしまいます。
2回目は8枚目から13枚目が表示されていました。その次も同じで14枚目がスキップされ、15枚目からになっていました。
困ったことです。原因はまあよくある、0からスタートか1からか、でしょうが、こんなものを見逃してはいけません。

これを作った当初は、月々の一枚は、写真集の写真だけを対象にしていました。
制作メモのページを調べ、写真集へ追加されている写真だけをピックアップして候補としていました。
最近では、その写真集への写真の追加を月に1枚アップするのに苦労していました。
窮余の策として、先日、観察メモの写真も対象にするように改変しています。
ここで、一挙に写真の数が増えて、6枚以上のケースが出てきました。
そして、このバグに気付いた次第です。

ただ、写真の表示は参考としてといいますか、副次的な仕事で、実際には、その月の一枚は、同時にリストしているテキストの一覧から選択するようにしていました。
ですので、バグが本筋の写真の指定などには影響していませんでした。




171222
FTP,PASSIV、AVG
過去のメモと重複しますけど、まとめが大半、あとAVGです。
FTPのプログラムを全部、3.5安定版のパッシブに変更しました。

各ページの生成プログラムからFTPのプログラムを呼び出すようにしてあり、そのFTPのプログラムも全部別々です。8本ありました。
ややこしいですが、ページの生成プログラムはそれぞれ別々のフォルダにあります。
FTPのプログラムは全部共通のフォルダに入れていました。
3.5安定版でのFTP用の新しいフォルダを作り、そこで全部のプログラムを書き直しました。
そこで、この新しい方のFTPを、ページ生成側から呼び出すようにしないといけません。
簡単に変更するため、新しいFTPのファルダを古いFTPのフォルダ名に変えました。

普通ならこれで終わりです。
呼び出されるところに新しいプログラムがあります。
ところが、AVGがあります。
これまでも、実行ファイルを作るたびに、15秒待て、と言われていました。
これが、フォルダを移動したときも、全部、15秒検査されます。
面倒な話でした。

ページ生成側のプログラムを書き直しても良かったのですが、3.5で実行ファイルを作り直すことになります。
その際、どのような面倒があるか分かりません。


171115
HSP3.5安定版、ftpdir
3.5安定版では、ftpdirの動きが違います。
ヘルプでは、
ftpdir p1,p2
p1で指定した変数に、ftpサーバー上のカレントディレクトリ名を文字列データとして代入します。
p2にディレクトリ名を指定した場合には、その場所へ移動を行ないます。
となっています。

現在の実行ファイルは、3.5ベータで作っています。
ここまでメモしている問題はありますが、ftpdirに関してはヘルプの通りに動いていました。
問題はp1に入るカレントディレクトリです。
例えば、ftpdir p1,"homepage"、とすると、
p1には、ちゃんと、/homepage、が入っていました。
なお、3.4版がありましたので、試してみました。
3.5ベータと同じく、正しく(マニュアル通り)カレントディレクトリが入ります。

ところが今回の、3.5安定版では、
p1に、257 "・・/homepage" is the current directory、という文字列が入っています。
つまり、ftpresultと同じものです。

このp1を利用していた箇所が、今の所、一か所ありました。
iif p1!"/homepage":dialog "失敗"
みたいな形で、動作検証をしています。これが全て、失敗になります。

上のftpdirの他、重複しますが、3.5安定版と3.5ベータ版との違いは、
ftpopenでp5のパッシブが使えます。
sortnoteが標準命令になり、hspd.dllが必要ありません。


171108
FTPのパッシブモードの試験
この間の問題が解決しそうです。
というか、私が無知だったのでしょう。
HSP3.5安定版で試しています。
FTPの転送で中断する問題、passiveモードで実施するとエラーが出ません。

下の記事でメモしているプログラム、ftpopenして、ループで同じファイルをアップする、最低限のスクリプトで試しました。
試験でアップするファイルは、4KBほどのHTMLファイルです。

通常モードではやはり、途中で止まります。
結果は一定はしません。ループを例えば50回にしておくと、3回目の起動で、ループの16回目で止まります。確実ではありませんが、このケースが多いです。
勿論、1回目の起動のループの途中で止まることもあります。
3回目まで無事通過する時もあります。ただ、その場合でも4回目、5回目の起動の途中で、ほぼ確実に止まります。

ループの回数を変えて試しました。回数や累計は、あまり意味はなさそうです。
いずれにしろ、最初から動かないという事はなく、何回目かの起動の、ループの途中で、止まります。
プログラムを起動するたびにopen、closeしますので、累計は意味が無いと思います。

ところが、パッシブモードでのオープンなら、今の所、まったく大丈夫です。
というか、通常モードで止まると、さらにもう一回、通常モードで起動しても、確実に同じループの回数で止まります。
具体例として、
50回のループで、3回目の起動の時、ループの16回目で止まったたとします。
次に、もう1回起動すると、そのループの16回目でほぼ確実に止まります。

これを回復するため、1 回、ないしは数回、パッシブモードで起動、転送します。
すると、リセットされる傾向にあり(確実ではありません)、また数回の起動とループを完了できる場合が多いのです。

ここで試したことは、もう一つ、ftpopenのp5で変数が使えるのか、という事でした。
使えます。
私の勉強不足でしょうか、サーバから帰ってくるメッセージだけでは、接続モードがパッシブなのか通常(アクティブ)のか分かりません。
p5を変数にして実行しても、実際にどちらのモードでオープンしているのか確かめる方法が分からず、心配していました。

そこで、上で何回も試して、p5=1の場合は、何度試してもエラーにならない。
p5=0の場合は、上の通りでした。
結果、パッシブが有効である事がほぼ確実に分かった訳です。

これから、3.5ベータで通常モードでオープンしていたものを、パッシブに変更していきます。

171118
現在、逐次、パッシブへの改編中ですが、これを忘れて、通常の作業をしてしまいました。
観察メモのFTPでエラーです。
普通に作業を進めていくと、今まで作ったてある、通常モードのFTPを使ってしまいます。
11個ある内の7個目で失敗してしまいました。
やむを得ず、残りはFFFTPで転送しました。
一応、比較の意味もあるので、今日はもう一枚観察メモを作りました。
こちらは、改編したパッシブで転送するものを使いました。
全部転送できました。
回編を急いで仕上げないといけません。



171103
HSPVer3.5、FTPのパッシブ、dll、バックアップ
まず、用語の問題です。
ここまで、私は実行ファイル(exe)を生成する作業を、コンパイルと呼んでいました。
エディタのメニューなどを見ると、エディタから実行することをコンパイルと呼ぶようです。
exeファイルを生成する作業は、メニューでは、実行ファイルを作る、となっています。
そういえば、コンパイラの他、リンカーとかあったな。
以下、これからも、私の混乱は続きます。

HSP3.5導入
HSPの3.5が正式にリリースされていました。
これまで、3.4と3.5のベータ版を併用していたものを、両方アンインストール、削除して、3.5安定版をインストールしました。(結果、あまりに安直すぎました。以下参照)

パッシブ、hspinet.dllと3.5bの問題
ざっと試してみましたが、この間、懸案だったFTPもそのままで動きます。
やはり、ftpopenの5番目のパラメータ(PASSIVE)は使えないのでしょうか。
そこで念のため、ヘルプを開くと、ありました、省略可能、となっていました。
p5を省略すると、通常モードとの事です。
そこで、コードを訂正して、PASSIVEモードで試してみました。動きます。

ここまで、ftpdirlistがうまく動かなことの解決策として、3.5ベータ版を導入していました。
3.4から3.5に移行するだけなら、そんなに問題は出なかったのだろうと思います。
3.5ベータを導入する際、正式版の3.4も残してあり、3.4と3.5ベータを行き来するので、以下のようなコードにしていました。
if hspver<13568{
   ftpopen hostname,username,password,21,1 ;パッシブモード、3.4
   if stat!0:goto *ftperror
}
else{
   ftpopen hostname,username,password,21 ;通常モード、3.5b
   if stat!0:goto *ftperror
}

これをどちらも
   ftpopen hostname,username,password,21,1
としました。

困ったことに、スクリプトからの実行ではエラーは出ません。
しかし、実行ファイルを作ると、内部エラーになります。
原因は、3.5bのhspinet.dllでしょう。dllを3.5版に変えるとOKでした。
3.4のhspinet.dllも探して見つけましたので試してみました。内部エラーを起こします。原因はもう追究しません。

hspda.dllと3.5の問題notesort
もう一つ、上のトラブルを調べていた過程で、3.5からは、hspda.dllは必要がないことに気づきました。
sortnoteが標準命令に追加されています。
そこで、hspda.asも必要なくなりました。削除しても、当然、動きました。
ただ、hspda.dllを削除すると、3.5でコンパイルした、このプログラムはいいのですが、同じフォルダにある他のプログラムが動かないことになります、多分。
ftp関連だけ全部(7本ぐらいか)、面倒だったので同じフォルダで作業していました。
旧来のフォルダで作業をするなら、削除するのは、全部のプログラムを修正してからになります。
あわてて、このdllを復活させました。

実行ファイルが上書きされる問題
さて、この間、実行ファイルも何度か作りました。
重大なことは、コンパイルすると、古い実行ファイルを上書きしてしまう事です。
そして、古い方はごみ箱にも残らないのです。
3.4も、3.5bも、アンインストールしてしまって、もはやこちらではコンパイルしなおせません。
再インストールする手もありますが、やる気になりません。
インストールの必要ないzip版だとどうなのでしょう。若い方と併用して大丈夫なのか、心配です。
(マニュアルを見直してみたら、併用できるようです。)

つまり、この混乱の途中で、3.5通常版の使用は、もう少し見極めてからにしようと思ったのですが、既に、3.5で実行ファイルを作ったものは、古い実行ファイルを取り戻せないという事態に陥りました。

ここで、バックアップに気づきました。
毎日のバックアップの作業は、その日の写真を整理した直後に行います。
多分、HSPの3.5のインストール前です。
このスクリプト類もバックアップの対象にしてあります。
毎日バックアップするので危ういところでしたが、どうやら、気づくのが早く、助かりました。
バックアップの方は上書きされていません。これを戻しました。

フォルダを別にして困ったこと
この過程で、もう一つやってしまったことがあります。
3.5のスクリプトや実行ファイルは、旧来のものとは別のフォルダを作り、そこに、今回改編した観察メモ用のFTPプログラムを移動させました。
当然、こちらには新しいdllです。
一応、古いdllでも動くことは確かめました。先のp5のパッシブを使わなければ、です。

さて、ややこしい事に、観察メモ生成のプログラムから、このFTPプログラムを呼び出すようにしてあります。
呼び出される実行ファイルは、新しいフォルダにあります。
呼び出す側のプログラムも書き換えないといけません。
当然、こちらも3.5でコンパイルし直さないといけません。
全部のプログラムを書き直して、実行ファイルを作り直さないといけないのです。
更には、この一連のプログラムの為に、ランチャーもあります。これも修正対象となってしまいます。

再度の大転換
ここで、3.5用のものは、呼び出し側もFTP関連も全部、別のフォルダを作る事を考えました。
しかしながら、冷静に考えると、注意する所はftpopenの所だけです。
パッシブが使えることはありがたい事です。
しかし、別フォルダにすると、呼び出し側も変えないといけません。
3.5のdllも3.5ベータで使える事は確かめました。
そこで、更に大転換で、元に戻します。同じフォルダで作業することにしました。
これから、この作業を進めていきます。バックアップを確実に取ってからです。

3.5に変えて、これまでの問題、サーバのファイルリストが取れない、転送途中で中断する時がある、などの問題が解決するといいのですが、これから試してみる事になります。

注意点
3.4と3.5は併用できる。競合しない。
多分、正式版なら、dllは新しいものを使えば問題ない。


171016
写真の並び替え、FTP、観察メモFTP失敗
下の記事の続きです。というか訂正。(この記事は混乱しています。)
どうやら、私のプログラムの方に問題があるかも。
発生した問題は、ftpputを連続して使うと、具体的には16個のファイルを連続してUPしようとすると、15個目で失敗する、というものでした。

そこで、念のため、原因究明のために、単純化したプログラムで試してみました。
f結果の反映の為に、tpresultだけは残し、その他の余計な表示を省きました。
エラー処理も無しです。

netinit、
ftpopen,
ftpdir,
ftpputだけをループに入れて30回繰り返す。つまり、同じファイルを30回連続でアップロード。
ftpclose

この30回の繰り返しも問題は出ません。すんなり終わります。
それどころか、3.4に戻してもすんなり動いてしまいます。
ftpopenはバージョン(3.4と3.5ベータ版)によって引数(オプション、パラメータ?)が違いますので、if文で回避しました。

転送するファイルは一般的には配列でしょうが、面倒なので同じもので代用です。
私のサイトでは大きめに分類されるファイルを使っても、エラーは出ませんでした。

つまり、正常に動かないのはFTPのコマンドにはなく、私が追加している、表示とか、エラー処理とかのルーチンに原因があると言えるのです。
変数などの定義も怪しいかも知れません。ただ、変数は一回見直したことがあり、正しく宣言使用していたとは思います。
いずれにしろ、これから、元に戻ってやり直しです。

171021
本来のプログラムの方を同じように単純化して試してみました。
うまく動くこともありますが、やはり、転送が15個目ぐらいでエラーになる場合が多いです。
単純化するといっても、一応、実情に合わせて作業はさせます。まだまだ、無茶をしている所もあるのかも知れません。

それどころか、問題は出ないと思っていた、上の、完璧に単純化した試験用のプログラムでもエラーが出ることが分かりました。
エラー発生する割合は少ないのですが、ごくたまには発生します。

ここに至って、従来の方法、転送10個目で一旦close、再オープンする、で、しのぐことにしました。
この方法は、下で説明したように、既に使っています。
当初、エラーに悩まされたときに見つけたものです。
つまり、今回は、都合3回ftpopenすることになりました。

171023
観察メモの転送作業でも失敗しました。
ファイル転送数は10個です。フォルダ生成が1つ有ります。
後ろの4個が失敗でした。ファイルの7個目で止まってしまったという事です。
個数ではなく、容量でしょうか。

171025
観察メモの転送は、頻繁に使うプログラムです。慌てて、修正作業に入りました。
表示などを多少変更しましたが、プログラムの骨格は変えていません。
この状態で、試験用のサーバを使って試していますが、失敗しません。困ったものです。

本日、実際の観察メモのページの追加があったので、元のプログラムを使いました。
今回は失敗しませんでした。
どうやら、サーバの調子によるものかも、と思うようになりました。

気になることが一つ、FFFTPでは動かないときにも、時々コマンドを発行しているようです。
調べてみると、サーバは一定時間放置しておくと、勝手に向こうから切断するみたいです。
ただ、私の問題は転送の途中で止まりますので、これとは関係なさそうです。

171109
観察メモのFTP4枚失敗、FFFTPでアップする。
早く、パッシブを導入してみないと。



171015
写真の並び替え、FTP
ここにメモしている半自動化のプログラムの中に、めったに使わない作業で、写真集のページの写真の順番を並び替えるものがあります。
写真集では、一つの鳥種に5枚ほどの写真があります。普通は、撮ってきた順に並んでいます。つまり、一番古いものが一番上にある訳です
また、サイトには各種の目次のページを作ってあり、目次のサムネイルに写真集のページの1枚目の写真を使っています。
たまに、そのサムネイルが、つまり、1枚目の写真の出来が良くないものもあります。

しかしながら、その鳥種を何枚か追加するうちに、まあ、1枚目よりましかなと思えるものも出てきます。折角なので、ここで、写真の並びを変えたい、結果、目次のサムネイルを変えたいという事情が出てきます。
この作業に関してもプログラムを作ってあります。

今回、これを使うケースがありました。
ページを作り直して、終ったらFTPでアップロードする訳ですが、ここでつまづきました。
FTPされません。

ページを生成する方の作業は、これまでに、少ないながらも何度かやった作業です。結果をHPBで読み込んで調べても問題はありません。成功しています。
FTPの作業は、ページの生成の後、更新されたページをアップロードするものです。
これが動いていませんでした。

再度、FTPのプログラムだけを実行できる構造にしてあります。これを実行しても、失敗します。
また、再度試せるということは、何も作業をしていないという事です。一部でも成功していて、部分的にアップロードされていたら、このプログラムが動かないように組んでいます。

不思議なことがあるものだと思って画面を眺めたら、デバッグモードでした。
私の言う、デバッグモードとは、作業は進めていくが、書込みとアップロードだけは回避するモードの事です。
プログラムの編集作業中に、途中途中で動かしながら試します。この時、いちいちアップロードなど実行してしまったら、使い物になりません。
既にサーバにあるものに、日付の古いローカルのファイルで上書きしてしまいます。
これは、このプログラムに限らず、今回のFTP全体の考え方です。更新するページは、日付を比較してローカルが新しい場合にのみアップロードするように手配しています。逆ですと、何か間違っているはずです。

ですので、普通は一回アップロードすると、サーバ側の日付が新しくなって、同じファイルはアップロードできなくなります。
そこで、変数と定義を使って、アップロードだけを回避するようにしてプロフラムを試していきます。
これが私の言うデバッグモードです。

プログラムが完成した後でも、デバッグモードで何度か実行して、大丈夫だという事になってから、実際のモードに戻します。
このモードを変える作業を忘れていました。

実際には、完成後に不具合が見つかることも多いので、完成後もこのモードを行ったり来たりします。
その際、うっかり、デバッグモードのままコンパイルした、実行ファイルにした、という事でした。
そこで、ちゃんとデバッグモードを外してコンパイルしなおしました。

しかしながら、うまくいきません。今度は転送の途中で失敗してしまいます。
この作業は、転送するファイルの数が最大16個になります。今回はその16個でした。
その転送中、15個目からの転送に失敗します。
つまり、残りの二つが失敗するのです。
ただ、完全に失敗するのではなく、10回の内1回ぐらいは成功する事もあるます。

さて、いろいろ試して、最後に、このファイル数の多さに着目しました。
FTPのopenをやり直す事です。

この方法は、既に経験というか実施しています。
初期に、一般的な作業の時でした、FTPでアップロードまではうまくいくのですが、作業後にサーバのファイルの更新日付を取得するために再度ファイルリストを取る段階で失敗していました。

この時に、一旦FTPをcloseして、openし直すと、うまくいくようになりました。
ですので、一連のFTPのプログラムはすべて、作業後のファイルリストを取るために、openをし直しています。
今回は、更に転送の途中でこれをやりました。都合2回openし直す、最初のopenと合わせると。3回もopenすることになります。

これでうまくいっています。
先ほど書いた、一回アップロードしてしまうと、以後はアップローダができない、という構造は、試験用のサーバでは強引に上書きできる、という方式で回避しています。

有り難い事に、私は、LaCoocanに2つのサーバを借りています。
一つは実際のサイトを置いている有料のLaCoocanです。
もう一つは、Lacoocanミニというサーバです。こちらは昔からの契約、多少質は落ちますが、無料です。

このミニの方を、今回のFTPのプログラムを作るにあたって、練習用のサーバにしています。
ここまで、ミニのサーバは、まったく使っていませんでした。

サーバの性質は多分、ほとんど同じで、ミニでうまくいけば、本体の方でもうまく行くのではないかと期待できます。
で、練習用のサーバではやりたい放題、プログラムに必要な部分だけを、本体のサーバからコピーしておいて、追加はもちろん、上書きだろうと、削除してやり直しだろうと、気ままに試せます。

普通は、このようなまれな作業は、ことFTPに関しては、プログラムの試験がほとんどできません。
次に、同じ作業が発生するまで待つ必要があります。
試験用のサーバがあって、とても助かっています。
ここまで、都合10回ほど試して、期待通りの結果になっています。

注目は、他の作業です。
他の作業でも、転送するファイル数が15個を超えるものがいくつかあります。
これの結果を注意しておかないといけません。

171026、
写真集の写真の追加で、既存分が4ページある時、転送するファイルは16枚になります。
今回このケースがありましたが、無事に転送されました。
転送の途中での再オープンの必要はありませんでした。


171007
HSP3.5beta6
HSPの3.5beta6が公開されていました。
正式版ももうすぐできるとの事、一応これもダウンロードしておきました。
FTP関連のコマンドの為に、3.5b5を使っていました。このb6に入れ替えておきます。
beta版は、インストール無しで展開するだけで使える、3.4版と共存できる、ので使っています。


171002
マップファイル
マップファイルに改行が2つ連続で入っている場所がありました。
この原因は、今の所、掴めていません。
マップファイルを編集するプログラムはページの種類ごとに複数あります。
また、今ではほとんどやりませんが、手書きで修正することもあります。プログラムのせいではないのかもしれません。

この問題の発端は、最近追加した新規の鳥種が、マップファイルの予定の場所に挿入されていなかったことです。
調べてみると、改行が余分にあるせいで、この結果になっています。
しかしながら、予定通りの場所ではないですが、構文上は正しく設置されています。
その為、実用上の問題はありませんし、プログラムでも不備を発見できませんでした。
ただ、こういうことが積み重なると、表にトラブルが出てくるかもしれません。

また、この余分な改行が何か所あるのか、調べるのに手間取りました。
何しろ、普通のエディタでは改行を検索できません。
</url>、CR、CR、<url>となっている場所を探さないといけないのです。

TExchangeが使えました。有り難いことです。
これを使って、2か所あることが分かりました。
その2か所を手書きで修正した上で、これから原因調査です。

遡って調べると、数年前のバックアップにも一か所ありました。
それが最近、2か所になっていたということは、何が原因か検討も付きません。
プログラムのミスなら、もう少し数が増えていると思います。

という訳で、次回発生するのを見守らねばなりません。
とりあえず、発生した新規追加のプログラムと、一番よく使う観察メモの生成のプログラムに、チェックルーチンを入れておきました。
必要以上の改行があれば、警告を出すようにしてあります。

現在は、プログラムのミスであれ、手書きでの不注意であれ、発生そのものを防ぐことはできません。
しかしながら、これで、発生した数日後には警告を出せます。
そうなれば、原因も追跡できるでしょう。

また、これまでのプログラムの構造について、反省しないといけません。
写真集のページを生成するプログラム、観察メモのページを作るプログラムなど、作業の種類によって、別々に作ってあります。
そのどのプログラムでも、マップファイルなどの更新作業はほとんど同じです。
制作作業上は、コピーして持ってくるので、別々に作っても作業の手間は変わりません。
多少の違いを修正するだけです。
この方法で、5、6個のプログラムを仕上げました。
ですので、今回のケースではどこで問題が発生しているのか皆目見当がつきません。
やはり、よく理解していないモジュールとか関数とかにするべきだったのでしょうね。

170806
ftpresult
ftpresultを乱用していました。
ここまで、無駄でも発行しておいて困ることはないだろうと思っていました。
しかしながら、ftpresultが有効なのは、つまりサーバからの返事を掴めるケースは、さほど無いようです。
しかも、ftpresult+変数、という書式ですが、この変数を初期化しても意味がありません。
結果はftpresult自体というか、どこかのバッファでしょうが、そこに入っているようで、次に有効な結果が入るまで、前の結果が残っているみたいなのです。
ですので、いくつかのコマンドを発行した後、変数に取り込むと、はるか昔の結果が返ってきてしまいます。

具体的には、ftpputで結果を取り込むと、まあ正常にアップロードした旨の返事を取り込めます。
その次に、ftpcloseして、まあ、無駄かもしれないが、何か返ってくるのだろうとftpresultを発行します。
その結果に、226 Transfer complete
などが返ってきます。

何か変なものをアップロードしたかな、と心配になります。


170805
FTPとAVGとファイアウォール
下にもメモしていますが、FTPのプログラムは、実行すると、AVGやWinのファイアウォールが立ち上がります。
誤動作ですが(多分)、有り難いやら面倒やらです。

毎月一回、トップページに写真を追加する作業があります。この作業も自動化してあります。
その月に追加した写真の内の一枚を選んで、サムネイルとリンクを張る作業です。
簡単な作業で、更新されるページもトップページ一枚だけです。

これも作業後にFTPするようにしました。
今までと同じ、ページの生成が終わると、このFTPのプログラムを呼び出す形です。
さほどの苦労もなく仕上がりました。多分。
何しろ、問題が有るか無いかは、月一回の作業の時でないと完全には分かりません。

実行ファイルを作り、試しに起動してみると、都合3回の警告が出ました。
まず、AVGがマルウエアの疑いがあるとダイアログを出します。これはいつもの通りです。
その次に、Winのファイアウォールがブロックしたぞとダイアログを出します。
これを通過させると、再度AVGからの警告です。
ソフトウェアアナライザというタイトルになっています。
これも通過させて、ようやく正常に動くことになりました。

結局、ページ一枚をアップロードするだけで、何も考えることがありません。起動してすぐFTPオープンです。これは怪しいとなったものでしょう。
ただ、警告が出るのは初回の起動の時だけで、全部拒否すると、その後の起動時には何も出ません。

一応、簡単に動作を書いておくと、
ローカルのファイルリストを取り、index.htmの更新日時を取得、
サーバのルートのリストを取り、日時を調べます、
比較して、ローカルが新しいならアップロード、古いなら何もしない、
アップロードしたら、結果の日時を調べ、新しくなっているかどうか確認、
となります。


170801
FTP、プロセスが残る
FTPのプログラムは、各作業ごとに別々に作ってしまいました。
統一するか、あるいはミラーリングすることで、作業に関係なく出来るはずですが、未だに着手していません。
現在、普通には、ページ生成プログラムの終了時点で、対応するFTPを起動するようにセットしています。
ただ、すぐにFTPせず、一段落した後でFTPだけ独立して使う場合もあります。
この時、いくつも作ってあるFTPの内、どれを起動するのか考えないといけません。
直前に生成されたページはどれかを自分で調べて、対応するFTPを起動する事になります。
まあ、最新のページは、一般的にはバックアップフォルダを見ると分かりますので、そこを参照し、必要なFTPを起動する、というプログラムを作りました。
これも、ランチャーから起動するので、画面を使わないようにしました。
ランチャー、どれを起動するか判定するプログラム、そして、そのFTPプログラムという順番で起動されます。途中では画面はいりません。

ここで、失敗をしました。
いくつかのケースではまだFTPが作ってありません。
この場合には、エラーメッセージを出して、おとなしくendとしたらよかったのですが、stopさせてしまいました。困ったことに、これには画面がありません。
実際には、簡単なエラーメッセージだけが出て、終了したように見えます。しかも、そのエラーの理由が分かりませんでした。
何度か繰り返すうちに、ふと、タスクマネージャーを見たら、同じプロセスが幾つも残っていました。
これで、更に驚いてしまいました。
冷静に考えたら、先に説明した通り、stopで終わっていたからだったという落ちでした。
もう少し、エラーメッセージに事態を詳しく表示するようにしておけば、簡単に解明できたのかもしれません。
更には、重複起動が出来ない様にしておいたら問題はなかったはずです。

170729
FTP、転送一部失敗
07/27、久しぶりに観察メモのページを作り、転送作業まで実施しました。
この所、2週間ほど、ページにするほどの写真がありませんでした。
さて、久しぶりの作業で、問題発生です。
サブディレクトリ作成、写真ファイル、など、正しく転送されていますが、ルートにある6個のページの内、4個が転送されませんでした。
具体的には、ftpputが一部失敗するということです。

そこで、miniへ戻って試すと(サーバのアドレス類が変わるだけで、スクリプトはまったく同じです。)、こちらでは成功しています。

もし、たまたま失敗しているのでなければ、後、考えられるのは、ファイルの量が影響しているのかという事だけです。
ftpdirlistで同じ様な事がありました。
リストされるファイルの数が多い正式のサーバでは失敗し、試験用に組み立てているminiサーバでは失敗しないのです。
これが原因だと、対策は限られてきます。スクリプトを見直してみると、一部に変数の確保量に問題がありました。
元もと、HSPでは変数の宣言もいい加減でよく、宣言しないでいい配列や、確保量が足りない場合でも、プログラム側が手当てしてくれて、エラーは起こさないようになっている様です。
ただ、ファイルリストが上のような具合です。ちゃんと宣言しておくに越したことはありません。

そこで、sdimで確保している変数の数字を増やしてみました。
今回、07/29の観察メモの転送は成功しました。
効果があったのか、偶然なのか、不明ですけど。

170602
FTPその後、HSP3.5batea5

HSPのページを調べたら、3.5beta5が出ていました。完成版に近いと読める解説でした。
インストール作業はbeta4と同じで必要ありません。zipファイルを展開するだけです。同じく3.4と共存です。
beta4を削除して、同じフォルダにbeta5を展開しました。
スクリプトエディタのアイコンは3.5beta4と同じフォルダになりましたので、同じものを使えます。
3.5beta5を使いたいときは、そのエディタを起動して、ファイルメニューからスクリプトを読み込みます。
3.4のエディタも残してあります。まだ、一般的にはこの3.4を使います。
スクリプトのダブルクリックでも、こちら3.4正規版が起動します。

そういうことで、FTPに関してのみ、beta5を使います。

ftpdirlistは正常です。

clipsetが懸案でしたけど、正常に動きます。単純にループで試して、200回連続してもエラーにはなりませんでした。
でも、多少心配なので、終了時一回だけ使うことにします。
完成した後では必要のないコマンドですが、これを終了時に発行しておくと、プログラムを閉じた後でも作業の経過が読めます。読める様になります。

clipsetの使い方ですが、プログラム中にテキストとして使える文字列変数を確保しておいて、逐次、プログラムの経過を追加していきます。メモリノートパッドです。

例えば、
ここでFTPをオープンします。
ルートのファイルリストを取得しました。以下、そのリスト。
".",<DIR>,2017/07/11,20:40:00
"..",<DIR>,2016/03/04,00:00:00
"b_index.htm",45837,2017/07/14,22:02:00
・・・

などどいうようなテキストを、場所場所で追加しておきます。
普通はこれを、dialogしたり、専用の窓に表示して進行状況を見ています。
更にこれを終了時などにclipsetしておくと、今度がプログラムが終了してからでも、プログラムの動きが分かります。デバッグに使えるという訳です。
HSPのスクリプトエディタを開いている状態で、メモ帳などで貼り付けを実行すると、クリップボードに残っているプログラムの経過を見ることができます。

当たり前ですが、この点、困ることもあります。
プログラム終了時に、クリップボードの内容が変わることを忘れることがあります。
普通は、エディタでスクリプトをあれこれ変えながら、プログラムを実行しています。
そのエディタでもコピーなど多用しますので、プログラムが終了したとたんに、クリップの内容が変わってしまいます。
逆に、後でプログラムの実行結果を見直そうと思っていても、エディタでコピー操作をしたとたんに消えてしまいます。

ftpopenは、やはり5番目のオプションでエラーになります。
beta5専用のマニュアルでもオプションは4個です。
パッシブが使えないのか、私が知らないだけなのか分かりません。
まあ、アップロードは通常モードで出来ますので、問題はありません。今のところ。

ちょっとした違いは、beta5のエディタを起動したとき、初回だけでしたがAVGが立ち上がりました。
実行ファイルを作ったら、必ず初回の起動の時、AVGが立ち上がり、スキャンが始まるのは前と同じです。
実行途中で再度ブロックされることは、今回はありませんでした。

asファイルはコピーの必要はありませんでした。
dllは必要でした。実行ファイルの時だけだったと思います。スクリプトと同じフォルダに置きます。
これは、beta5のフォルダにあるものをコピーしました。

見切り発車部分もあります。まだ、観察メモの分だけの完成です。

使い方は、例えば、観察メモのページや関連ファイルを生成し、終了時点でこのFTPのプログラムを呼び出す形を考え、そのようにしてあります。
FTPの必要なファイルを見分けるために、観察メモ生成で作ったバックアップファイルのログを見ています。
この際、更新したファイルはもちろん、復元作業の際に必要になるので、生成したフォルダ名や新規の写真ファイルなどもログしてあります。
これを読めば、FTPの必要なファイル、生成されたページや写真、更新されたページなどは簡単に分かります。

この方式で困るのは、ログファイル名やバックアップフォルダ名を生成した日付時間を使って作っていることです。
つまり、試験運転の時でも、バックアップフォルダ名などがその時の日付時間を使うのですが、実際には、試験ですのでバックアップフォルダなどは実際には生成されません。
そのフォルダがないと、今度はFTPのプログラムが動きません。

もちろん、FTPのプログラム単体でも動くようにしてあります。
観察メモ生成プログラムからオプション付くで起動した場合は、そのオプションを参照し、
オプション無しで直接起動した場合は、最新のバックアップフォルダを参照します。
本来は、サーバとローカルのファイルの時間を比較して、新しいものだけをアップロードするといいのでしょう。つまり、ミラーリングです。
しかしながら、これはとても面倒ですし、実行時間もかかりそうです。取り上げません。

もう一つの問題、そのままアップロードする事の問題点です。
これまでは、自動化で作ったページ類を一旦HPBで読み込み、構文エラーやリンクエラーを点検し、異常がないことを調べて、FFFTPでアップロードしていました。
これを生成と同時にアップロードでは、その点検ができません。
アップロード後、つまり公開した後で点検という段取りになります。多少心配します。
まあ、今まで、生成に失敗した経験は、ほぼありません。アップロードそのものに問題が無ければ大丈夫でしょう。

観察メモを作るとき、トップページと制作メモのページの更新をスキップするケースがあります。
この場合、FTPが動きません。更新リストの内、どれか一つでもローカルのページの更新日時が古いとFTPしないようにしています。
この原因は、参照している制作メモのバックアップログにあります。
面倒だったので、場合分けをせず、バックアップのリストに入れておきました。
バックアップからの復元の際にも、同じものだから、まとめて復元しても支障はないと考えました。
そのため、ここにきて、このFTPで支障が出ました。
やむを得ず、このケースではFFFTPを使うことにします。件数としては、さほど発生はしません。

また、写真ファイルだけ先にアップロードしてある場合があります。
作った写真を忘れないようにと、アップロードだけしておけば観察メモのプログラムでチェックできる体制なのです。
これも裏目で、先に写真がサーバにあるとFTPを止めるようにしています。
こちらは、結構な頻度になると思います。対策が必要です。(対策しました。)

更新ファイルの内の数個がアップロードされないケースに遭遇しました。
原因不明です。発生率は高くありません。正常にアップロードされることがほとんどです。
気楽に試験ができませんので、厄介です。
試験用のminiで試していますが、例えば原因がサーバの重さだったりすると意味がありません。
理屈は不明ですが、先のトップページなどのアップをスキップするケースと関係があるかも。
この件、実際に作業をしながら点検する以外にありません。

170610
ここまで、問題点を含みながら、仕上げました。
動いてはいます。

170621
最終的に、アップロードが完了しているかチェックするルーチンを作って、これは完成。
続いて、写真追加のプログラムにも対応させるつもりです。

170630
観察メモのFTPは稼働しています。
ただ、昨日、アップロード後の検査のルーチンで異常が出ました。
アップロード後に更新日時を調べて、新しくなっているかをチェックします。
この、作業後のファイルのリストを取ろうとすると、うまくいきません。
実際にはアップロードは成功しているのに、ファイルリストの取得に失敗するので、結果が出ません。
サイトへのFTPの作業ですので、繰り返して試験できる状況ではありませんが、幸い、もう一つ、サーバがあります。LaCoocanミニです。こちらは現在、具体的には使っていません。
これを使って、アップロードしてはFFFTPで削除する、という作業を繰り返しました。
しまいには、新しいファイルでも強引に上書きするようにして試しました。
すると、どうやら時たま失敗するケースがあります。つまり、まったく原因不明です。
失敗する時は、ftpdirlistでリストを取ろうとすると、いつもと違って少し待たされます。それでもリストは返ってきます。しかし、次のディレクトリ移動、ftpdirに失敗しているようです。

試しに、アップロード後に作業結果を調べるルーチンだけ動かしてみました。
つまり、ftpdirlistとftpdirを数回繰り返す作業です。
これを、ループにして繰り返してみました。
すると、最初の数回は成功するのですが、4、5回目に必ず失敗します。

170705
ftpのlistはスタンダードでもopen後の最初の一回は成功していることに気付き、完了検査でのリストを取る前に、一旦closeしてopenし直してみました。
これでうまくいきました。
このスタンダードでも試してみました。こちらはこの対策前では必ず失敗していましたが、openし直すことで成功しました。
試しに、リストだけを取るルーチンを3回繰り返してみても失敗しません。
単なる想像ですが、やはりファイルの数が影響しているのかも知れません。
実際に使っているこのスタンダードでは、ルートに置いているファイルが160個あり、試験で使っているミニの方は30個ほどしかありません。

観察メモ生成に続いて写真集の追加のプログラムからもftpを呼び出すようにしました。
この二つで、自動化の作業の98%程度をカバーしていますので、これで良しとします。
後は、個別に対応するのでなく、ミラーリングのまね事で対応したいと思っています。
残りの2%も大半、写真集がらみの作業です。一括してミラーリングで対応できるはずです。

170725
FTPに関しては、ここでひと区切りとします。
観察メモのページ、写真集への追加、新規、入れ替え、の作業に対応して、FTPでのアップロードまで自動化できました。
あと、些少の作業が残って、その分は別にFFFTPでアップロードすることになります。作業割合からすると、積み残しは1%以内です。

それよりも、今後の課題があります。
FTPが遅いのです。
いえ、アップロードに関しては、10数個のファイルのアップロードが多分、数秒程度で実行されています。
時間がかかるのはサーバのファイルリストを作る作業です。
写真集の追加などの作業では、対象のファイルの数は、5つのディレクトリに2000個程度です。
つまり、5回ftpdirlistを発行します。計測してみたら、1分50秒かかっていました。
このセットを2回やります。アップロード前とアップロード後です。
アップロード前は、当然、アップロードしていいのかチェックするためです。
アップロード後には、ちゃんとファイルが新しくなっているかを調べます。
合わせると、一回の作業で4分ほどかかっています。
これでは、ちょっと退屈してしまいます。

FFFTPでの作業では、リストは瞬間的に表示されます。
ミラーリングを調べるのも数10秒で終ります。ことによるとキャッシュされているのかもしれません。全部のディレクトリを走査しているようには見えませんので。
ミラーリングに関しては、FFFTPではアップロード後には検査を実施しませんので、そこらあたりが考え所かもしれません。

もう一つ、このミラーリングが出来れば、プログラム毎にFTPを作り替える必要は無くなります。
しかしながら、未だに着手していません。

170818
積み残してあったトップページを月々の1枚で更新した際のFTPは170806に仕上げました。
生成作業から連動するように仕上げてあります。

もう一つ、最後に、その他のページのアップロードができるようにしました。
これはページの生成作業には関係なく、指定の1ページを独立してアップロードするものです。
独立したページを作った時、あるいは部分的に修正をした時などに使えます。といいますか、面倒をいとわなければどの作業でも使えます。
1ページずつ、繰り返してアップ出来ますので。
起動は、その他のページの生成作業にボタンを追加して、独立したボタンで起動する様にします。
例えば今、このページを更新していますが、この作業は自動化してありません、出来ません。
作業後に、このページをアップする時に使えます。
ま、FFFTPを使えば、スマートで、早いのですが。

これで、全部の作業に対応しました。
改めて気付きましたが、この、その他のページのFTPをするプログラムを発展させると、ミラーリングも可能でしょう。
一つのファイルの更新日時の比較は出来ています。これを全フォルダの全ファイルに適用するだけです。
文章では簡単ですが、実際の作業はとても面倒(多分)なのと、実行時間の目途がつかないので、当分様子見です。
HSPのFTPの限界かもしれないと思っています。
ファイル数にも依るのでしょうけど。

ここまで来て、作業が逆だったことに気づきました。
最後に仕上げた、単体のページのアップロード作業、これを最初に作って、後、全部の作業に拡張していけば良かったのだろうと思います。


170503
FTPの自動化

サイト開設以来、かなりの月日が経ちます。
このサイトの維持管理に関して、様々なツールを使わせていただいています。
その中の一つがFFFTPというFTPのツールです。
このページで経過を書いているように、HSPというプログラミングツールのおかげで、ページの制作はかなり自動化出来ています。
そのページを生成した後、FTPのツールを使ってアップロードしています。

今回、ふと考えたことが、HSPにFTPのコマンドは無いのか、ということです。
なんと、調べたら、これがあるのです。
FTPが使えたら、写真を撮りさえすれば、正確には、既定の規格の写真を作りさえすれば、ページの生成、関連ファイルの更新に続き、サーバへのアップロードまで自動化できます。
現在、この準備中です。

具体的に、ファイル単体で試験してみると、FTPでアップロードは出来ます。
あとは、具体的に作ることと、ページ生成のプログラムと連結する事です。

ページ生成のプログラムは分類別にたくさんあるので、それぞれのプログラムに組み込むより、FTPの作業だけを別プログラムにして、ページ生成のプログラムからコマンドオプション付きで呼び出すようにすると簡単なように思います。
まだ、本来のサーバでは試していませんけど、幸い、試験に使えるサーバがあります。
無料で借りているFC2と、先日取得した、このサーバと同じLaCoocanのミニです。
特にLaCoocanミニの方は、設定などが実際のサーバと同じでしょうから、このような試験にはとても有り難い存在になりました。
ミニで試験してみて、問題が無ければ、後はサーバ名などを変更するだけでいいのだろうと思います。
ここまで、ミニの方は何も使っていませんでした。
そこで、今回の試験のために、最小限のファイルやフォルダ構造をコピーして試しています。

さて、これが結構トラブル続きです。以下コマンド別に書き分けます。

ftpdirlist、ファイルの数が多いと、うまく動きません。
当初、数個のファイルとフォルダで試したときは問題はありませんでした。
しかし、実際のファイルはフォルダごとに数十個あります。これに近い数で試してみると、ファイルリストが取れません。厄介なことに、エラーが出ません。空白かゴミを返しているようです。
既にサーバにあるファイルに対して、上書きになるのかどうかの判断は、とても重要です。
これが空白などを返されると、対象のファイルは存在しないと判断してしまいます。
そのまま実行してしまうと強引に上書きされることになります。

対策を調べていたら、どうやらHSPの3.5beta版で対応しているようです。
そこで、3.5beta4を導入しました。
3.5betaはzipファイルを展開するだけで使います。現行の3.4と共存できます。
3.5betaのエディタのアイコンを作っておき、エディタを起動、ファイルメニューでソースファイルを読み込むと3.5betaが使えます。
3.4を使いたいなら、そのままソースをダブルクリック、あるいは3.4のエディタを起動です。
ftpopen、3.5beta4でパラメータが多すぎるとエラー。
3.5betaでは、問題が色々と発生していますが、この1点、ftpdirlistが動きます。
これに比べたらほかの問題は何とか対応出来ますので、3.5betaを使います。利用するのは、このftpのプログラムだけですし。
このエラーは、ftpopenの5番目のパラメータを省略すると回避できました。
つまりパッシブを使わない事です。
今まで、ftpはパッシブでないと使えないのかと思っていましたが、この状態で試すと、通常モードでも送信できることが分りました。
なお、調べてみたら、3.5のマニュアルがありました。それによるとftpopenのオプションは4個です。つまり、正常な動作でした。
そうすると、パッシブはどうするのでしょうか。
ftpcmdというコマンドを見つけました。試しましたが、うまくいきません。
やはり、通常モードでいくしかないようです。
clipsetが3.5betaで不調です。
デバッグの為に、clipsetを多用しています。実行ファイルが完成した後では無意味なコマンドです。
実行途中の経過を、逐次、変数に入れておいてクリップボードからメモ帳などに移して調べます。この内容が膨大になればなるほど、テキストの検索などが使えますので重宝しています。
プログラムの経過は、assertはもちろん、mesboxやdialogでも表示させます。
しかしながら、clipsetで残しておけば、プログラムを終了させた後でも調べられますし、当然、メモ帳の検索機能なども使えます。
このclipsetが3.5betaでは不調になります。
ただ、5〜10回ぐらいまでは使えています。何回か発行するとエラーになります。まったく理由は分かりません。
普通は、スクリプトの途中途中に差し込んでおくのですが、このおかげで、プログラムの終了時点に一回だけセットしてしのいでいます。

ftpcloseの位置の考慮が必要。
ftpopenしていない状況でftpcloseを発行するとエラーが発生します。当たりませかもしれません。
プログラムの都合でftp作業に行く前に終了することもあります。

sortnoteでエラーが出ます。
3.5betaを使うにあたり、asファイルやdllファイルを集めてソースと同じフォルダに置きました。
これがいけないようです。試しに3.4に戻って実行するとsortnoteでエラーです。
asファイルを削除すると、ここでのエラーは出ません。

新しいAVG17が実行ファイルの邪魔をしています。
色々あって、実行ファイルを作って試してみました。dllなどの問題は実行ファイルを作ってみないと分かりませんので。

いつでも、AVG17が邪魔をします。
ここまで、HSPで作ったものがAVGから警告を受けることは、まったくありませんでした。
今回、AVG17に変わって以降、HSPで作った実行ファイルは全部、AVGから警告が出るようになりました。
普通は、しばらくすると、調べた結果、大丈夫でしたとメッセージが出て終わっています。
そして、2回目からの実行では警告は出なくなります。

このFTPのプログラムも、同じく起動時に警告が入り、同じように問題なしとなりました。
善意で考えると、変な通信が始まるかどうか見定めている、と解釈できますけど。
それならそれで、一回目の実行では何もせず、何回目からその手の仕事をするようなコードを作った場合に対応できるのでしょうかね。

ただ、今回は、ftpopenでしょうか、ftpputでしょうか、FTPが動き始めるタイミングと思割れる時間に、再度割り込まれます。
突然、FTPですからね、まあセキュリティ上は無理からぬとは思います。
しかしながら、今回は無事ではすみませんでした。AVGから、マルウエアのようなので隔離する、よろしいか、と尋ねてきます。
困ったことに、どうも選択肢の説明が曖昧です。直訳なのでしょうね。
それでもどちらかといえば無難な方を選べばよかったのでしょう。
しかしながら、物は試しと、多分こちらが隔離だろうなと思える方を選んでみました。
すると、当然のことでしょう、実行ファイルが消えてしまいました。

まあ、隔離なのだから、その隔離を解除したらいいだろうと、AVGの設定を調べました。
しかしながら、この隔離を戻す方法が分かりません。戻せません。
隔離してあるメニューまではたどり着きましたが、どうやっても戻せませんでした。

そこで、仕方が無いので、HSPで再度コンパイルしました。同じ実行ファイルができるはずです。今度はその実行ファイルが生成されません。exeの代わりに、拡張子がdpmというファイルが出現します。
AVGの仕業でしょうか。監視しているのでしょうね。
そこで、やむを得ず、AVGを止めた状態でコンパイルしました。これでようやく実行ファイルが出来上りました。
これを実行すると、同様にAVGから警告が出て、隔離していいかと選択を迫ります。
ここで今回は隔離しない方を選ぶと、ようやく完成でした。
その後は、同じファイルなら、2度目からは何の警告も出ません。

AVGの誤認識?について、
実行ファイルが同じ名前の場合でも、コンパイルしてファイルのタイムスタンプが変わると、初回の起動の時、警告が出ます。マルウエアかもしれないという警告です。しばらく待つと、大丈夫だった、となります。また、これは2回目以降の実行の時は何も出ません。

実行途中で、Winのファイアウォールみたいなものからも、たまに警告が出ます。
やはり、FTPを使うタイミングの様です。許可を求めてきます。
もちろん許可します。許可しない、を試したことはありません。

AVGの警告に関して、
FTPがらみで、最新の作業が何だったかを調べて、そのFTPプログラムを起動するプログラムを作りました。これをAとしましょう。
普通は、ページ生成のプログラムの終了時点で、その作業に対応するFTPプログラムを起動するのですが、対応次第では、後でFTPするケースもあります。
つまり、このプログラムではFTPしませんが、これから起動するプログラム(これをBとします)にFTP作業があります。
AVGはAが起動されると、15秒間の警告を出します。(上に書いた通りで、初回起動時だけですが。)
しかし、すぐにBが起動されてしまっています。
これで大丈夫なのか心配してしまいます。




170502
トップページの「月々の一枚」の写真の入れ替え

毎月、月末になるとトップページの更新作業があります。
月々の一枚、としている段落の写真の入れ替えです。
簡単な作業です。関連するページもありません。これまでは手作業でやっていました。
他の作業が一段落していて、この際、プログラム化しました。
まず、更新の候補となるものは、その月に写真集へ追加した写真です。これを制作メモのページから抜き出し、リストアップします。
このリストから1枚を指定し、トップページへ追加、同時に掲載してある最も古い写真を1枚削除します。
この際、撮影日を取得しますので、その写真集のページへのアクセスも必要でした。
今回の分から稼働させました。今月のキジの写真はこのプログラム経由です。

170310
観察メモ、未作成フォルダの表示

観察メモの生成に関しての問題です。
写真は準備してあるのに観察メモをを生成していない場合があります。
理由はいろいろあります、写真をたくさん撮った時などです。これを忘れてしまう時があります。
この未生成の写真がある場合に警告するようにしました。

観察メモの場合、日付と鳥名を組み合わせたフォルダを作って、そこに写真を配置してあります。
で、起動時に、そのフォルダをチェックして対応するメモファイルがあるかどうかを調べます。
手こずったのは、メモファイル名を単純に作ったので、同じ日にいくつもフォルダを作ると重複が起きる場合がある事です。
勿論、ファイル名生成の際は重複を回避するように作ってはいます。

まあ、年に一回発生するかどうかの事なのですが、このせいで未生成かどうかが分かりにくいのです。
この処理に時間を取られてしまい、ようやく完成しました。
ですが、今後は、とにかく写真を準備だけしておけば忘れさられる事はなくなりました。

170218
バックアップ方式の変更、レストアのプログラム、古いバックアップファイルの削除

下にメモしてあるように、バックアップの方式を変更しており、現在は、日付を使ったフォルダごとにバックアップファイルを保存してあります。
レストアのプログラムもほぼ完成しました。
ただ、このレストアに関しては、実際に必要になるまで封印というか、試すことはできても実行はできないようにしてあります。
動作試験が面倒なのと、実際に必要な場面があるのかどうか、ということです。

ただ、不必要なバックアップが増えていきます。
以前は、一つのフォルダに全部のバックアップファイルを入れていましたので、どんどんファイルが増えていき、古いものを捨てることが絶対に必要でした。
ちょっと調べてみたら、半月分でフォルダ数15、ファイル数114でした。
以前の方式だと、一つのフォルダにファイルが100個置いてあることになります。
やはり、我慢の限界に近いものがあります。エクスプローラでスクロールが必要になるのが嫌なのです。
以前は、手動でちまちま削除していました。
今回は、ファイルがそれぞれの日付付きのフォルダに保管されています。
バックアップファイルの必要な期間は、実際、のところ数日だと思います。
日々、ファイルが更新されていきます。何日も前のファイルを戻したくても収拾がつきません。

そこで、フォルダの日付を見て、15日以上古いフォルダは削除できるようにしました。
実際には、ファイルの存在するフォルダの削除は難しかったので、古い日付の分をリネームすることにしました。
こうしておけば、手動で削除するにしても簡単です。
また、古くても残しておきたいバックアップもあります。(説明省略)
これも組み込むことは簡単でした。


170216
sortnoteのエラー
sortnoteで内部エラー38が出ます。
実行ファイルでの問題です。エディタからの実行では出ません。
#include "hspda.as"は入れています。
エラーメッセージだけではsortnoteが原因なのかも分かりません。

試したり、調べたりして、原因はdllファイルです。実行ファイルにはhspda.dllが必要です。
#includeだけでいい場合と、そうでない場合があります。困ります。


170117
clipsetが役に立ちます
clipset "strings"(#include "hspext.as")を重宝しています。
stringをクリップボードに入れる命令です。メモ帳などで参照できます。

プログラムの動作を検証するとき、変数などのチェックをするassertがあります。
これの不便な点は、目的の変数を探すのが面倒なこと、大きな配列や莫大なテキストの場合、表示されないこともある点です。
簡単な方法は、代入した直後にdialogを使って変数などの値を表示させています。

ところが、これは、ここで扱っているHTMLファイルの内容など、大きなテキストは無理です。
HTMLファイルを生成しているので、このテキストが小さいものでも5KB、つまり半角で5000文字、大きなものになると、500KB 、500000文字、2000行ほどになります。
一応、プログラムでも、作業経過やテキストなどをmesboxなどに表示させるようにはしています。
でも、大量のテキストの中から、問題の箇所を探すのが大変なのです。

そこで、そのテキスト類をclipsetを使って、まとめてクリップボードに転送しておきます。
後は、テキストエディタを起動して貼り付ければ、どんな大きなテキストや配列でも確認できます。
プログラム中のdialogやmesboxなどと違って、エディタのメニューにある検索などを使って簡単に目的の場所に到達できます。

プログラムを実行して保存された結果を調べるといいわけですが、これには無理があります。
新たに生成されるファイルだけなら、これでもいいかもしれません。
ここでは、更新されるファイルがほとんどで、それも5ページから15ページほどになります。
これを試験でやるわけですので、取り消すとしても収拾がつきません。

実際には、プログラム中に巨大な変数を用意しておき、更新されたテキストを全部追加してあります。これをmesboxに表示して、実行途中で確認するようにしているのですが、前述のとおり、目的の所に到達するのが大変なのです。
この変数を、保存の代わりにクリップボードに転送して、メモ帳などで引用すると、とても簡単になります。
少し、要領が必要ですが、HPBに転送して調べることもできます。

また、これが実行ファイルに残らないようにするのも簡単です。
確か正式には#ifdefとかあると思いますが、私は普通にフラッグで処理しています。

clipsetに全部入らない場合があります。どうやらmesboxで制限されるみたいです。

画面コピー(PrintScreen)も多用しています。これと競合することに気づきました。
プログラムの終了時にclipsetで経過を残しています。後で経過を見直せるので、安心して終了出来ます。
さて、今回は、FTPのせいでしょう、AVGやFirewallが盛んに警告を出しています。
自分のプログラムです。問題ないと思いながらも、念のためメモを取ります。
長い英語の文字列です。そこで、手書きメモが面倒なので、画面コピーを使います。こちらもPrintScreenキー一発です。
残したからいいやと、そのままプログラムを終了します。
clipsetのせいで画面コピーが消えます。
対策は、画面コピーをその都度保存しておくことです。
170112
バックアップ方式の変更、その他
昨年8月に始めたこの作業、ようやく終わりました。
最初は、単純な改造のつもりでした。プログラムの数が多かった事と、途中で細かい変更をいくつも考えた事もあり、今までかかってしまいました。

その作業とは、
自動化プログラムを使ってページの更新をする時、同時に、その更新されるページのバックアップを作っています。
これまでのバックアップのやり方は、共通のフォルダを置き、そこに作業の都度、作成日付を付けたファイル名に変更して保存していました。同じ日付の場合は連番を付けました。

これを、今回、バックアップごとに、その作業日の日付と時間を付けたサブフォルダを作り、そこに名前を変えずにコピーする方式に変えました。同じ名前のファイルがあるときは、更にサブフォルダを作り、保存し、ファイル名に日付や連番を付けなくてもいいようにしました。
さらに、この作業のログも作るようにしました。
こうしておけば復旧の時が簡単だろうということです。

この一連の作業の中で、最初は、ファイル生成のルーチンごとにバックアップのルーチンを追加していたものを、できるだけルーチンをまとめて置くようにしました。
これは、今回、各プログラムでかなりバラバラだった変数名やサブルーチン名を統一しようとした関係もあります。

本来は、一つのプログラムで全作業に対応できるといいのでしょう。
現時点では、例えば、観察メモを作る作業と写真集のページを作る作業では、それぞれ別のプログラムを起動します。
今回の作業は、全作業を網羅したプログラムにするための準備ともいえます。
もっとも、現在は窮余の策で、ランチャーを作ってはあります。

これとは別の問題ですが、あと少し、作業が残っています。
観察メモのプログラムに、写真だけ作ってあり、まだ観察メモにを作っていないフォルダを表示するように考えています。
写真は作っても、すぐに発表しない方がいいようなものがあります。また、写真は準備したものの、ホームページにアップするか迷うような場合があります。
こういったものは、しばらく経つと忘れてしまうものです。
そういう時に、最低、フォルダだけ作っておけば、プログラムでチェックしてくれるようになります。

また、今回のバックアップを使っての復旧のプログラムがまだです。
こちらは、さほど急ぐ必要はありません。万一の場合、手作業で戻しても、そう問題は出ないはずです。
フォルダごとのファイルなので、戻すのも簡単なように思います。


161231
年次更新
年次更新作業をやりました。
今回は昨年のメモがしっかりしていたので楽でした。
詳しくは、パソコンメモと年次更新作業メモを。

161003
その他のページ、RSS

RSSファイルを更新するプログラムにバグを見つけました。
久しぶりに動かしてみたら、タイトルが違うと出て止まります。
一年ほど前、観察メモのタイトル文を変更した時、このコードも変える必要がありました。
修正しました。
プログラムを動かす手順も忘れていました。
観察メモを自動化で生成し、その後、ページに手書きで文言を入れた場合にRSSを対応させるものでした。
つまり、観察メモのページを修正した後、このプログラムを動かします。

161002
50音順目次

観察野鳥50音順目次に配置間違いを見つけました。
プログラムの誤動作かと心配しましたが、どうやら、自動化以前の手書きによる配置の作業ミスのようです。
160811
バックアップ方式変更、レストアの自動化
161215再編集
更新したページを、バックアップ使って実際に復旧した事は、過去1回あったかどうかです。
まあ、今後もめったな事は無いと思いますけど、この復旧の作業も自動化しておこうと思います。
作り始めてみて、紛れが多すぎます。現在のバックアップの体制が悪いのだと思い至りました。

そこで、バックアップの方式を変更することにしました。
従来は、専用のフォルダを一つ作ってあり、そこに日付や通番を入れた名前に変更して保存していました。ログなどは無しです。

今回思い立った事は、
更新作業や新規の追加作業などするたびに、サブフォルダを作って、その中に更新前のページを保存しておきます。
更に、この作業を記録したログファイルも作っておきます。
復旧の時、便利だろうと思って、ログの中は、ファイル名などフルパスで書いておきます。
新規に追加したファイルや写真などは、復旧の時は削除しないといけません。そのような新規の写真などもメモしておきます。(これはこれでバックアップの必要があります。)
復旧では更新した時間が大切です。最新のものから復旧しないといけませんので。
これは、サブフォルダ名を日付時間で作り、ログファイルにも日付を記録しておきます。

最初は、旧来のバックアップと新方式を併用して進めました。バックアップが2個できる状態でした。
ある程度様子を見た上で、現在、新方式に一本化しています。

プログラムがページの種類・作業に応じて複数あります。
使用頻度の少ないものの積み残しもありますが、まあ大体終わりました。

今後の課題は、コードの整理です。
長年、追加や変更を繰り返してきたコードに重複があるようです。
これを何とかしたいと考えています。

160703
バナーの変更、GIFファイルの配置

最上段にある各ページへのリンクに使っているバナーを、一個、作り替えました。
作業にはHPBのツールを使いますし、文字だけを変えたGIFファイルを作り、必要なフォルダに置くだけです。
ただ、配置しなければいけないフォルダが複数ありました。
ページで使うのは、どこでも同じファイルです。どこかに一つ置いて、そこを参照するようにすると効率的です。

しかしながら、実際には同じ物を重複配置してあります。
これは、プログラム化の弊害、と言いますか、プログラムの手抜きでしょう。
年次ごとに新しく追加するフォルダ全部に配置してあります。
まあ、ほんの少しだけ、プログラムか関連のファイルを修正するといいと思います。
年次の更新の時、新しくフォルダを作る場合、プログラムを対応させるのが面倒だったので、同じ環境にすると修正も楽だろうとして、関連のファイルを一括してコピーしてしまった事による弊害でしょう。
年を重ねて、現在では6か所程度に同じGIFを配置してしまっています。
ここまでくると、今回のように対象のGIFファイルを作り変える時、とても面倒になります。
覚えているなら来年の年次更新の時、対応しようと思います。

160705
さて、年末まで覚えている保証がありませんので、すぐに試してみました。
ページやプログラムを検証してみたら、単にテンプレートのファイルを変更するだけでいいようです。
テンプレートファイルでは、なぜかカレントのフォルダにGIFファイルなどを置いてある前提になっています。
これを共通のGIFファイルの置き場にしてあるフォルダを参照するように書き換えるだけです。
実行してみました。
プログラムも問題なく動き、新しいページが生成されます。

しかしながら、いろいろ試していくうちに、問題点に気づきました。
想定通りにファイルは生成されます。ただ、その生成されたページに手書きで変更を加えたりして、別名で保存するとき、それが発生します。
HPBがページ内で使用しているGIFファイルをカレントにコピーして持ってくるか、いちいち聞いてくるのです。もちろん、必要ないので、そのままでいいという選択もできます。
しかし、GIFファイルが10個ほどあります。10回聞いてきます。とても面倒です。
そこで思い出しました。これがあって、新しいサブフォルダを作るとき、一括してGIFファイルをコピーして置いておくことにしたのです。

HPBはGIFが直下のフォルダにあるときはこの警告を発動しません。一度、上のフォルダに戻って参照するとき、発動します。
また、上書きでは発動しません。別名保存の場合だけです。
実際には別名保存が必要なケースはほとんどありませんが、生成されたページに解説などを書き込むケースが全然ないわけではありません。
それに、プログラムを使わないで、手書きで作り上げるケースも皆無ではありません。

このようなケースがあるので、現在の形にしておいたのだと、おぼろげに思い出しました。
つまり、現状のままが無難なようです。何か対策があるか、ゆっくり考えてみます。

160531
サムネイル写真の変更

サイトのサムネイル写真を一括変更しました。150x113ピクセルの写真を160x120に変えました。
ファイル類の変更作業の具体的な内容はパソコンメモに書いています。
この変更に関して、半自動化プログラムの修正が必要になります。
一応、サイトのファイルと同様、プログラムコードもコピーして作業開始です。万一、うまくいかない場合は、元のファイル、元のプログラムでやり直せば、今日現在の状態には戻せます。

プログラムの修正作業の項目は、多分二つ、
1、ファイル名などで絶対アドレスを使っている場合の変更。
2、写真のサイズの書式、width="150" height="113"、(の一部)を使っている箇所の変更、
です。

観察メモのプログラム
観察メモを作る際の写真が写真集に何枚登録されているか表示させているルーチンがありました。これが動きません。
写真集のページのサムネイルのサイズ指定の行を数えていました。変更しました。
ローカルのサイトの配置は変わりませんが、プログラムの置き場所を変えました。
ローマ字からカタカナの名前に変換するためなど、プログラムの置いてあるフォルダにあるテキストファイルを参照しています。
こちらはカレントディレクトリ(dir_cur)を使っているので、修正の必要はありませんでした。
また、サイトのローカルフォルダは変更していませんので、そのまま使えました。

写真集のページ追加
要は、width="150"云々とあるのを、width="160"云々と書き直せばいいのですが、書式の都合で、"width=\"150"とか、width=\"150\"とか書いています。
検索するとき、このあたりを考えて探さないといけません。単に150で検索すると関係ない数字が含まれてしまいます。
スマホ版のルーチンとか複数の修正箇所があります。
絶対アドレスは使用していませんでした。

写真集新規追加
shtm09フォルダだけが対象、そこにテンプレートが置いてあり、一括変換の時、変換済みです。
新規の場合、テストができないので、ダミーのファイルを作ってあります。付属のテキストファイルも整合させました。

以下、同じです。
全て、150を160へ、113を120へ置き換えることで終わりました。
ファイル名の絶対アドレスはプログラムのランチャー部に使っていただけでした。
160926この際、写真のサイズをチェックするルーチンを追加した。
最近では見ないが、同じ写真をサムネイルに使っているケースがあったり。

160520
観察メモファイル名

プログラムを利用しての作業のほとんどは、観察メモのページを作ることです。
観察メモのページとは、観察野鳥一覧表に目次が作ってある、その日に観察した、正確には写真の撮れた、野鳥を掲載しているページです。
一定の規格で、日付ごとにフォルダを作って、その日の写真を入れておきます。
この状態でプログラムを起動し、観察メモのページと関連するページのリンクなどを生成します。

ここまで、プログラム化して5年ほど経過しています。この観察メモのページ生成に関して、初めてのケースが発生しました。
それは、作り上げたHTMLファイルのファイル名が重複する場合があることです。

観察メモのファイル名は日付と鳥名の一部を使って生成しています。
例えば、2016年4月25日のゴジュウカラ(160425_gozyuukara)の場合は、ファイル名は160525or.htmとしています。
7、8文字目のローマ字の部分は、鳥名の2文字目と後ろから2文字名を取り出しています。
これで、この時まで、ファイル名が重複することはありませんでした。まあ、同じ日に複数のページを作ることがめったにありませんので。
今回、同じ日に、コルリのページを作りました。(160426_koruri)
上のやり方だと、ファイル名が見事に重複することになります。繰り返しますが、このケースはここまでの5年間、一回もありませんでした。
さあ、大変です。今更手書きでは作る気になりません。
そこで、ようやく、プログラムを対応させました。このような場合、ファイル名には9文字目に数字を追加することにしました。160525or2.htm

今回、これが面倒だったのは、実際には新しい写真がない時にもプログラムを動かすことがあることです。動作試験の時や、うっかり新しい写真を作り忘れていた時などです。
この場合は、当然同じファイル名になるので、上書きしたり、項目を追加したりすると大変です。
ですので、これまでは同じ名前のファイルが存在したら書き込み出来ない様にしてありました。ワンパターンで解決できていたのです。

つまり、今回の課題は、ファイルを新たに作ってはいけない場合と、偶然同じファイル名になる場合との区別をつけることでした。
今度は、同じファイル名になった時、上のように単純に枝番を付けて処理すると、必要のないページが作られてしまう可能性が出てきます。
対策として、簡単なのは、ダイアログなどで聞いて選択させる方法です。
同じファイル名が存在しますが、ファイル名に枝番を付けて別に作っていいですか。みたいな感じです。

でもそれでは、面白くありません。折角なのでプログラムで判断させるべきです。
前提は、一つのページを作るときは、日付と鳥名を組み合わせたフォルダを個々に作っておいて、その中にページで使う写真を入れていることです。

そこで、以下のようにしました。
新しく作ろうとしたページと同じファイル名が既にある場合、
今回作ろうとしている日付と同じ日付のフォルダ数と観察メモファイルの数を数える。
観察メモファイルがフォルダ数より一つ少ないはず、これ以外は、準備の手違いか動作試験なので、終了するかファイルを生成しない。
ファイル数がフォルダ数より一つ少ない場合のみ、ファイル名に枝番を付けて新しく作る。
この際、念のため、既存の同じ日付のメモファイルの内容を読み込み、今回登録する写真が使われていないかどうか調べる。
今回の写真が使われているなら、フォルダの指定間違いなので、やり直させる。
ここまで。

現実には、今回、もう一つ同じ日にページを作りました。コマドリ、160425_komadoriです。
従来通りですと、見事にこれも同じファイル名になります。
ファイル数に応じた枝番を付けることで解決です。

蛇足ながら、当初、ファイル名を作るとき、省略せず、日付+鳥名全部、とすればよかったのです。
そこはそれ、DOS時代、ファイル名が8文字だった名残なのです。当時でも、既にこの制限は無かったはずですけど。
それに、鳥名から2文字を取り出す場合でも、前から2文字目と後ろから2文字目というのは、適切な方法では無かったと思います。
ローマ字ですので、前から2文字目は母音になるケースが多いはずです。母音は5文字しかありませんのでかなりの確率でその2文字目は同じになります。
それに、後ろから2文字目ですが、大体鳥の名は後ろが、トリ、シギ、サギなど同じ言葉が多くあります。
つまり、この2文字だけだと、同じ文字になる確率は少なくはないという事です。
まあ、さして必要でもない今後の課題としておきます。


150116
バグあり

どうも、写真入れ替えのRSSファイルの更新ルーチンにバグがあるようです。
直近の記事のdescriptionの日付が11年になっていました。
今回のRSSファイルは、手書きで修正しました。
考えてみると、RSSファイルに関しては、単独でdescriptionの内容を書き換えるプログラムが組んであります。
これを使うと、その都度、修正はできます。
150121プログラム修正済。

150113
エラー処理

今日、ルリビタキの写真を一枚、入れ替えました。
もちろん、このページでメモしているプログラムを使いました。
しかしながら、ダイアログが出てエラーで終了します。
プログラムのエラーではなく、どうやらファイルの整合性に問題があるようです。
調べてみたら、既存のルリビタキの写真のページでミスが見つかりました。
サムネイルを重複して使用していました。
具体的には、5枚のルリビタキのページがあるのですが、その1枚目と3枚目のページのサムネイルが同じものを使っていました。
今や、どのような経過で作ったか覚えていませんけど、とにかく、整合していない場合の処理を入れてあったわけです。
手前味噌ながら、人力ではなかなか発見できないミスだったと思います。

150107
HSPのラベルジャンプ

この自動化作業とは直接関係は無いのですが、HSPの不具合かなと思える現象です。
ダイアログに表示する文字列が複数に渡る時、コードの表記に不便を感じていました。
文字列の複数行の表記方法を知らなかったのです。
やむを得ず、変数に1行ずつ追加していったりしていました。こうするとイメージが近いものにできますので。
しかしながら、最近ようやく中かっこ{ }を使うと簡単に複数行の文字列が出来ることに気づきました。
そこで、早速使って見ました。便利は便利です。この方法だとコードではタブやスペースを付けていても、実際の表示では無視してくれます。
ところが、今度はその弊害が出ているようです。
編集メニューにあるラベルへのジャンプがうまくいかないのです。あくまでコードの編集中だけの問題です。
ラベルへジャンプするように指定しても何行かずれて移動してしまいます。
いろいろ試してみたら、ジャンプの際には、その複数行の表記がまとめて1行に計算されているようなのです。
複数行の文字列以降の行が、その行数分ずれてしまっています。
やむなく、そのコードを末尾に移動させてしのいでいます。

150105
年度更新作業

年が改まると、このサイトのページのうち、いくつかを更新する必要があります。
年度ごとのページがある事と、HSPを使ってページの制作を半自動化していることの絡みです。
(以下、実際のファイル名などは2016年の1月での作業例です。1年後にここにメモしていることを思い出せればいいが・・・。

ページの更新
制作メモ(memo.htm)、観察野鳥一覧表(mlindex.htm)、パソコンメモ(pcmemo.htm)の各ページをコピーし、コピーした方を年度を入れてリネームし、そのまま前年度のページとして使うことになります。
例えば、memo2015.htm、mlindex2015.htm、pcmemo15.htmのようにします。
コピー元のファイルは新年度で使います。
当然、前年度の記事が残っていますので、その部分は削除することになります。
この時、古い記事を完全に削除しないで、数件分残しておきます。
自動化のプログラムで0件の処理がしてないものがあります関係です。
新しい年度の記事が一つでも追加されたら、古い年度の記事は削ってしまいます。
新しい年度で使う分も古い年度の分もそれぞれ多少の修正がが必要です。
たいていはリンクがらみですが、新年度に持ち越したページはページタイトルの変更も必要です。(それまでは2015年分として使っているので、2016年分と書き換えます。)

フォルダの追加
観察メモ用に新しい年度のフォルダを追加することが必要です。
例えばtemp16などです。
で、そのフォルダに関係ファイルをコピーしておきます。
gif、テンプレート、jsなどのファイルです。(HTMLファイル以外は全部)

プログラムコードの書き換え
初期設定で、dirstt="temp15"で年度を指定しています。新しい年度に変更します。
*dirsetに古いファイルへの対応があります。
新しく作られた直前の年度のファイルへの処理を追加します。

140908
RSSファイル、GoogleChrome

RSSファイルの動作がおかしいことに気づきました。
その以前の問題として、今、主として使っているGoogleChromeにはRSSのボタンが出てきません。
機能を追加することは出来るそうですが面倒なのでやっていません。
で、RSSの動作を調べる時はIEを使います。
Chromeには、もう一つ問題があり、キャッシュが強力に効いています。日々の更新が、なかなか反映されないのです。
これも強引に更新する方法がありますけど、面倒です。
さて、RSSの不具合とは、戻るボタンが効かないことです。
RSSのページを見て、そこの一覧されている中のページに飛びます。
そのページからRSSのページに帰ろうとして、戻るボタンをクリックしても帰ってこれないのです。
戻ろうとすると、ファイルをダウンロードするかどうか聞いて来ます。PDFファイルなどを開こうとした時などと同じような状態です。
調べてみたら、どうも拡張子の関係らしいです。
RSS1.0の場合は、拡張子にrdfを使うと、このような動作になるそうです。
そこで、拡張子をxmlに変えてみました。
動かしてみると正常に動きます。
ただ、RSSファイルもプログラムで生成するようにしています。この修正が大変でした。
結果、対応できたと思います。完全に検証は出来ていませんけど。
疑問なのは、いつからこの状態なのか、です。
最初からのことで、気づかなかっただけなのか、途中から発生したことなのか、わかりません。
バックアップしてあるファイルや、ごみ箱のファイルを戻したりして、数か月前のファイルで試してみましたが、同じ状態でした。

140608
スマホ対応版とRSSファイルの生成

最近、スマホ対応版のページも作るようにしました。うまく行っているかどうか、心配な面もありますが。
そのため、一つの写真のページを追加や修正するとき、関連するページが飛躍的に増えています。目次ファイルに係わるものだと、都合20ページの修正が必要になります。
もはや、ここで解説しているHSPによるページの半自動化プログラムが無いと、サイトの維持が困難かもしれません。
このスマホ対応版の生成に関しては、おおまかには出来ていました。しかしながら、色々なケースに対応させることは見切り発車してありました。
プログラムで生成できない部分は手書きで対応でした。
もう一つの懸案があり、これまではRSSファイルが手抜きでした。このサイトのRSSを見ていただくと分かりますが、記事としては日付だけが入っています。
元々が写真だけのページで、大半、解説や記事はありません。当初、RSSには日付でも出しておくかという考えでした。
でも、たまには文章を入れる場合もあります。(このページなどがそうです。)
この間、この二つの問題に対応していて、どうやら満足出来るものに仕上がりました。

現在、手書きでの作業は、写真を既定の大きさに作って、既定のフォルダに入れることと、
めったにありませんが、新規の鳥種の場合、分類順の目次の中で写真の配置を決めること、だけです。
(もう一つ、このようなページの文章を作るときも、もちろん手書きです。)

先の関連するページが20あるというのも、今回の成果です。動かしてみると簡単に把握できます。
これからは、ようやく写真の制作に専念できるはずです。


140520
スマートフォン対応の各目次生成

写真集については、スマートフォン用のページを作り始めています。
これに合わせて、やはりスマートフォン用の目次を作らないといけません。
あまり、知識を持ち合わせてはいない中で始めてしまった作業です。
基本的には、スマホでも写真が判別できるようにしたい事と、指で操作して目的の写真まで表示できるようにする事を一応の目標にしています。
少しずつ自動化の作業を追加していき、何とか全部の作業をカバーしました。
写真集の写真のページは問題ありません。追加の場合や新規の場合など、その要件に合わせて生成できています。
ただ、目次のページが面倒でした。特に新規の場合の分類順の目次です。
今のところ、完璧には生成できません。元々、分類順に関しては、PC版の方も自動化できず、手書きで追加編集しないといけません。
これは、新しい鳥種の場合、目次のどこに挿入するか、その位置を簡単に決定できないのです。
やり方とすると、最初に全鳥種の分類表を作っておき、そこから参照するような方法でしょうか。いずれにしろ、その分類方法を理解していないといけません。これはとても面倒なので、ここは印刷された分類表を眺めながら、手入力で作る事にしています。
同じことが、スマホの目次ににも当てはまります。
そこでやったことは、まず、PC版の方を手入力で完成させ、その後、プログラムを起動して、PC版を参照してスマホ版を作るようにしました。
細かいところで修正は必要ですが、今のところ、ほぼ思い通りに動いています。

140612追記
分類順目次に入れない写真があります。鳥以外、リスなどを新規に追加する場合です。
でも、五十音順の目次には入れます。スマホ版の五十音順にも入れなければなりません。
この目次だけを更新するプログラムでは、現在、分類順でチェックをしていますので、使えません。
修正が必要です。
これに関して気付きました。写真の入れ替えの時にも問題になります。
動物などは、分類順に写真がないので、どこかで問題が起こりそうです。
新規の分だけとりあえず修正しました。選択して五十音目次だけに登録出来るようになりました。
これをもう少しスマートになるよう修正はするつもりですが、その他については、このままにしておこうと思います。
多分、動物などの分類順に登録してない写真の入替だけの問題です。この場合は手書きでやろうと思います。
多少はサイトの構造を記憶、理解しておく必要もありますので。

140403
スマートフォン対応の写真集のページを生成

スマートフォンでの操作が簡単にできるように、対応したページを作りました。
当初、最終的な写真のページはPC版と共通にしていました。
これをHSPとTExchangeを使って、作り直してみました。

140115
ファイルのバアクアップ、カタカナ名のフォルダ、観察メモのページ生成

この項、大半はページ作りには関係ありませんが、作業をHSPでやりましたので、ここに書き込みます。

以前から撮りためている写真ファイルが膨大なものになっています。
写真を本格的に撮り始めたのが2005年ですので、数と容量は大変なものです。この際、質は問題にしませんが。
今、ディスクの管理で調べたら、HDDの総容量が3TBでした。ほかにバックアップ用に同じくらいの外付けのHDDがあります。
これまでは、日付順にフォルダに入れたものと、鳥名ごとに保存してあるものとの2種類で保存してあります。
この鳥名ごとに保存してあるものは、4GBずつ区切ってフォルダを作っています。
つまり、鳥名ごとに貯めていって、4GBになったら新しいフォルダを作ってそちらに保存していきます。
これは、当初、DVDにバックアップがしやすいように始めたものです。
この4GBのフォルダが現在50個を超えました。つまり、数えていませんがDVDも50枚以上あるはずです。
当初は、この方式でも不便はありませんでした。
でも、現在、これが大変なのです。つまり、どれかの鳥の写真が必要なとき、50数個のフォルダを延々と探す事になります。
これではいけないと、一念発起、鳥種ごとにまとめたフォルダを作ることにしました。
この際、懸案だったことがもう一つ、カタカナのフォルダ名です。
以前、カタカナを含め日本語、2バイト文字、のファイル名、フォルダ名に関しては、色々と問題がありました。
で、フォルダ名はこれまで全部ローマ字です。現在では、このような問題を聞かなくなりました。
まあ、じぶんのパソコンで、しかもデータ保存用に使う限りにおいては、全く問題はないでしょう。
で、この際、フォルダ名をカタカナにして保存しようと思い立ちました。

試行錯誤の結果ですが、
まず、ローマ字の鳥名と全角カタカナの対応表を作りました。
これも、手書きで作ったのではなく、あらかじめ一文字一文字の対応表(ka、カ、とか)を作っておいて、
HDDにある限りのローマ字の鳥名フォルダを読み込み、カタカナに変換しました。
完璧にはできませんでしたが、何か所かを手書きで修正して完成させました。
この作業は一応、Excelあたりに関数かなにかないものかと調べましたけど、わかりませんでした。
さて、この対応表から、まず、実際にカタカナ鳥名のフォルダを作りました。
その後、簡単に言えば、ある程度日付順に並んでいる日付の付いたフォルダを鳥種ごとにカタカナフォルダにコピーしていきました。
実際には、すべてが同じ形式ではなかったので、結構面倒な作業でした。
現在では、同じプログラムを使って、バアクアップ用に使っています。
つまり、日付ごとに並んだフォルダと、カタカナ鳥名ごとに並んだフォルダの双方にファイルがあることになります。

この後の問題点は、
fxcopyが長いファイル名のコピーでエラーを出すこと。
ミラーリングが出来ていないことの、2点です。
fxcopyは、面白いのは、といいますか、不思議なのは、コピーは出来ていて、長いファイル名をコピーし終わった直後に
エラーで止まることです。
ですので、プログラムを再起動すると先へ進んでいきます。
コピーは出来ている、既にあるファイルはスキップする、ので、エラーを起こしたファイルは次回はfxcopyの対象になりません。
ただ、長いファイルはたいてい複数ありますので、そのファイルの数だけエラーを起こして止まります。
何度か実行するうち、完成してしまいます。
この件、ファイル名を長短いろいろ変えて、どこが限度か調べましたが、はっきりとは分かりません。
フォルダを入れても違いますし、同じ長さでも、エラーが出る場合とそうでない場合があります。
何か、動的なものに影響されているようです。

この、エラーを起こす長いファイル名の代表例がカンムリカイツブリkanmurikaituburiです。
実際には日付と拡張子が付きますので、kanmurikaituburi999999-2.jpg程度のファイル名です。
確実ではありませんが、このままではエラーを起こし、試しに日付だけのファイル名に短縮すると無事コピーされます。
この際のファオルダは5〜60文字、フォルダの階層は5ぐらいです。
つまり、(実際の構文では変数に入れています)
fxcopy kanmurikaituburi999999-2.jpg,F:/aaaaa/bbbbbbbbbb/ccc/dddddddddddddddd/eeeeeeeeeeeeee,0
でエラー
fxcopy 999999-2.jpg,F:/aaaaa/bbbbbbbbbb/ccc/dddddddddddddddd/eeeeeeeeeeeeee,0
だと通過、です。

ローマ字からカタカナへの変換表は、ローマ字と対応するカタカナの鳥名が並んでいるだけのテキストファイルです。
これを作ったことが、後日、役に立ちました。
個々の観察メモのページの作成は完全には自動化してありませんでした。
これまでは、この観察メモのページは、手書きで(HPBで)作っていました。
ただ、観察メモのページに関係するいくつかのページ、たとえば、一覧表のページなどは自動化していました。
今回、このおおもとのページも自動化しようと思い立ち、この時、この変換表が役立ちました。
簡単に書くと、ウェブサイトのフォルダや写真ファイルはアルファベット(つまりローマ字)です。
当然、ローカルのHDDでもローマ字にしています。
ここで、あらかじめ決めている形式のフォルダに、決めている形式の名前の写真を入れておけば、
変換表を使って自動的にカタカナの表記のページを作ることが出来ます。
最近では、ページに解説や鳥の説明を入れることも少なくなりました。手抜きですが。
この解説などは今でも自動化できていません。
でも、必要ならページが完成した後で、そのページに書き込んでいけばいいことです。
この作業は、自動化しても労力は同じです。ページの作成途中で手書きで入力するか、作成前に作っておくか、
ページだけ作っておいて、後で書き込むかの違いです。
今日、140130のページから、このプログラムで、実際に使っています。
今のところ、動いているようです。

131127
HSPの文字列の制限

現在試行錯誤中、
HSPで大量の文字列を扱っていると、途中で不自然な動きになります。
文字列の途中が消えてしまいます。
調べてみると、文字列の大きさに32768バイトという制限があるようです。
ネットで調べると、最近のバージョンではこの制限はなくなっていると書いてあります。
けど、現実には32768バイト以上のテキストが作れません。
実は、少し前、この問題に付きあたって、その時は解決した記憶があります。
その時、メモを残していない様なので、もう一度悩まないといけないようです。

新しいHSP()Ver3か?では、文字列に制限はない。
mesboxでは32767までしか表示できない、事がある。必ずではない。Windowsの仕様かもしれない。
mesboxのパラメーター変数を直接いじると、制限にかかることがある。

131010
サムネイル写真付の分類順目次

写真集の目次に五十音順と分類順のページを作っています。
さらに50音順の目次には、サムネイル写真付きのページも作ってあります。
分類順の方はテキスト版だけです。
そこで、分類順の目次にもサムネイル写真付きのページを作ってみました。
今までのテキスト版の分類順目次はそのまま残し、並行してサムネイル付の分類順目次のページを作ります。
鳥の名前を調べる時、分類順のページから探すのが便利です。そこに、サムネイルがあると好都合です。

さて、その段取りです。
元々のテキスト版のページの各行に一行追加して、そこにサムネイルとリンクを追加する事にしました。
300行弱の作業です。当初手作業で何とかなるだろうと始めましたが、これがなかなか面倒でした。
やむを得ず、HSPでプログラムを組むことにしました。
元々テキストのリンクがあります。これで、どの写真のページを使っているか分かります。
で、そのページを読み込み、サムネイル写真がどこにあるか調べます。
その写真を引用します。その写真に付けるリンクは、テキストのリンクと同じなので、基本的にはコピーするだけです。
これを項目の数だけ繰り返せばいい訳です。
ただ、テキストのリンクの行に例外がいくつかありました。
場合分けが面倒なので、そこはスキップして、後で手作業で追加することにしました。

130527

観察野鳥鳥名順目次の生成に問題があることに気づきました。
カッコウとカツオドリの順番が正しくありません。
辞書順(調べたのはフィールドガイドの五十音順索引です。)で見ると、カツオドリが先でカッコウはその後になっています。
で、最初に既存のページを一覧表にした時、カツオドリ、カッコウの順に置いていました。
ところが、私の生成のプログラムでは逆に配置してしまいます。
原因は、制作過程のことを完全には思い出せませんが、確か、HSPの比較が完全な辞書順になっていなかったようだったので、
比較の基準の文字列を作って、それで一つ一つ比較するようにしたことです。
で、その基準が、なぜか半音が先で全音はその後に配置していたのです。
プログラムを修正するといいのでしょうが、今までの生成過程との整合性に問題が出そうな気もします。
よって、このまま進もうと思います。鳥名順目次の方は手書きで書き直しました。

130212

写真集の各写真のページの生成において、写真の右肩にある野鳥紀の文字が一文字分右にずれるページがあることに気づく。
調べてみると、文字が右置きに設定されており、下の段の撮影地が4文字ある場合、その列の文字がずれることが分かった。

120715

観察野鳥のページに五十音順の目次を作りました。
各ページのタイトルにある鳥種を分割して、五十音順に並べ直したものです。
写真集のページは元から目次が作ってあって、鳥種から簡単に写真を探せます。
ところが、観察野鳥のページは日付順に並んでいるだけですので、どの鳥の記録がどこにあるのか、まず分かりません。
そこで、一念発起、五十音順の目次を作りました。
プログラムを作ろうかとも思いましたが、ここは手書きでやりました。3日ほどかかりました。
ただ、今後の追加分については、プログラミングしました。
各日の観察野鳥のページさえ手作りで仕上げれば、あとは全部プログラムで作り上げます。
自動的に作成するのは、今回の目次ファイルを含めて6ファイルです。
言いかえると、一枚の観察野鳥のページを制作すると、6個のファイルにリンクを作る必要があります。

120524

ページの(サイトの)タイトルから熊本を抜き、ただの「野鳥紀」にしました。
具体的には、TITLE文、Description文、Keywords文などを修正してあります。
このため、自動化プログラムを修正する必要が出てきました。
一括して修正するのは面倒なので、プログラムを使うついでに修正して行こうと思っています。

写真集の追加、
写真集の入れ替え、
 TITLE文などをプログラムに合わせることで対応しました。

観察記録のページ追加、
 TITLE文を参照し、鳥名を抜き取っていました。
 文字数を修正するだけで動くようです。

以下、熊本野鳥紀時代の記録

111118

今日は、たまっていた写真の一部をアップしました。
作った写真は11枚、ページは写真集が3ページ、観察野鳥が2ページでした。
写真の編集ソフトで編集するのに30分、この自動化のプログラムを使ってページを作るのに
やはり30分ぐらいの、合計1時間で仕上がりました。
プログラムの30分は、正しく動いているかを手動でチェックするのに要する時間です。
ページの作成そのものには5分もかかりません。

書き換えたページは全て、バックアップを作るようにしています。
そのバックアップを数えると、30ファイルありました。つまり30項目を追加や修正したことになります。
これだけの作業を1時間ほどで仕上げられるというのは、かなりの成果だと思います。

出来あがってから、まずリンクがちゃんと作られているか、HPBを使って調べます。
HPBのサイトメニューでリンクを調べる事が出来ます。これは以前から重宝しています。
サイト内部のリンクはこれで完璧に調べられます。
その次に、構文にエラーがないかを、やはりHPBを使ってチェックします。
読み込めば、エラーがあればダイアログが出ますのですぐわかります。
ここまで神経質にチェックをするのなら、最初からHPBを使って書き直しても構わないような
気もします。まあ、何も考えずに作業が出来るのが利点ですし、落ち着いたらチェックも必要ないでしょう。

さらに、新規を含め3枚の写真をアップしました。
新規に追加するケースの実働も試せました。
書き換えファイルの表示に間違いがあるようです。書き換えているのにリストに出てこないケースです。
実行には不都合はありませんでした。
唯一の懸案は、分類順の目次を作れない事です。これだけは当分、手書きで追加することになります。

110918

制作メモなどに使っている「入れ換え」は、どうも「入れ替え」のようで、全て変更しました。
今年の7月21日に、逆のような気がして、一度変更したものです。

辞書など見ると、どちらも通用する様なのですが、再度、変更した根拠は、
まずGoogleで「入れ換え」で検索すると、強制的に「入れ替え」に変換されてしまいます。
もうひとつ、Excelのヘルプは「入れ替え」で表記されています。
というわけです。

該当するページは3ページで、全部置換しました。
幸い、というか、古い制作メモは「入れ替え」で残してありました。

肝心のプログラムの修正も終わりました。

110918
制作メモを作らない作業、など

新しい写真が出来て、これを一枚めに持っていきたい、
ただ、一枚目の写真は残して、例えば2枚目の写真を削除したい。
このような時、1枚目と2枚目を並び換え、その後、1枚目に新しい写真を入れ替えるといいわけです。
ただ、このまま作業を実行すると、制作メモに二つの作業が記録されてしまいます。
しかも、入れ替えにも、並び換えの方にもリンクを付けています。
結果的に、リンクが違ってしまいます。
これを避けるため、並び替えの時、メモを付けるかどうか選択できるようにしました。

入れ替えの作業ではファイル名には変更がありません。
そこで、マップファイルは作らないようにしていました。
実際には、ファイルスタンプが変わっていますので、マップファイルに登録してあるファイルは
日付を更新するべきでしょう。
現在、トップページの日付のみ更新するようにしました。

ここまでの作業変更に伴い、説明ファイルを書き換えました。

観察一覧表の作成時に、鳥名を編集できるようにしました。
制作メモなどの記事をタイトルから引用していましたが、不自然なケースがありましたので。

110912
トップページに制作メモの抜粋を挿入

トップページを少し改修して、制作メモのうち、直近のものをコラム化して入れることにしました。
これで、トップページを見れば、大まかな作業状況がわかります。
それに、最終更新日を表示するようにしていますが、これが。トップページのファイルスタンプを見ているだけなので、
実際には、ほぼ毎日写真が更新されているのに、その状況を反映していませんでした。
これが、今後は、写真を入れ替えるたびに更新日表示も変わることになります。

一応、作業は、ほぼ終わっています。
メモの挿入場所を探して、末尾のメモを削除、先頭に新しいメモを挿入、します。
写真の作業種別ごとにプログラムを分割していましたので、それぞれを修正追加する必要がありました。
インラインフレームでも使えばスマートなのかもしれません。
ここはあえてフレームは使わず、制作メモと同じ内容を、プログラムで書き込んでいくことにしました。

110905
ここまでのまとめ

ここまで、一応の作業は自動化できています。
まず、作業別にコードを分けています。

写真集の写真に関して、
 新しい写真を単純に追加するとき、
 新しい写真を、既にある写真と入れ替えるとき、
 新しい写真は無しで、同じ鳥種の写真の並びを換えるとき、
 まったく新しい鳥種の写真を入れるとき、
  これらの場合は、新しい写真のページを作り、もともとある同じ鳥種のページにリンクを追加します。
  制作メモのページにもリンクを追加します。
  必要なら、目次のページのサムネイル写真を入れ替えます。
観察野鳥一覧表のページを作ったとき、
  一覧表にリンクを追加します。
いずれの場合も、必要なら、マップファイルとRSSファイルを作り変えます。

さて、今後の課題は、
 これらのコードのランチャーを作ろうとしたのですが、二重起動の制御が出来ません。
 マップファイルとRSSファイルが必要のないときでも作られてしまうケースがあります。
  必要に応じて、作業をスキップできるようにしたい。
 制作メモ、観察野鳥一覧表の書込み内容について、タイトル文から引用しています。
  これが場合によっては不自然な内容になってしまいますので、内容を別に指定できるようにしたい。

110816

写真の並び換え作業について、古い写真で動作試験をしてみました。
ほぼ予定している通りに動いてくれます。
これまでに、ノゴマの写真が2枚UPしてあり、見直すと、もう少し写りのいい写真があります。
さらに、今の画像処理ソフトを通すと、見ばえがかなり違います。
これで、まだ実働させていない並び換えの動作を試してみました。
新しく処理した写真を3枚目に追加し、続いて1枚目と3枚目を並び換えです。
予定通りの動作をしてくれています。

多少、問題も残りました。
制作メモに、二つの動作が記録されます。今回はメモを手動で書き直しました。
このくらいはやむを得ないかと思います。

もうひとつ、RSSファイルに、結果的に古い方の写真が登録されます。
3枚目に新しい写真を追加したときは、RSSに反映、記録されます。
単に並び換えの時は、写真が新しくなりませんので、RSSは書き換えない事にしています。
結果、RSSのリンク先が、古い写真に置き変わった3枚目になってしまいます。
これも手書きで修正しました。今はRSSの構造も理解していますのでなんとかなりますが、
今後は対策も必要でしょう。

110812

写真の並び換え作業についても自動化できる見込みです。
同じ鳥種の写真の表示の順番を換えるものです。
これ、出来上がればすぐにでも使えると思っていました。
並び換えたい写真がかなりあるものと思っていて、ざっと調べてみましたが、どうしても、と思える所は
そうそう見当たりません。今後、もっと丁寧に調べなおすつもりです。

手順は結構面倒でした。写真の入れ替え作業のルーチンを使えると思っていましたが、ほとんど作り直しでした。
メインの写真を入れなおすことを回避するために、ファイル名を入れ替えることにしました。
この作業は、撮影地なども換える必要が出てきますので、面倒なのです。
該当する(入れ替える)2つのファイルは、タイトルとサムネイルを入れ替え、ファイル名も入れ替える。
他のファイルは、サムネイルだけを入れ替える。
これでいいはずですが、まだ実地に試していません。

今後の課題は、二つあります。
ランチャーを作りたいのです。個々の作業が独立したプログラムです。
ランチャーから起動できるようになれば、対応が楽です。
ところが、HSPにはexecはあるのですが、二重起動を防止する方法がありません。
単独の実行ファイルを監視することはできても、他の作業のプログラムをチェックできません。

もう一つは、マップファイルとRSSファイルの一般化です。
現在、このサイトに合わせてあり、必要最低限度の作業しか出来ません。
これを一般化できれば何かと便利です。
必要なことは、初期設定が出来るようにすること、一から始める場合に使えるようにすることです。

110724

タイトルを「ページの自動化メモ」から「ページ制作を自動化する試み」に変更しました。

下の記事の通りで多少の積み残しがありますが、おおよそ考えた通りに動いています。
折角だから、Generatorを書き換える作業を追加しました。
現在、GeneratorはHPBになっています。これを適当な名前に書き換えるようにしました。

110721

一つの鳥種では、写真は5枚までと決めています。(例外もあります。)
既に5枚写真を出している場合に、新しい写真が出来ると、その鳥種のうち一番写りの悪いものと入れ替えます。
普通はこれでいいのですが、実際の評価は別にして、個人的にはまあまあの出来なので、1枚目に置きたい、
しかし、1枚めの写真も残したい、外すのは3枚目にしたい、と思う場合があります。

新しい写真を1枚目と入れ替え、今入れ替えられた写真を、今度は3枚目と入れ替える。
今までは、このように、入れ替え作業を2回やればいいはずだと思っていました。
実際、今日試してみました。写真集のページは期待通りに実行できました。
ただ、メモファイルとRSSファイルも2回書き変わって、新しい写真が2枚追加されたように表現されてしまいました。
それでも、メモファイルの方は簡単に手書きで修正できます。

RSSファイルが、もう手書きでは判らなくなっています。対策を考える必要があります。
新しく作り直せばいいのでしょうが、RSSだけ書き換えない選択肢を作ればいいように思います。

110707

さて、新規写真の追加のケースに挑戦中です。
まったく新しい野鳥の写真が撮れた場合に使うものです。年に何度もあるケースではありません。
実際必要になった時、操作方法がわかるかどうか、多少心配しています。
ただ、このケースは結構厄介で、今数えると、8ページほど書き換えるファイルがあります。
ですので、完成すると便利にはなるはずです。

でも、自動化はちょっと無理だなと思えるページがあります。分類別の目次ファイルです。
どこかに新しいリンクを作らないといけないのですが、挿入位置を決めるのが難しそうです。
この部分だけ手入力になりそうです。

50音別の目次ファイルはなんとかなりそうです。
やはり、挿入位置に苦労しました。HSPのソートでは濁音半濁音がおかしいのです。
文字の大小の比較をした場合、濁音が後ろに行ってしまいます。
普通の辞書では、アオジとアオシギを並べた時、アオジ、アオシギの順だと思います。
それが、HSPの比較ではアオシギ、アオジで並んでしまいます。
対策は、比較用に濁音のない鳥名を作っておいて、配置を決めることにしました。

110703

バックアップファイルは、専用のフォルダにまとめることにしました。
最近は、ほとんどこのプログラムを使っていますので、バックアップファイルがすぐ増えてしまいます。
なにしろ、写真を一枚アップすると、通常、6、7枚のバックアップファイルができます。
適当なところで手動で削除しています。
考えてみると、今までは、一枚のファイルをUpする際には、バックアップの枚数だけ修正が必要だったわけです。
これを一挙に自動化できるのは、手前味噌ですが、かなりのことです。
一つ一つの作業は、たいしたことではないのですが。

バックアップファイルには、名前に日付を追加し、同じ名前が存在するなら、さらに通し番号を付加してあります。

さて、まったくの新規の写真のケースにも対応させようとしています。
あらかじめ、必要な項目のところがブランクのファイルを作っておき、それに項目を追加するようにします。

前準備が必要です。index.htmから通算の種目数を読み込む、学名ファイルから学名を取得、の二つです。
関連するファイル群のうち、RSSファイルはほぼ準用でOKでした。

マップファイルの挿入位置も何とかクリアしました。
HSPでは文字列の比較が出来ないのかと思っていましたが、if ("abc"!"bcd")>0、の形式で比較できるそうです。
これで、新しいデータの挿入位置を指定できます。

ただ、多分、3種類ある目次ファイルが自動化できないように思います。
特に、分類別の目次ファイルは、このままでは絶対に無理です。
あらかじめ、全種類の分類を決めておかないといけません。
まあ、新規の写真の追加は、年に何回もない作業です。手動で(HPBで)やることにします。
このままだと、HPBを使うのは、このメモのページぐらいです。

META name="GENERATOR"に署名を追加することにしました。
うまくいくようなら、他のプログラムにも追加します。

110615

バックアップルーチンの変更と、付随して多少のコードの修正が、ほぼ終わりました。
何しろ、ケースごとにプログラムを変えています。3本ありますので、大変でした。
写真集の写真追加と入れ替え、動作試験をやってみました。
といっても、実際に新しい写真をUPしてみただけです。異常は無いようです。

今後の改良点です。
肝心のバックアップファイルの名前付けに工夫が必要でしょう。
保守をしないと、各フォルダに点在するので、あとで削除とか大変になりそうです。
ファイル名で検索できるように、名前を工夫しておくか。まったく違うフォルダに移動するか、です。
HPBでリンク切れをチェックする時の範囲外に置くべきでしょう。

もうひとつ、少し引っかかるのが、写真入れ替えの際の古い写真の扱いです。
不要なものです。ただ、簡単に削除するのも忍びないので、これまでの手入力のときは、
まったく関連のないフォルダに残していました。
今回は移動用のフォルダを作って、そこに移しています。後々混乱するかも知れません。

RSSとMAPは一般化できるかも知れません。
初期設定、まったくデータがない場合、追加入力項目など、かなり大変ですが。

110612

UTF変換の目途がつきました。#include "jcode.as"でいいようです。作者の方(森々せつき様)に感謝です。
残念なことに、いまいち、使い方がわかりません。恐るおそるです。
ちゃんと動作はしています。

UTFがUTF-8Nになってしまいます。ただ、変換対象のMAPもRSSも、8Nでかまわないみたいです。
さらに、多分ですが、漢字なしの半角だけのファイルだと、UTF-8NとSJISとの区別がつかないみたいです。
勉強不足かもしれません。今のところエラーは出ませんので、これでいきます。
半角文字だけのファイルは、TeraPadで手動で試しても、漢字コードは同じになりますので、こんなものなのでしょう。

漢字コード変換とファイル保存との関係がわかりません。
BOMをあとで強引にくっつけるものなのでしょうか。

あわせて、バックアップファイルの共通ルーチンを作りました。
元のファイル名に日付を付けて、バックアップファイル名にしています。
さらに、同じ日付があれば、末尾に連番を付けるようにしました。
いままで固定のバックアップファイル名を使っていましたので、作業が続くと、バックアップファイルを
避難させていました。

順次、今までの全部のコードを書き直すことになります。
ここでも、ローカル変数とか、関数とか、引数とか、参照渡しとかあれば、便利だったと思います。
このメモが頼りです。もう少し詳しく記録する必要がありあます。

110610

HSPでページ制作の自動化を(5)
年度変り問題対策、
フォルダやファイルを変えたときの対策は、前年のデータを少し残しておけばいいように思います。
実際、毎年ファイルを新しくする時には、前年末のデータを少し残しておきます。
この状態で年を越せば、多分、大丈夫と思います。まあ、その時考える問題です。
メモファイルと一覧表ファイルが該当します。

110609

HSPでページ制作の自動化を(4)
昨日の記事で、このページを作る際、RSSファイルが手書きになってしまう事が、今後の課題と書きました。
ついでに、これを作ってしまいました。
大半のコードが準用できましたし、操作するファイルが、MAPとRSSだけですので、簡単でした。
写真集などのページと違って、文言がいろいろありますので、メモファイルが自動化できず、手書きです。

今後の課題、
ようやく一段落しました。今後は、コードを見直していく作業になるでしょう。
HSPはテキストファイル操作がとても便利です。今回大半のコードはメモリノートパッド命令です。
多少の不満は、変数のスコープ、受け渡しなどの概念がないことです。
コードが長くなってきたり複雑になってくると、変数の見直しなどが大変になります。
なにしろ、自分だけで使うものです。わざわざサブルーチンにするより、コピーペーストで貼り付けてしまいます。
というわけで、あとでの見直しが大変です。

なお、汎用性はまったくありません。扱うファイルがこのサイトのファイルです。
URLを使いますし、フォルダ構造が入っています。
それどころか、来年使えるかどうかわかりません。毎年フォルダを増やしている部分があります。
対応できる部分もありますが、対応しない部分もありそうです。

ページ作成作業は二つのPCでやっています。
PC間はバックアップファイルで同期を取っています。
これについては対応させています。ドライブ番号が違いますので、ここをチェックして変えています。

110608

HSPでページ制作の自動化を(3)
HSPというプログラミング言語でこのサイトのページの制作の自動化に取り組んでいます。
今回は観察野鳥一覧表関連のページを自動制作するものです。
さすがに各々の観察メモのページは作れません。手書き、といってもHPBでですが、で仕上げた後、
それに関連するページをこのツールで作ります。
実際、今日試してみました。期待通り動いているようです。

さて、経緯です。
当サイトは、写真集のページと観察野鳥一覧表のページをRSSファイルにしてあります。
これまでに、写真集のページは、下に記事があるように、自動化の体裁が整ってきました。
ただ、RSSのファイルを作るのに困った問題が起きました。
以前はフリーのツールでRSSファイルを作っておりましたが、写真集の各ページに関して、
自分のツールでRSSファイルも作るようにしたので、今まで使っていたものが使えません。
一覧表に関しては、RSSのデータ追加が手書きになってしまいました。
これではせっかくの自動化に逆行してしまいます。第一、RSSファイルは手書きだと結構面倒なのです。
そこで、ついでに観察野鳥一覧表も自動化することにしました。
これを今日、試してみました。うまくいっているようです。
自動で作るファイルは、制作メモ、観察野鳥一覧表、マップファイル、RSSファイル、です。

簡単に手順をメモしておきます。
まず、個々の観察メモのファイルから、観察日、鳥の名前を取り出し、
制作メモのページにメモ書きとリンクを追加、
一覧表に新しい行とリンクを追加、
マップファイルにデータを追加、
RSSファイルにデータを追加、古いデータを削除、
します。

残念なことは、こうした独立したページを作ったとき、やはり多少面倒な作業が残ります。
最後に、これも自動化することになりそうです。

もう一つ、漢字コードの変換がわかりません。
HSPで吐き出すファイルはSJISです。MAPとRSSは、これをUTFに変換する必要があります。
これらのファイルは、本来のページには直接影響しないことと、
ちょうど、バックアップファイルの格好になっているので、まあ、まったくの無駄ではありません。
現在は、いちいちテキストエディタで変換しています。
HSPで一括して出来ればいいのですが、勉強不足です。
HSPで出来なくても、何かのマクロで出来そうな気がします。これも課題です。

110524

HSPでページ制作の自動化を(2)
110513の記事に続き、写真集のページの制作の自動化作業を追加しています。
今回は、写真の入れ替え作業を自動化できる見込みになりました。
実際に、直前数回の入れ替え作業は今回作ったプログラムによるものです。
今のところ、恐るおそるの作業です。
でもリンクエラーもHTMLのエラーも出ませんので、実用上は大丈夫だと思います。
まだ、多少のコードの改良は必要でしょうが、ちゃんと動いているのです。

完全な自動化ではありません。多少の手動部分が残っています。
残っている部分は、RSSファイルなど、主に日本語コードに依存する部分です。
でも、これらは別のフリーのアプリを使わせていただいています。
そのアプリも便利なのですが、現時点では別々に起動しないといけないので、その分、わずらわしいのです。

さて、その作業をまとめると(前回と重複することもありますが)、
新しい写真を写真集のページに加えたい場合、追加の場合と、入れ替えの場合、があります。

つまり、一つは、例えば、同じ鳥の写真が既に2枚あって、3枚目の写真を追加したい場合、
この場合、まず、新しい写真のページを作ります。同じ鳥のページを利用して、写真を新しいものに入れ替え、
サムネイル写真とリンクを追加します。
他の同名の鳥のページに新しい写真のページへのサムネイル付きリンクを追加します。
その後、この制作メモのページに日付とメモ書きを加えます。

二つ目は、例えば、同じ鳥の写真が既に3枚あって、そのうちの1枚を新しいものと入れ替えたい場合、です。
写真を入れ替えるページは、写真の入れ替えとリンクのサムネイルの変更、
残りの同名のページは、サムネイルだけ変更、
入れ替えたものが1ページ目の写真だったら、目次のページのサムネイルも入れ替えます。
上と同じく、このページのメモの追加、です。

これらの前提として、新しい写真とそのサムネイル写真を作っておく必要があります。
逆に言うと、写真さえ準備すると、自動で写真集のページを作れます。

本当は、新規の写真のページも自動で作れるといいのですが、関連するファイルが多すぎるのと、
めったに必要がないので、まあよしとします。
それに、観察野鳥一覧表のページもありますが、これは私のレベルではどうにもなりません。

このサイトも、結構年数だけは食っていて、なかなか新しい種類は増えません。
でも、かなり以前の写真は、今になってみるとちょっと恥ずかしいなと思うものも多いです。
今回作った写真の入れ替えのプログラムは、この作業が便利になりそうです。

それに、ここまで来ると、もう作業がブログに近いものになっています。
つまり、写真を準備すると、ほぼ自動でページができます。
他所との交流のない私のサイトではブログの役割は終わりそうです。

110528追記、
RSSファイルも自動化に組み込みました。

110513

HSPでページ制作の自動化を(1)
ページの制作をある程度自動化出来ないかと頑張っています。
私のサイトを構成する個々のページは、ご覧のとおりで、構成が単純なものがほとんどです。
特に写真集のページは、ほぼ100%体裁が同じページに個々の写真があるだけです。
つまり、どのページも写真を入れ替えるだけで、ほとんど出来上がります。
そこでちょっとプログラムを組んだらいいのじゃないだろうか、という話です。
ただ、少しは単純ではなく、1枚写真を追加すると、つまり写真のページを1つ増やすと、
関連して数枚のページを書き換えないといけません。
このあたりが手作業の時、単純なのですが面倒でもあり、出来ればプログラムで自動化したい作業なのです。
まあ、いま流行りのブログも、もちろん私の作業とは比較にらないぐらい複雑なのでしょうが、同じようなものです。
基本的にはブログも、写真をアップロードすると、関連のページを自動で作ってくれるものです。

さしあたって、最も単純な写真の追加作業を半自動化してみました。
本当は、写真を作ってしまえば、ボタン一発でサイトに追加のページが出来上がる、と行きたいところですが、
さすがにまだ一部の作業が手動のままです。
それでも、写真の追加に関してはかなり楽になりました。
丁度、一か月前から実施しています。今のところエラーやリンク切れは出していないので、うまくいっているようです。
この間、新しい写真をどんどん入れています。これはこの成果と言えます。

やっている事は、
まず、追加する写真とそのサムネイルを作り、所定のフォルダに入れる。
このあと、プログラムで、既にあるページを雛型にして、新しい写真のページを作る。
そのページに、サムネイルを入れて自分自身へのリンクを付ける。
同じ鳥種のファイルが何枚かありますので、そのファイルに追加したページへのサムネイル付きのリンクを挿入する。
この制作メのページに日付とリンクを作る。
です。

また、HSPを使いました。
現在、写真の入れ替え作業の自動化に取り組んでいます。

110221

学名追加

写真集の個々のページに学名を追加してみました。
その方法です。

なにしろ写真が800ページほどあります。プログラムを組みました。
結果的には、いちいち書き込んだ方が早かったと思います。ちょうど一ヶ月かかりました。
プログラムはHSPで作りました。昔のBasicに一番近い言語だと思います。
学名のデータはWkipediaから頂きました。「日本の野鳥一覧」というページです。
このページをコピーし、Excelに移します。
Excelで簡単な関数を使って、項目などの、必要のない行や文字を省きます。
最終的に、鳥名と学名だけのテキストファイルにしました。
これをHSPで読み込んで使います。HSPはテキストファイルの操作がとても簡単なのがありがたいです。
JISコードの文字化け騒動で、全体をShiftJISコードに変更しておいたのも幸運でした。
ただ、上のページの学名のデータに、なぜか、一部古いものがあるようで、これを修正して使いました。

あとは、
各々のページを読み込む、
鳥名のある行を探す、
そこに対応する学名を追加する。
同じ名前で書き込む。
これをファイルの数だけ繰り返す。
で終わりました。

対応した学名を書き込まないといけません。
単なる置換をするだけとか、差し込みをするだけではうまくいかない作業でした。(と思います。)


トップページへ 前のページに戻る