> 各位OMさん
> こう言うメッセージが出ますが、どういう原因ですか？
想定外のエラーが発生していますよと言う事ですので原因不明のエラー発生です（保護エリアすなわち読み書きすべきエリアで無いのに読み込もうとするとでる警報）。
この様な時に必ず発生していますとの情報があれば改善出来る事もありますが、普通は超難しい案件でもあります。
今のOSは良いですよね、Hamlog内で不都合が発生してもHamlogが停止するだけで、初期のOSは　システム全体が動かなくなってしまう厄介なものでしたから。
と言う事で　滅多にシステムまで影響のないものなので（無いとも言い切れないのですが）、自己責任でお使いください。　但しこのエラーが出た際は　継続させないで終了させることがリスクを」最小限に抑える事になります。　

【2021/05/22(Sat) 07:40:58 投稿者により修正されました。】

銅子OM
ご返信ありがとうございました。
HAMLOGからのエラーではなければ、仕方がありませんね、、、　

私も同じようなエラーが最近出ます。発生するのは、hqslとハムログを同時に動かしている時でかつ、hQSLを送信しているときに、ハムログにコールを打ち込んだ時、起こっているのではないかと思っています。
　一日の終了時にhQSLを送信すればよいのですが、ちょくちょく送信・受信するのでこのようなことが起こっています。２つのソフトに共通するデータがあるのではないでしょうか？？プログランミングは初心者なので、的を外していたらお許しください。

> 銅子OM
> ご返信ありがとうございました。
> HAMLOGからのエラーではなければ、仕方がありませんね、、、　

hQSLとHAMLOGを同時起動中の場合は、どちらか一方がクルマでいうところの
アイドリング状態のとき操作してください。

同一のQSOデータを操作していますので、例えばhQSLが送信中、照合中などの
ときはHAMLOGを操作しない方が無難です。

逆に言いますと、HAMLOGでQSL印刷のためデータを読み込んでいるときは、
hQSLは操作しないでください。そっとしてあげてください。

> 私も同じようなエラーが最近出ます。発生するのは、hqslとハムログを同時に動かしている時でかつ、hQSLを送信しているときに、ハムログにコールを打ち込んだ時、起こっているのではないかと思っています。
> 　一日の終了時にhQSLを送信すればよいのですが、ちょくちょく送信・受信するのでこのようなことが起こっています。２つのソフトに共通するデータがあるのではないでしょうか？？プログランミングは初心者なので、的を外していたらお許しください。

浜田OMうまく説明されますね。どの様に表現しようか迷っていました。
HamlogのAPIを使って補助プログラムを作っているとこの問題に難儀していました。VC#なので非同期処理を比較的簡単に実現できるのですが肝心のHamlogAPIが対応していないので結局のところ　ＡＰＩ呼び出しをＴａｓｋ化してこれをFIFOで制御する事で　ｄｌｌのアクセスを重複しない様に工夫しました。Ｔａｓｋ毎に　Turbo HAMLOGデータアクセス構造体　を切り替えるなどの処理も必要ですが何とか動作する様になりました。また、Hamlog本体とは違うフォルダーで別ｄｌｌを使う事でＨａｍｌｏｇとの干渉も排除する様にしています。ファイル関係は共用を可能にすることで問題を回避しています。C++ではどうなんでしょうか、自前で構築しなければいけないのであれば、それは大変。C#に切り替えるにしても　これも難儀。八方塞がりの現状浜田OMの心境が推し量れるところです。でも出来ると良いですよね、印刷しながらQSOが出来る、何か検索しながらQSOも出来る。デジタル通信になると、ながらQSOが出来る時代ですから。新しい技術の体験アマチュアながら楽しんでおります。

> hQSLとHAMLOGを同時起動中の場合は、どちらか一方がクルマでいうところの
> アイドリング状態のとき操作してください。
>
> 同一のQSOデータを操作していますので、例えばhQSLが送信中、照合中などの
> ときはHAMLOGを操作しない方が無難です。
>
> 逆に言いますと、HAMLOGでQSL印刷のためデータを読み込んでいるときは、
> hQSLは操作しないでください。そっとしてあげてください。

Windows-98時代のコンパイラ使ってますので、なかなか難しいですね。
最新の開発ソフトでは、今さら頭が付いていきません。

たぶん、HAMLOGを共有オープンで動作させれば、エラーにはならないものと思ってますが、
詳しくテストしていません。

今、移動運用を終えて一息ついたところです。
コンディションが悪いので、リグのCQマシン機能に助けられました。

> 浜田OMうまく説明されますね。どの様に表現しようか迷っていました。
> HamlogのAPIを使って補助プログラムを作っているとこの問題に難儀していました。VC#なので非同期処理を比較的簡単に実現できるのですが肝心のHamlogAPIが対応していないので結局のところ　ＡＰＩ呼び出しをＴａｓｋ化してこれをFIFOで制御する事で　ｄｌｌのアクセスを重複しない様に工夫しました。Ｔａｓｋ毎に　Turbo HAMLOGデータアクセス構造体　を切り替えるなどの処理も必要ですが何とか動作する様になりました。また、Hamlog本体とは違うフォルダーで別ｄｌｌを使う事でＨａｍｌｏｇとの干渉も排除する様にしています。ファイル関係は共用を可能にすることで問題を回避しています。C++ではどうなんでしょうか、自前で構築しなければいけないのであれば、それは大変。C#に切り替えるにしても　これも難儀。八方塞がりの現状浜田OMの心境が推し量れるところです。でも出来ると良いですよね、印刷しながらQSOが出来る、何か検索しながらQSOも出来る。デジタル通信になると、ながらQSOが出来る時代ですから。新しい技術の体験アマチュアながら楽しんでおります。

浜田さん、皆さん、ご無沙汰しています。

ファイルの排他使用に関してですが...

> たぶん、HAMLOGを共有オープンで動作させれば、エラーにはならないものと思ってますが、
> 詳しくテストしていません。

こういう時、Hamlogが使用している時は、"使ってます.HLOG" というファイルを、H-QSLが使用している時は、"使ってます.HQSL" という空のファイルを作成して、もう片方のプログラムがアクセスする前に、そのファイルがあるかどうかをチェックし、そのファイルが無くなるまでループして待つ、ということで、とりあえず、排他使用の真似事はできるかと思います。

さらに、待ちループを経験したら、念のために、データファイルは改めて読み込みなおす、というのではだめでしょうか。

JP7CZE川辺さん、どうもどうも、お久しぶりです。

実は、ファイル共有のときは、そんなことやってます。
QSOデータをSaveするときに HAMLOG.shareというファイルを生成し、Saveが完了したら
HAMLOG.shareファイルを削除しています。

他のHAMLOGは、HAMLOG.shareファイルが既に存在する間はQSOデータに書き込み
できない、という仕様です。

hQSLと併用のときはそこまでやってませんでした。もう頭がついていきません。Hi

> 浜田さん、皆さん、ご無沙汰しています。
>
> ファイルの排他使用に関してですが...
>
> > たぶん、HAMLOGを共有オープンで動作させれば、エラーにはならないものと思ってますが、
> > 詳しくテストしていません。
>
> こういう時、Hamlogが使用している時は、"使ってます.HLOG" というファイルを、H-QSLが使用している時は、"使ってます.HQSL" という空のファイルを作成して、もう片方のプログラムがアクセスする前に、そのファイルがあるかどうかをチェックし、そのファイルが無くなるまでループして待つ、ということで、とりあえず、排他使用の真似事はできるかと思います。
>
> さらに、待ちループを経験したら、念のために、データファイルは改めて読み込みなおす、というのではだめでしょうか。

浜田さん、

> 実は、ファイル共有のときは、そんなことやってます。
> QSOデータをSaveするときに HAMLOG.shareというファイルを生成し、Saveが完了したら
> HAMLOG.shareファイルを削除しています。
>
> 他のHAMLOGは、HAMLOG.shareファイルが既に存在する間はQSOデータに書き込み
> できない、という仕様です。

なるほど、まあ、OS上の共有制御ができないときの定番ですからね。このBBSのCGIでも、様々な複数同時の書き込み（投稿、修正、削除）のために、書き込み中を示すフラグのファイルを使っているはずです。

> hQSLと併用のときはそこまでやってませんでした。もう頭がついていきません。Hi

あまり難しく考えずに、hQSLもHamlogとまったくルーチンで、一つの HAMLOG.share で制御できるはずかと思います。複数のHamlogの立ち上げで事実上問題が無いわけなので、それにhQSLを加えても、事実上問題はないように思いますが。

ユーザー任せにするよりは、はるかに大幅にリスクは低下できるわけで、ぜひやってみてはどうでしょうか（ほとんどHamlogのコードをコピペでできる？）。