その他」カテゴリーアーカイブ

サポート日記からその他に変更20190530

夏みかん、今年の収穫は終了

庭に甘夏の木がある。3月、普通の甘夏はこれからが収穫期、だがうちのは終了した。

3月の様子

もう12月から黄色く色づいていた。今年は豊作と思っていたが。

12月の頃の写真

1月くらいからリスがかじり出して、ヒヨドリがつついて、メジロが食べたり、風で落ちたり、どんどんなくなっていく。昨年はこれらの影響で人間は一つも食べられなかった。

リスが食べているのならもう食べられるのでは?ということで、今年は1月から風で落ちたのを食べ始めた。酸っぱい。下手に食べるとむせて大変なことになる。砂糖をかけて食べるとむせないことに気づく。昔ババアがそうやって食べていたのを思い出す。若い頃は酸っぱいものを食べても、多少むせても平気だったがこの歳になるとむせかたが半端なくて辛い。なるほど砂糖をかけて食べるとむせる心配がない。これはこれでかなり美味しい。

2月に入ると樹熟が進んで甘くなってくる。別に八朔があって、こちらは今年初収穫。2月に14個取れた。八朔は美味しいな。

八朔も甘夏も皮は砂糖で煮てジャムにする。鍋に甘夏5個分くらいの皮を千切りにして入れて、水を張って煮る。沸騰したらお湯をこぼして、また水を張って煮る。これを3回繰り返す。4回目の沸騰の後、水が皮よりも少なくなったら砂糖を入れる。350gから400gがうちのお好みかな。これで水気が半分くらいになるまで煮詰める。程々で良い。冷めていく途中で水分が減るからね。

5個分の皮でこの容器の二倍くらいできる

3月14日、最後の4つを収穫。

間引きしていないせいか大きさがかなり違う
最初リスがかじって穴を開け、そこを鳥がつついてこうなる。何十個も食べられた

残りはリスと鳥にやられた残骸。今年は人間も食べられたので良かったです。

4D プロジェクトフォームとテーブルフォーム、イベントプロパティが違う その2

以前のブログで間違いがあったので修正するとともに、印刷用フォームについて再考した。プロジェクトフォームとテーブルフォームで制御できるイベントプロパティが違うのは「テーブルのレコードセレクションを前提としたイベントがプロジェクトフォームではサポートされていない」ということだった。以前ブログを書いた時の理解が足りていなかっただけで、考えてみればプロジェクトフォームには帰属するテーブルがないから、セレクションを前提としたプロパティが設定できないのは当たり前だ。

たとえばプロジェクトフォームのプロパティには「On Printing Detail」などの印刷時に発生しそうなプロパティがない。これはPrint selectionの時に有効で、セレクションが必要なのでテーブルに帰属していることが前提になるためにテーブルフォームにしかないプロパティなのだ。

たとえば、印刷時に「文字列が多くて印字領域に収まらなかった時に文字フォントを小さくして印刷する」という技を使っているのだが、これは印字しようとしている文字列長によって適用するかしないかが異なる。「On Printing Detail」が発生した時、文字列を一度配置してみて文字列オブジェクトの矩形の長さを評価して、所定の幅に収まりきらなかったら小さいフォントサイズを再設定するという仕様だ。それで「On Printing Detail」にコードを記述することになる。この実装がプロジェクトフォームでもテーブルフォームでも動いてしまう。あれっ、と思って調べたらどちらのフォームにも「On Printing Detail」イベント(Form event = 23)が発生していたのだ。では、テーブルフォームで「On Printing Detail」チェックを外したらどうなるか。これでも「On Printing Detail」イベントは発生していた。

印刷時に使っているコマンドは次。

Print form([Z_PrintForm];”PP11_PrintList”;Form detail)

ここで印刷するフォームオブジェクトに配置されているのは配列要素またはプロセス変数でありテーブルのセレクションは無関係。

Print formではフォームプロパティのイベント「On Printing Detail」のチェックオフが無視される。Print formでForm detailを直接印刷しているため、4Dが内部的に「On Printing Detail」イベントを発生させているように見える。よく見たらPrint formの説明に書いてあった。つまり、Print formを使うということは、印刷イベント「On Printing Detail」を強制的に発生させるという意味であり、フォームのプロパティ設定は無視される、ようだ。しかしヘッダーを印刷するとき、つまりPrint formの指定領域が「Form header」でも同じイベント「On Printing Detail」が発生するのはわかりにくい。どうやら指定領域ごとに異なるイベントを発生させる必要はない、と考えているようだ。まあ実用上は問題ないかもしれない。次のコードはいずれも「On Printing Detail」が発生した。

Print form([Z_PrintForm];”PP11_PrintList”;Form header)
Print form([Z_PrintForm];”PP11_PrintList”;Form detail)
Print form([Z_PrintForm];”PP11_PrintList”;Form footer)

以前のブログは次のように補足しよう。

1)Print formを使う場合、「On Printing Detail」イベントプロパティのチェックは印刷時に影響しない。

2)配列を印刷する場合のフォームはプロジェクトフォームでもテーブルフォームでもよい。

Print formで配列を印刷する場合はセレクションが関係しないため、どちらにフォームを作っても問題はない。テーブルフォームに作ることもできるがテーブルに帰属させる必要性はない。フォームを整理するという側面からは、テーブルの内容を一覧する(配列に転送したとしても)ものはそのテーブルのフォームに作る、ことは意味があるかもしれない。

しばらくは、印刷用フォーム専用テーブル[Z_PrintForm]に印刷フォームを作成して、プロジェクトに印刷フォームがどのくらいあるかを把握できるようにしたい。フォーム名は出力するデータの元のテーブルのプレフィックスをつけて、10番代から始める。たとえば上記であれば、PPというお売りフィックスのテーブルの1番目の印刷フォーム「PP11_」をつけてフォーム名を続ける。「PP11_SiharaiIchiran」とか。

以前のブログはこちら
4D プロジェクトフォームとテーブルフォーム、イベントプロパティが違う その1

2020は干し柿好調

2020 干し柿についてのメモ

10月になって庭の渋柿にオレンジ色が差してきた。早めと思ったが、たくさん生っているので順次収穫していかないと後工程が押してくるため収穫開始。今年は熟すのが早い印象。グズグズしているとヒヨドリに突っつかれてしまう。まずは30個くらいとってみて皮むき。

10日くらい干したら食べれた。いつも通り甘く、相変わらずタネは多い。

皮むき

水につけると乾きが悪くなるため洗わない。鉄の包丁は黒くなるのでセラミックを使う。スズラン紐で結んで、一本の干し竿に15個から20個引っ掛けて吊るす。

外干し

干し柿は戸外の物干しに引っ掛けておいて乾かす(外干し)。ずっと部屋干ししていると風が当たらないので乾きが悪く、室温が高いため腐りやすい。理想的には昼も夜も外干しが良い。くれぐれも雨に当てないように。濡らすと台無しになる。

2020.10.24

台風被害、鳥獣被害

思えば一昨年は台風被害、昨年は10個くらいしか取れなくて、干している最中にヒヨドリに全部食べられてしまって...

今年は台風被害は免れた。なぜかヒヨドリの被害がない。よしよしと思っていたら干している最中にやられた。おそらくアライグマだ。干して甘くなったやつだけ10個以上食べてった。竿を引き摺り下ろして、まだ乾いていないのも被害。夜中の12時ごろから1時間くらい目を離していた、その15分くらいの間に。

夜ぼしはNG

猫のかごを出してきて、これなら取られないだろうと、夜も外干ししておいたら、再びやられた。檻の中に手を伸ばしたのだろう、干し柿に届くようだ。12個くらい食べられている。夜はヤバイ。毎晩取り込むようにした。昼間はやられない、これで大丈夫だ。


11月に全量収穫

もうオレンジ色を通り越して赤みが出てきている。これ以上木の上においておくと熟してユルユルになって、皮むきができずに干し柿にならなくなる。大量に収穫、皮むいて、吊るす。朝外に出して、夕方家の中に引き込む。

夜このままにしておくと、下の方の甘くなったのを取られる


熟柿(ジュクシ)

皮むきを先送りにしていると柿は熟してくる。熟すと身がユルくなって干し柿にはできない。そのうち熟柿という状態になる。これはもう中身がユルユル。皮はブドウの皮のように薄くなって、見た目は赤みが出てきている。渋は、完全に抜けている時もあればまだ少し残っている時もあるがいずれも食べた直後は甘い。渋は後味にやってきて舌に残る。食べ終わるまでわからない。

11月12日、皮むき完了。この時点で330個。すでに食べちゃった分、クマに食べられた分、鳥にやられた分を考慮すると400個近く収穫できた事になる。10年くらい前に300個、という記録があったが、今年は記録更新。

柿の木1本から330個収穫

来年も豊作でありますように。

何年か収穫が思うようにならなかったため、鉢で育てていた2本の若い木(7、8年もの)を2年ほど前に庭植えした。タネから実生で増やしたやつだ。今年1個だけ花をつけたので来年あたり実がなるかもしれない。

4Dのプロセス変数にゲッターセッターを記述するのはもう古い?v18で提供されたClassesのFunctionが使えそう。

プロセス変数とはプロセス内で参照可能な変数のこと。プロセスというのは同じマシンならNew Processなどで区切られたメモリー上の作業空間とでも言えばいいか。Client/Server環境ではサーバサイドで実行などにより実行マシンが違えば作業空間は異なるので別プロセスだ。別のプロセスの変数はそれ用のコマンドを使わないと参照できない。

人それぞれ違うと思うが、ウチの開発スタイルではプロセス変数は次の2種類がある。

(1)フォームオブジェクトに割り当てるためのプロセス変数
(2)プロセス内でグローバルに参照するために用意する主として制御用のプロセス変数

(1)は4Dの仕様上必要な変数。フォームが表示されている間はメソッドからフォームオブジェクトを参照したくなるはずで、メソッドが終わってもフォームがある限り解放されないプロセス変数であることが合理的だ。個人的に、次のように名前を付けている。

・ vPL01_btnOK:PL01というフォーム上の「OK」ボタンという意味。ボタンの場合はプロセス変数に代入することはない。オブジェクト名を参照しているだけ。

・ vPL01_lstPL:PL01というフォーム上の「lstPL」リストボックスという意味。vPL01_lstPL_IDやvPL01_lstPL_NAMEなどを列として定義、DBのPLというテーブルから持ってきた値を表示する。プロセス変数はプロセス開始時に領域が確保されるが、リストボックスはOnload前は参照できないので注意。

・ vPL01_txtPL_NAME:PL01というフォーム上の「PL_NAME」フィールドで、DBのPL_NAMEから持ってきた値を表示するためのプロセス変数という意味。

変数名とオブジェクト名は別の名前をつけることもできる。どちらもプロセス開始時に領域を確保されてしまう。特に困ったこともないので「オブジェクト名と変数名はいつも同じ」にしている。同じ値のオブジェクトには同じ変数名をつければどちらも同じ値が表示される。が、別々の名前をつけて値はコードで代入し直す方が主流だ。

(2)は、フォーム上に表示されない、プロセス内の制御用の変数。例えばよく使う変数としては、ダイアログを表示するメソッドの場合にどのフォームから呼ばれたかを示すモードのような変数「vPL01_varMode」とか、一覧で選択されていたIDを詳細画面で保持するための変数「vPL_varPL_ID」とか、印刷時に現在のページ数を印字するための変数「vP01_varPageNr」など、がある。

このような変数にはいわゆるゲッター/セッターを用意して直接参照はしないようにする。フォームオブジェクト以外は、基本的に変数はローカル変数にすべきで必要な関数に引数で渡して使う、という考え方がまずあって、オブジェクト型の変数が無かった時代は多くの引数が必要になってしまって面倒すぎるのでグローバル変数を使いたい、という時代背景がある。例えば「vPL01_varMode_get」と「vPL01_varMode_set」である。次のように使う。

//PL01_DefInit
・・・
C_TEXT(vPL01_varMode)
・・・

//vPL01_varMode_get
C_TEXT($0)
$0:=vPL01_varMode

//vPL01_varMode_set
C_TEXT($1)
vPL01_varMode:=$1

//PL01_SetContorolsValues
・・・
//新規追加モードの場合、削除ボタンは非表示にする
C_TEXT($mode)
$mode:= vPL01_varMode_get
if ($mode=“add”)
 OBJECT SET VISIBLE(*;”vPL01_btnDelete”;False)
end if
・・・

このように記述していると、メソッド内にはフォームオブジェクト以外のプロセス変数が現れなくなる。このやり方は、まだ4Dに不慣れな頃に師匠から伝授されたものだ。初めはなんでこんな面倒なことをするのだろうと思っていたが、今でもこのやり方を踏襲している。実はこの種のプロセス変数はそんなに多くない。メソッド数が増えてしまうが、たいして手間ではないし、このようにすることでデバッグタイムが少なくなっていると感じている。教えてくださった先輩に感謝!

この方法の欠点としてメソッド数が増えてしまうと書いた。わずか2行のコードのために新しいメソッドを作る手間も感じていたがv18で改善された。ClassesのFunctionを使えば、オブジェクト表記の延長で「vPL01_varMode.get」などとメンバー関数を記述できる。そしてなんと一つのメソッドエディタ内に複数のFunctionを定義してゲッターとセッターを記述できるようになるのだ。

Laurent Esnault氏のセッション。今年の4D Summit 2020はオンラインで無料。英語がダメでも画面見てれば大体わかる素晴らしいデモに感謝。その内容に感激!4Dライフが大きく変わること必至。

まだv13のプロジェクトもあるが、コーディング規約を改訂するときがきたようだ。