HAMLOG プログラム開発室

Windows7ではうごきませんでした。
Ｈａｍｌｏｇのフォルダーに解凍もしてみましたが症状は代わりません。

Hamlogのデータを読み込んで、JARLのWAKUアワードを楽しむための
ソフトを作りました。URLからダウンロードできます。

よかったら使ってみてください。
皆様のフィードバックをお待ちします。

JG1MOU浜田OMのHamlog50.libとJO1SIM出島OMのTHW2VBNET.dll
を利用させてもらっています。この場をお借りして、両氏に感謝致します。

Ver5.13a迄は複数ＱＳＯをマネージャ経由で印刷した時は
Ｔｏ　Rario事に印刷していたのですが。
Ver5.13cにバージョンＵＰしてから　相手コールが異なっても
同一マネージャだと　一緒に印刷されてしまいました。

標記を作ってみました。ここの開発室の各氏のご指導の賜物です。

本件を思い立ったのは、ローカルのブラインドハムである、Ｍ氏
の希望によるものです。「もっとハムライフを楽しみたい」との
お話にグッときた次第です。

現在、β版を、ローカル各局にて試用いただいております。

機能に関しては本家 Hamlog に全く及びつかぬほど、お粗末な
ものですが、ブラインドの方には、むしろ、必要最小限の機能
に限定した方が良く、Ｍ氏の要件（特に、以下の6.）は満たし
ております。

1. マウス不要
2. 入力文字１字ごとの読み上げ（発声）
3. 入力フィールドは、コール、RST(HIS/MY)、FREQ、MODE
の４つのみ
4. フィールド毎、または、全フィールドの読み上げ
5. 現在の入力状態を、Hamlogデータにアペンド
（日時は、CPU Date/Timeから拾う）
6. 入力コールサインから、QSO履歴を検索。
検索結果、(名前)、今回のQSO回数、最近のQSOの年月日
の読み上げ。

データの削除、修正、QTHの入力、などはできず、これらは、
いまのところ、介助の方に 本家Hamlog から操作いただく、と
いう代物です。

ブラインドの方は、とにかく、マウス操作は困難、日本語入力
が困難、ということで、機能に押さえることにも意味はありま
す。…と啖呵を切ってみたものの、正直なところは、当方の
コーディング技量のなさによるわけでして…、hi。

もちろん、今後、Ｍ氏の希望により、技術的に可能な機能は
追加していきたいと思っております。そのときには、また、
皆様のお助けが、是非とも必要です。

当方、今回がはじめての「作品としてまとまった」Windowsプロ
グラミングですので、それなりです。ですけど、私もプロの端
くれでして、可能な限り、細やかな配慮は随所に込めたつもり
です。

※VC++ Ver 6.0 MFCによる

実に粗末なものですが、試用をご希望な方は、当方までメール
にてお問い合わせください。
（私のコールサイン＠jarl.com）

※表題の末尾には、必ず、de xxxxxx （xxxxxxはあなたか代理
　の方のコールサイン）を加えてください。時々、迷惑メール
　に紛れることがあり、その場合の救済になります。

※まだ、セットアップ説明書も作っていないですし、お届け
　するまでには、お時間いただくことになると思います。

とにもかくにも、ここまでこれたのも、皆様のお陰です。
どうも有難うございました。今後ともどうぞご指導よろしくお
願いいたします。

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

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



> > 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％の局は６バイトではないでしょうか。

浜田OM
こん●●は！

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

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

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

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

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

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

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

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 ファイルを破壊している様では無い様
なので、すこし、ホッとしております。