開発者の方へ

大変便利に利用させて頂いております。
質問ではなく改善提案なのですが、適当な場所が見当たらないのでこちらに投稿させて頂きます。

・「QTHの部分文字列検索」ですが、現状、大文字小文字までしっかり区別されてしまうため、国や地域名で検索する際、少々面倒に感じます。できればあいまい検索（大文字小文字やスペースの有無程度）ができれば尚、良いかと思います。

・DXのコードは、HAMLOG独自のコードを使用しているかと思いますが、私はDXはDXCCメインのため、QSLカードの管理やDXCCの集計などする際にはARRLのDXCCコードを使用しています。ログ、集計や検索にARRLのDXCCコードも表示、利用できるようになりますと尚、便利かと思います。

ご検討いただけましたら幸いです。

> ・「QTHの部分文字列検索」ですが、現状、大文字小文字までしっかり区別されてしまうため、国や地域名で検索する際、少々面倒に感じます。できればあいまい検索（大文字小文字やスペースの有無程度）ができれば尚、良いかと思います。

大文字小文字を無視した検索は、プログラムを改修すれば可能です。
個人的に、あまり必要性を感じなかったのでやってませんでした。

> ・DXのコードは、HAMLOG独自のコードを使用しているかと思いますが、私はDXはDXCCメインのため、QSLカードの管理やDXCCの集計などする際にはARRLのDXCCコードを使用しています。ログ、集計や検索にARRLのDXCCコードも表示、利用できるようになりますと尚、便利かと思います。

過去の交信データをどうするか、ですね。
そのため、現状のままでも十分という意見が多かったです。
ARRLのDXCCコードは、ソートしたときにJCC/JCGコードに混在してしまいますので、
そのままでは使えません。

例えば、3D2　Fiji では　176　ですが、A176のように国内よりも後に並ぶようにコード
を変える必要があります。
'A'でなくとも、'5'以上のキャラクタであればOKです。

どなたかが、たとえば
509A=A176
510A=A489
511A=A460
・・・のような感じでテキストファイルで変換テーブルを作ってくださる方がおりましたら、
過去データのコンバートツールを作ってみてもよいですが、ＰＣビギナーが混乱する
かもしれません。

こんにちは。

今回の機能が必要は分かりませんが。

> どなたかが、たとえば
> 509A=A176
> 510A=A489
> 511A=A460

拙作ファイルに下記のようなファイル ctydat2thwcode.mas 　があります。
古いので最新に確認の必要がありますが、必要でしたらお送り増した。
ＨＰで配布中の digi2thw.exe や eQSL2Thw.exe に同梱されています。　

3D2 ,509A,176 ,Fiji
3D2/c ,510A,489 ,Conway Reef (3D2/c)
3D2/r ,511A,460 ,Rotuma I. (3D2/r)

なるほど。CSV形式のものがあるのですね。
データ仕様を変更すると混乱しますので、さてどうしたものか・・・。
CTY.DATを利用する仕様に変更したときのようなメリットがあるかどうか、です。

> 拙作ファイルに下記のようなファイル ctydat2thwcode.mas 　があります。
> 古いので最新に確認の必要がありますが、必要でしたらお送り増した。
> ＨＰで配布中の digi2thw.exe や eQSL2Thw.exe に同梱されています。　
>
> 3D2 ,509A,176 ,Fiji
> 3D2/c ,510A,489 ,Conway Reef (3D2/c)
> 3D2/r ,511A,460 ,Rotuma I. (3D2/r)

お返事ありがとうございます。

DXのコードについては過去にそのような経緯があったのですね。

私なりに考えてみましたが、既にHAMLOGコードで慣れている方もいらっしゃるかもしれませんし、他の利用者に迷惑や手間をかけるような改修はよくないと思いますので、お手間をおかけしますが、HAMLOGコードとDXCCコードを共存させるというのはいかがでしょうか。

DX局の場合、データベースには従来のHAMLOGコードと、DXCCコードの両方を保持し、環境設定等で、HAMLOGコードを使うか、DXCCコードを使うかを選べるようにするという方法です。

データベースは、改修後の初回起動時に、現在のHAMLOGコードに基づいて、DXCCコードのフィールドを自動作成できれば、ユーザーによるコンバートなどの手間も発生しないかと思います。

私個人の意見としては、検索、集計、表示等でDXCCコードが表示、利用できれば問題ないので、先頭に識別のアルファベットが付くことは特に支障はありません。従来のHAMLOGコードと似すぎていてもいけませんので、D176のような付番でよろしいかと思います。

> DX局の場合、データベースには従来のHAMLOGコードと、DXCCコードの両方を保持し、環境設定等で、HAMLOGコードを使うか、DXCCコードを使うかを選べるようにするという方法です。
>
> データベースは、改修後の初回起動時に、現在のHAMLOGコードに基づいて、DXCCコードのフィールドを自動作成できれば、ユーザーによるコンバートなどの手間も発生しないかと思います。

ご提案ありがとうございます。
慣れていない方の対応をどうするか、ですね。
ARRLのDXCCコード方式に全面変更するか、当面は現状のままかの二択かと思います。
両方アリは、作るのも使うのも大変です。

私は今世紀に入ってから（HAMLOG作るようになってから）国内QSOがほとんどになって
しまいましたので、現状のままでも十分ですが。

部分文字列検索は、半角英字については大文字小文字の区別なしに変更しました。
https://hamlog.sakura.ne.jp/mou/index.html

ベータ版ありがとうございます。
QTH検索の操作性が、すごく良くなりましたので大変助かりました。

DXコードについては承知いたしました。以降は、コードの件については見守ることにします。

一応、なぜARRLコードにこだわるのかという点だけ、私の意見を述べておきます。
ARRLのDXCCでは、Lotw(ARRLの電子ログシステム）を使用する局がかなり増えてきておりますが、登録手順の煩雑さ（ライセンスのARRL本部への送付など）からか、まだ十分とはいえず、Paper QSLをやりとりすることがかなりあります。

これらPaper QSLは、後日ARRLの本部へ申請をして、Lotwシステムに反映（クレジット）してもらう必要がありますが、カードチェックに通したり、都度申請料金もかかりますので、私の場合は年1回程度でまとめて申請しています。

そこで必要なQSLカードを後日簡単に抽出できるよう、何らかの方法でソートして管理しておく必要があるわけですが、DXCCが国及び地域を単位としますので、国名アルファベット順にすると、例えばRとJが並び、どちらか前後かとなったときに、アルファベットの順序というのはあまりなじみがないので、判別が困難となり、抽出に余分な手間を要します。

それが数字なら、5と8どちらが前後かとなっても、簡単に判別ができます。

では、どの数字を付番するかとなったときに、LotwシステムではARRLコードが採番され、参照できる点、DXではおなじみのQRZ.comでもDX局の国名をクリックすればARRLコードが簡単に確認できる点の優位があり、ARRLコードで管理することとしました。

そして、いざ申請となった時、HAMLOGの「wkd/cfm一覧表示」で、既にLotwでcfmされているバンドやモードを重複して申請しないよう、チェックしながらDXCCの申請書を作成していきますが、この重複チェックの時に、HAMLOGコード＋国名なので、DXCCコードリストで国名を検索してARRLコードを確認してから、QSLカードを探すという手間が発生しているので、そのままHAMLOGでARRLコードが出たら便利だなと思った次第です。

ＡＲＲＬの　下記のリンクの　 DXCC Award Credit Report のページは
Prefix　(Sorted by)　Entity　(Sort by)　Deleted　Mix　Ph　CW　RT　SAT　160　80　40　30　20　17　15　12　10　6　2

3D2 CONWAY REEF X X X X 以下は省略

．．．の様に Prefix で表されています。
私はこのマトリックスを使用してＮｅｗをチェックしてＤＸＣＣの申請をしていました。
（最近はＮｅｗが増えないので申請の機会が無いが．．．）

https://lotw.arrl.org/lotwuser/awardaccount?awardaccountcmd=statu ..... ngo=1#list

情報ありがとうございます。

プリフィックス順での整理も初期の頃にやってはみましたが、やはりアルファベットなので、QSLカードを途中挿入や抽出するときに前後関係が分かりにくいので、個人的には数字が最適だと感じました。カード枚数が増えてくると、ARRLコードだとちょうど1／100／200／300／400／500番台+USAと箱で分けておいて、保管や区分けもしやすいのも利点です。

マトリックスは申請の時にHamlogのwkd/cfm一覧表示と組み合わせてhamlogにcfmになっているのにDXCCにはないもの=Paper QSLをチェックするという形で私も利用しています。

Paper QSLも個性や相手国の雰囲気が感じ取れて好きなのですが、集計の時にはやはり色々と混乱するので、少しでも分かりやすいといいなあと思って改善を提案させて頂きました。

思いつきで、hamlog.mstのエンティティ名の末尾（プリフィックスのフィールドの前）に、ARRLコードを挿入してみました。

QTHのデータ幅は、28から30に変更しました。

Logウィンドウでコールサインのみで入力すると、CTY.DATのエンティティ名が自動入力されるようなので、mstファイルのエンティティ名は無視されますが、複合条件検索の表示ではmstファイルのエンティティ名（複合条件検索でのエンティティ名表示はデータ幅は関係しないようですね）となるので、ARRLコードが表示されるようになりました。

こちらでやれる程度の雑な処置なので、既知の問題として
・データ幅を広げた分、エクセルなどに出力したとき、mstファイルのプレフィックスフィールドの一部が出てしまう
・複合条件検索出力やログウィンドウでコード部分が見切れる
・コードも含めたQTHをリスト選択で入力させると余分なスペースが増える
・コードも含めたQTHはいったんリスト検索をかけないと入らない
などあり、やや半端な状態ですが、コードを参照や検索（出力後にエクセルでコードを検索）するという目標は達成できているので、これをきれいに実装できればコード自体は変更をせずとも少なくとも私の必要な範囲でのコード利用は実現するので、実装案として提案いたします。

一応、しばらくの間、コードを追加したmstファイルは下記に置いておきます。
https://yuasa.org/at/JQ2MPJ/hamlog/