HAMLOG プログラム開発室

近況です。

デスクトップ機をWindows7 Pro 64bitに更新しました。

Turbo HAMLOG/Winのコンパイラは、Delphi3.1と、Borland C++5.0です。
なんと、Windows95時代のものを、いまだに使ってます。
Delphi3.1は、インストーラが16ビットコードを使っているらしく、
64bit Windowsにはインストールできません。

Delphi7なら問題なく動作しているという記事を読みましたの
で、Delphi7をインストールしてみました。
これだって、もう10年も前に買ったコンパイラです。

いざ、コンパイルしてみると、エラーの嵐で大幅なコード修正を
余儀なくされそうです。

あきらめてVMwareの仮想PCのWindows XPモードにDelphi3.1を
インストールしてみましたが、重い・・・。

ここで思い切ってWindows XP環境からフォルダごとWindows7に
コピーし、レジストリも同様に書き換えてやったら、ばっちり動作
してくれました。

４コアマシンでWindows95時代のソフトを動かすわけですから、
そりゃ速いです！　快適快適！

この要領でVisual C++ 5.0もインストールし、快適に動作してくれ
ます。

これで、Windows7のサポートが切れるまでは、20年前の開発環境の
まま、遊べることが確認できました。　めでたしです。Hi

> 初めまして。
> iPhone iPad版のHAMLOGを作ろうと思っていますがよろしいでしょうか？
> 名前は、「SmartHamLog」としたく考えています。

FBですね！
完成しましたら使わせていただきたいです。

iOS版 <-> PC版のデータの共有がカギだと思います。

期待してます！！

初めまして。
iPhone iPad版のHAMLOGを作ろうと思っていますがよろしいでしょうか？
名前は、「SmartHamLog」としたく考えています。

> 漢字の分断は、MS-DOSの時代からある問題なのですが、Windows版では
> すっかり忘れてました。漢字の分断は、
> ・ADIF出力時に修正
> ・QSOデータSave時に修正
> ・QSOデータのチェック機能に追加
>
> ということで対応します。

ありがとうございます。よろしくお願いします。

> なお、上に赤い字で記載のとおり、この件はHAMLOG BBS の方でお願いします。

失礼しました。以後そのように対応します

> eQSL.ccのボランティアサポートをしていますJH4PHW坂井です。

坂井さん、お久しぶりです。

漢字の分断は、MS-DOSの時代からある問題なのですが、Windows版では
すっかり忘れてました。漢字の分断は、
・ADIF出力時に修正
・QSOデータSave時に修正
・QSOデータのチェック機能に追加

ということで対応します。

なお、上に赤い字で記載のとおり、この件はHAMLOG BBS の方でお願いします。

eQSL.ccのボランティアサポートをしていますJH4PHW坂井です。

HamlogからADIF変換をしている方からの問い合わせで変換されたADIFを見せていただいたところ、の時に54バイト目からダブルバイトが始まる時にその直後のの左括弧を上書きし、処理ができなくなっていた例がありました。

53,54バイトの2バイトで処理をされているケースについては正しく処理がされているようです。54バイト目が英数字符号などかどうか判断して53バイトの出力にするなどの対応をお願いできませんでしょうか?

いろいろなところサイトでアップロードするもレコードの終わりが書いていないのでエラーとなり困っておられたようです。

ご検討をお願いします

> 要するに
> 送信文字列への変更が終わったらF12キーを押してください。
>
laoさん、お調べいただきありがとうございました。これで、安心して文字列の追加送信ができますわ。

長野さん、ありがとうございました。

> と細かく書きましたが、要するに
> 送信文字列への変更が終わったらF12キーを押してください。

長野さん、おはようございます。
マクロで送信中、文字を挿入して
F12キーを押して、止まることなく
送信できました。
有り難うございました。

ＰＳ
また　何もありませんが時間と・・・が
有れば関ハムに来てください。
お待ちしています。

第19回 関西アマチュア無線フェスティバル(KANHAM 2014)
2014年7月19日、7月20日の開催を予定しております。

ソースを眺めながらMMVARIで動作を確認しました。
１．マクロボタンを押すと、自動的に送信が始まり文字列が送信される。
　このとき、左上のマクロ文に<%RX>があればTX(F12)ボタンがReqRXボタンに変わる。
２．送信窓で文字列に変更を加えようとキーを押すと、文字が追加されると
　同時にReqRXボタンがRX(F12)ボタンに変わる。
３．文字の追加が終わったら、F12キーを押す。そうするとRX(F12)ボタンが
　ReqRXボタンに変わる。またカーソルは文末に移動する。
４．文末まで送信が終わると、自動的に送信が終わり受信に切り替わる。

仕様を推測するに、文字列に変更を加えるとその変更が終わったのかどうか
判断する術がなく、まずカーソルの位置まで送信する。
カーソルが途中にあるならまだ変更中かもしれないからです。
カーソルを文末まで移動させても、そこからまだ文字を追加するかどうか
判断できないので、文末まで送信が終わっても受信に切り替えない。
文字の追加などが終わった時点で、F12キーを押すことで変更が終わったことを
明示することにより、カーソルが文末に移動するとともに、文末まで送信が終われば受信に切り替わる。

と細かく書きましたが、要するに
送信文字列への変更が終わったらF12キーを押してください。


> 太田さん、、、よろしくお願いします。
> マクロ送信中に文字列を追加した時は、カーソルを文字列の一番最後まで移動すれば、追加した文字列も含めて旨く送信できますが、マクロの最後に<%RX>を書いていても、この<%RX>処理が何故か働かず、送信状態のままとなるので、あわててF12を押して送信を止めます。　<%RX>が働くようにしていただけるとありがたいのですが、、、よろしくです。