HAMLOG プログラム開発室

前略、ご無沙汰しております。5年振りの書き込みです。5年前は、
浜田、森、両OMの GetProcAddress() の手ほどきのお陰で、DLLの
関数をアクセス可能となり、Hamlogアプリケーション製作に開眼
しました。

このたび、ひょんなことで、ブラインドハム向け、名付けて
"TalkHamlog" を開発することになりました。HAMLOGデータの
検索、読み込みについては旨い具合に機能させているのですが、
書き込みについては今回初めてで、四苦八苦しております。

ちなみに開発環境は、VC++ Ver6.0 MFC環境です。ただ、HAMLOG
アクセス部分は、C言語でコーディングしております。

教えていただきたいのは、まずは「データの追加」です（これすら
うまくいかないので、delete や update まで手が伸びません）。

データの追加は、
・HamlogOpen()
・Th.Qso各メンバへの値のセット
・THW_append()
・THW_flush()
・HamlogClose()
の順で行ってます。データの登録は、この後本家 Homlogブラウザ
でうまく表示されることから、うまく行っていっているものと
思われます。

問題の内容は、まず、"JA1AAA" のコールサインで、1レコード追加
に成功、続いて、"JA1AAAA"（サフックスが１桁多い）をキーに
コールサイン検索 THW_seek() したところ、エラーダイアログ
「No15 インデックスの再構築が必要」が表示されてしまう
（返り値=NOSYC）、というものです。

そこで、一旦プログラムを終了し、Hamlog.dx* をハンド削除後、
起動（インデックスの再作成を実施）したのですが、同様に
THW_seek()したところ、これが改善せず、同様に NOSYC を返して
きてしまいます。

多分、私の、データの Append の手順が良くなく、THW_append()
の前後に、他の手続き（サービス関数のCALL）が必要なのではな
いか、と感じてます。ここをどうかご教授賜りたく。

また、別件ですが、以下の２点も追加で質問させていただきたく。

(1) Th.Qso.Flag1 の詳細

　"DXの場合、8～10" と説明されているところがありますが、つまり
ここはビット単位で色々な細かい情報を保持しているものと思われ
ます。その詳細と、使用法を教えてください。

　私の現在の思い込みでは、国内QSOは 0、DX QSO時は 8 をセット
してやる、くらいで、これだけでやっております。

(2) THW_idxrmv() の機能

　仕様書を何度読み返しても、意味がつかめません。まず、この
関数は、READ時に有用なのでしょうか、WRITE時に有用なのでしょ
うか？。そして、どういう局面で、何の目的に使用するのでしょ
うか？。

　私の勝手な思い込みですが、そもそも、THW_append() はデータ
部の追加しか行っておらず、インデックスに対してお手当てして
いない（だから先述の様な問題が起こっている？）。インデックス
に対して、別途お手当てが必要で、そして、これを行うのがこの
関数ではないか?、と、邪推しているところなんです…。

　私のローカルのブラインドハムさんの期待も高いことから、何
とか解決したいと思ってます。夢は、フリーソフトとして一般公開
することです…。

　どうぞよろしくお願い致します。草々

洗川様

ＪＯ１ＳＩＭ でしまです。
お空でもお世話になっております！

私もVC++でプログラミングしています。残念ながらAppendを使ったものは作ったことないのですが、インデックスの仕様に関して私が気付いた点についてお知らせします。

JA1AAA局を登録した後、JA1AAAAで検索した時の挙動ですが、本家HAMLOGでも、JA1AAA局と交信した後JA1AAAAを入力しようとすると、一瞬JA1AAA局との交信が表示され、そして消えるという挙動をします。

したがって、append自体の問題ではなく、seekの仕様（インデックスの仕様？）が関係しているのではないかなと思っています。サフィックス３文字のコールサインの時は正常にseekも動いているのではないかと思いますが、いかがでしょうか？

もう１点…
Flag1の仕様ですが、現在のところ以下のようです。

(Flag1 & 0x08) ==> DX
(Flag1 & 0x10) ==> CQ






> 前略、ご無沙汰しております。5年振りの書き込みです。5年前は、
> 浜田、森、両OMの GetProcAddress() の手ほどきのお陰で、DLLの
> 関数をアクセス可能となり、Hamlogアプリケーション製作に開眼
> しました。
>
> このたび、ひょんなことで、ブラインドハム向け、名付けて
> "TalkHamlog" を開発することになりました。HAMLOGデータの
> 検索、読み込みについては旨い具合に機能させているのですが、
> 書き込みについては今回初めてで、四苦八苦しております。
>
> ちなみに開発環境は、VC++ Ver6.0 MFC環境です。ただ、HAMLOG
> アクセス部分は、C言語でコーディングしております。
>
> 教えていただきたいのは、まずは「データの追加」です（これすら
> うまくいかないので、delete や update まで手が伸びません）。
>
> データの追加は、
> ・HamlogOpen()
> ・Th.Qso各メンバへの値のセット
> ・THW_append()
> ・THW_flush()
> ・HamlogClose()
> の順で行ってます。データの登録は、この後本家 Homlogブラウザ
> でうまく表示されることから、うまく行っていっているものと
> 思われます。
>
> 問題の内容は、まず、"JA1AAA" のコールサインで、1レコード追加
> に成功、続いて、"JA1AAAA"（サフックスが１桁多い）をキーに
> コールサイン検索 THW_seek() したところ、エラーダイアログ
> 「No15 インデックスの再構築が必要」が表示されてしまう
> （返り値=NOSYC）、というものです。
>
> そこで、一旦プログラムを終了し、Hamlog.dx* をハンド削除後、
> 起動（インデックスの再作成を実施）したのですが、同様に
> THW_seek()したところ、これが改善せず、同様に NOSYC を返して
> きてしまいます。
>
> 多分、私の、データの Append の手順が良くなく、THW_append()
> の前後に、他の手続き（サービス関数のCALL）が必要なのではな
> いか、と感じてます。ここをどうかご教授賜りたく。
>
> また、別件ですが、以下の２点も追加で質問させていただきたく。
>
> (1) Th.Qso.Flag1 の詳細
>
> 　"DXの場合、8～10" と説明されているところがありますが、つまり
> ここはビット単位で色々な細かい情報を保持しているものと思われ
> ます。その詳細と、使用法を教えてください。
>
> 　私の現在の思い込みでは、国内QSOは 0、DX QSO時は 8 をセット
> してやる、くらいで、これだけでやっております。
>
> (2) THW_idxrmv() の機能
>
> 　仕様書を何度読み返しても、意味がつかめません。まず、この
> 関数は、READ時に有用なのでしょうか、WRITE時に有用なのでしょ
> うか？。そして、どういう局面で、何の目的に使用するのでしょ
> うか？。
>
> 　私の勝手な思い込みですが、そもそも、THW_append() はデータ
> 部の追加しか行っておらず、インデックスに対してお手当てして
> いない（だから先述の様な問題が起こっている？）。インデックス
> に対して、別途お手当てが必要で、そして、これを行うのがこの
> 関数ではないか?、と、邪推しているところなんです…。
>
> 　私のローカルのブラインドハムさんの期待も高いことから、何
> とか解決したいと思ってます。夢は、フリーソフトとして一般公開
> することです…。
>
> 　どうぞよろしくお願い致します。草々

JO1SIM 出島さま

　早速のお返事有難うございます。そうですね、確かに一瞬何か表示
されている挙動は感じられます。もしそうであっても、本家HAMLOG
では、「No15 インデックスの再構築が必要」のダイアログ表示は
まぬがれてますね。THW_seek() では、ダイアログを表示してから、
返り値=NOSYC を返してくるので、このダイアログ表示を抑止する
ことができません。おそらく、本家は、THW_seek()を使わず、イン
デックスのみをアクセスする関数群で対応しているのかもしれませ
んね（ちょっと実験しみます）。

Flag1に関しては、明解な情報、誠に有難うございました。

今後もどうぞ（QSOも含め）よろしくお願い致します。


> 洗川様
>
> ＪＯ１ＳＩＭ でしまです。
> お空でもお世話になっております！
>
> 私もVC++でプログラミングしています。残念ながらAppendを使ったものは作ったことないのですが、インデックスの仕様に関して私が気付いた点についてお知らせします。
>
> JA1AAA局を登録した後、JA1AAAAで検索した時の挙動ですが、本家HAMLOGでも、JA1AAA局と交信した後JA1AAAAを入力しようとすると、一瞬JA1AAA局との交信が表示され、そして消えるという挙動をします。
>
> したがって、append自体の問題ではなく、seekの仕様（インデックスの仕様？）が関係しているのではないかなと思っています。サフィックス３文字のコールサインの時は正常にseekも動いているのではないかと思いますが、いかがでしょうか？
>
> もう１点…
> Flag1の仕様ですが、現在のところ以下のようです。
>
> (Flag1 & 0x08) ==> DX
> (Flag1 & 0x10) ==> CQ
>
>
> > 前略、ご無沙汰しております。5年振りの書き込みです。5年前は、
> > 浜田、森、両OMの GetProcAddress() の手ほどきのお陰で、DLLの
> > 関数をアクセス可能となり、Hamlogアプリケーション製作に開眼
> > しました。
> >
> > このたび、ひょんなことで、ブラインドハム向け、名付けて
> > "TalkHamlog" を開発することになりました。HAMLOGデータの
> > 検索、読み込みについては旨い具合に機能させているのですが、
> > 書き込みについては今回初めてで、四苦八苦しております。
> >
> > ちなみに開発環境は、VC++ Ver6.0 MFC環境です。ただ、HAMLOG
> > アクセス部分は、C言語でコーディングしております。
> >
> > 教えていただきたいのは、まずは「データの追加」です（これすら
> > うまくいかないので、delete や update まで手が伸びません）。
> >
> > データの追加は、
> > ・HamlogOpen()
> > ・Th.Qso各メンバへの値のセット
> > ・THW_append()
> > ・THW_flush()
> > ・HamlogClose()
> > の順で行ってます。データの登録は、この後本家 Homlogブラウザ
> > でうまく表示されることから、うまく行っていっているものと
> > 思われます。
> >
> > 問題の内容は、まず、"JA1AAA" のコールサインで、1レコード追加
> > に成功、続いて、"JA1AAAA"（サフックスが１桁多い）をキーに
> > コールサイン検索 THW_seek() したところ、エラーダイアログ
> > 「No15 インデックスの再構築が必要」が表示されてしまう
> > （返り値=NOSYC）、というものです。
> >
> > そこで、一旦プログラムを終了し、Hamlog.dx* をハンド削除後、
> > 起動（インデックスの再作成を実施）したのですが、同様に
> > THW_seek()したところ、これが改善せず、同様に NOSYC を返して
> > きてしまいます。
> >
> > 多分、私の、データの Append の手順が良くなく、THW_append()
> > の前後に、他の手続き（サービス関数のCALL）が必要なのではな
> > いか、と感じてます。ここをどうかご教授賜りたく。
> >
> > また、別件ですが、以下の２点も追加で質問させていただきたく。
> >
> > (1) Th.Qso.Flag1 の詳細
> >
> > 　"DXの場合、8～10" と説明されているところがありますが、つまり
> > ここはビット単位で色々な細かい情報を保持しているものと思われ
> > ます。その詳細と、使用法を教えてください。
> >
> > 　私の現在の思い込みでは、国内QSOは 0、DX QSO時は 8 をセット
> > してやる、くらいで、これだけでやっております。
> >
> > (2) THW_idxrmv() の機能
> >
> > 　仕様書を何度読み返しても、意味がつかめません。まず、この
> > 関数は、READ時に有用なのでしょうか、WRITE時に有用なのでしょ
> > うか？。そして、どういう局面で、何の目的に使用するのでしょ
> > うか？。
> >
> > 　私の勝手な思い込みですが、そもそも、THW_append() はデータ
> > 部の追加しか行っておらず、インデックスに対してお手当てして
> > いない（だから先述の様な問題が起こっている？）。インデックス
> > に対して、別途お手当てが必要で、そして、これを行うのがこの
> > 関数ではないか?、と、邪推しているところなんです…。
> >
> > 　私のローカルのブラインドハムさんの期待も高いことから、何
> > とか解決したいと思ってます。夢は、フリーソフトとして一般公開
> > することです…。
> >
> > 　どうぞよろしくお願い致します。草々

JO1SIM 出島さま

　JG2NUD洗川です。続報です。

You wrote:
> append自体の問題ではなく、seekの仕様（インデックスの仕様？）

先ほど、

・本家HAMLOGで、"JZ1ZZZ" を追加
・私のPGで、"JZ1ZZZZ" を key に、THW_seek() をコール

　…したところ、同様に「No15 インデックスの再構築が必要」の
ダイアログと、返り値=NOSYC を返してきました。

　ここから考えられることは、当方の、THW_append() に問題がある
のではなく、むしろ、THW_seek() にあるのではないか、ということ
です。今回のような検索に対しては、返り値=NDXEOF を返して欲しい
（もちろんエラーダイアログのポップアップなしで）ところです。

　idx_next() + dbf_read() による実験は、追々実施しようと思い
ます。とりあえず、THW_append() には問題ない、つまり、私の
プログラムのせいで、hdb ファイルを破壊している様では無い様
なので、すこし、ホッとしております。

> 　ここから考えられることは、当方の、THW_append() に問題がある
> のではなく、むしろ、THW_seek() にあるのではないか、ということ
> です。今回のような検索に対しては、返り値=NDXEOF を返して欲しい
> （もちろんエラーダイアログのポップアップなしで）ところです。

コールサインのキー長は６バイトで処理してますので、７バイトで検索
をかけた場合は内部で強制的に６バイト処理にしているつもりでしたが、
うまく動作していないのかもしれませんね。

ハムログ本体では、６バイトを超える文字列は６バイトに切り詰めて
検索をかけますので、エラーはでません。

浜田OM
こん●●は！

ご回答ありがとうございます。

seekを使う場合は６文字で検索し、検索結果に対して検索をかけたコーサインで再検証するという感じになりますでしょうか？

しかし、最近のコールサインのバリエーションには泣かされますね。（笑）

> > 　ここから考えられることは、当方の、THW_append() に問題がある
> > のではなく、むしろ、THW_seek() にあるのではないか、ということ
> > です。今回のような検索に対しては、返り値=NDXEOF を返して欲しい
> > （もちろんエラーダイアログのポップアップなしで）ところです。
>
> コールサインのキー長は６バイトで処理してますので、７バイトで検索
> をかけた場合は内部で強制的に６バイト処理にしているつもりでしたが、
> うまく動作していないのかもしれませんね。
>
> ハムログ本体では、６バイトを超える文字列は６バイトに切り詰めて
> 検索をかけますので、エラーはでません。

> seekを使う場合は６文字で検索し、検索結果に対して検索をかけたコーサインで再検証するという感じになりますでしょうか？

そういうことになります。
ハムログ本体のデュープチェックでは、idx_search()を使ってます。
つまり、動作を軽く見せるために、とりあえずはインデックスファイル
のみ読み込んでます。

> しかし、最近のコールサインのバリエーションには泣かされますね。（笑）
そうですね。
Ver5.00にしたときは、キー長を７バイトとしたのですが、まだまだ
99.9％の局は６バイトのコールサインでしたので、Ver5.02で６バイトに
戻しました。
現在でも、99％の局は６バイトではないでしょうか。

JG1MOU 浜田さん

　ご無沙汰しております。作者さまにご登場賜り光栄です。

　このたびは、「コールサインを KEYとする場合の、正しい THW_
seek()」の使用方法をご教授くださり、誠に有難うございました。
キーは６文字（以内）で渡す件、早速、当方のプログラムに適用さ
せていただきます。

　とにかく恐れるのは、当方が作ったプログラムで、使った人が何
年もかかって入力してきたデータを、破壊してしまうことです。
これまで、読み込みオンリーのアプリしか作ったことがなく、今回
初めて書き込み操作を行う、ということで、丹念に検証していたと
きに、本件にたまたま遭遇したというわけです。大事でなくて良かっ
たです。

　今後も益々のご活躍を期待申し上げますと共に、ご指南賜ります
様、よろしくお願い致します。

※THW_idxrmv() についても、いずれお時間できましたときで結構
　ですので、お教えくださいましたら幸いです。

おっしゃる通りでございます！
残り１%のためにデータ量や処理速度が数１０%のオーダーで悪化するのは実装コストに見合いませんね。

貴重な情報ありがとうございました！



> > seekを使う場合は６文字で検索し、検索結果に対して検索をかけたコーサインで再検証するという感じになりますでしょうか？
>
> そういうことになります。
> ハムログ本体のデュープチェックでは、idx_search()を使ってます。
> つまり、動作を軽く見せるために、とりあえずはインデックスファイル
> のみ読み込んでます。
>
> > しかし、最近のコールサインのバリエーションには泣かされますね。（笑）
> そうですね。
> Ver5.00にしたときは、キー長を７バイトとしたのですが、まだまだ
> 99.9％の局は６バイトのコールサインでしたので、Ver5.02で６バイトに
> 戻しました。
> 現在でも、99％の局は６バイトではないでしょうか。