=Архив= LogHX: Аппаратный журнал любительской радиостанции, тема №2

[RX4HX]

LogHX - программа аппаратного журнала любительской радиостанции с большими возможностями настройки "под себя".

Вложение 244265


Сайт программы: RX4HX

Помощь по программе: Ссылка --> Начальная страница

Ссылка --> на файл Whatsnew.txt с информацией о последних обновлениях в релизе:

Ссылка --> Актуальные релизы и история изменений.

Канал на Youtube Сергея RD9CX: LogHX

База дипломов - >> Вложение 262565

Уважаемые друзья!
В связи с большой загрузкой по работе отвечать на личные письма и телефонные звонки возможности нет!
Просьба все вопросы и предложения писать на форуме QRZ.RU
Спасибо за понимание!

[RX4HX]

перезапись подгруженных самостоятельно файлов

Обязательно сделаю - т.к. сейчас сделано - это не верно. Нужно только решить как лучше это сделать... Тут нужно чтоб и от меня файлы обновленные приходили, и то что есть у пользователя не затиралось.

перезаписать старый файл в датабазе

Вопрос: перезаписать или добавить новых пользователей? Или на выбор - так наверное правильно.

[RD9CX]

Вопрос: перезаписать или добавить новых пользователей? Или на выбор - так наверное правильно.

Перезаписывать !!! Однозначно !!!!
К примеру я не добавляю к старому файлу новых членов, которые появились уже позже последнего обновления.
Я делаю опять полный копипаст с сайта клуба. Думаю это очевидно Так-как часто меняются позывные на новые, укороченные... плюс к этому запросто получают контестпозывные и они в клубах будут числятся под теми же номерами, что и личные.
В общем есть большая вероятность, что уже в первой сотне могут быть изменения.
Так-что перезапись должна быть однозначно.

На счёт того, что Добавить или Обновить не суть важно. Тут главное алгоритм...
Если такого клуба ещё нет у пользователя, то разумней будет "Добавить членов клуба", как оно сейчас и есть. Тут и презаписывать ничего не надо ))
Если Обновить, то можно и через Добавить (чтоб лишнюю ссылку не плодить) Но тогда он уже должен перезаписать старый файл.
И если исходить из того, что у некоторых пользователей могут быть затруднения, то разумней ниже добавить ссылку "Обновить Членов клуба"

з.ы.
Алексей. На мой взгляд в лог вшивать датабазу по клубам вредно.
Например обновлю я через неделю-две какой нибудь клуб, то старый файл вшитый Вами в датабазу нужно будет удалить.
Или Вы сделаете так, что при "Обновить членов клуба" он перезапишется ????
...но тогда нужно точно знать имя файла под каким он лежит у Вас в датабазе !!!
Например у Вас лежит под именем RU-QRP.txt
Пользователь не зная создаст свой под именем RUQRP.txt
то в оконцовке получим дубль в окне "Членство в клубах".
Да и формат файла может не совпадать !!!! У Вас 134.UA9AAA , а кто-то сделает без "точки" но через пробел 134 UA9AAA
......в общем создаст вшитая датабаза подводные камни ...пить дать )))

[RX4HX]

И так, я придумал алгоритм: в логе изначально базы будут в файле Databese. При запуске лога будет создана UserDatabase (если она еще не существует), куда будут перенесены следующие базы:

членство в клубах
локаторы для позывных
QSL via
RDA для позывных

справочные данные как были централизованы - так и останутся.

После этого файл UsersDatabase уже не будет перезаписываться.
В случае необходимости будет ф-ция копирования новых данных из таблиц в централизованной базе Database в локальную базу UsersDatabase.
Как такой алгоритм?

[4Z5CP]

А почему не может быть база данных для каждой категории, зачем 4 вместе обьеденять?

[RD9CX]

Как такой алгоритм?

Можно попробовать и такой алгоритм, а там видно будет

[RX4HX]

А почему не может быть база данных для каждой категории, зачем 4 вместе обьеденять

Размер 4-х баз большой получается. Можно конечно каждую таблицу в отдельную базу засунуть, только зачем? Лучше все пользовательские таблицы хранятся физически в одной базе (одном файле).

[RX1AG]

куда будут перенесены следующие базы:

членство в клубах
локаторы для позывных
QSL via
RDA для позывных

справочные данные как были централизованы - так и останутся.

Основные нужные данные в этом наборе присутствуют. Так, будет лучше, нежели сейчас... Самое главное, нужно предусмотреть, чтоб UserDatabase не удалялась при обновлениии и возможность самостоятельной коррекции по необходимости

[UR7TT]

В связке с JTDX не всегда пишется в лог adif band, частота всегда нормально. Закономерности не нашел.

[4Z5CP]

Можно конечно каждую таблицу в отдельную базу засунуть, только зачем?

Что бы если одна база крякнется, остальные остались, да и редактировать удобнее.
Хотя, вам программистам, виднее.

[R2PU]

Release build_375
Добавлена возможность сохранять QSO сразу на eQSL

Release build_376
в установках для eQSL добавлена графа QSLMSG;

build_376 установленный "начисто" (перед установкой удалена предыдущая версия и все файлы от неё) .

При активации автоотправки на eQSL - QSO появляется на eQSL (т.е. автоотправка работает) , НО :
1) QSLMSG не проходит на eQSL (в графе комментариев на eQSL пусто)
2) в папке LogHX\eQSLUploads не записывается файл с данными отправки
3) в колонке eQSLS лога не появляется галочка (QSO не отмечается в логе как выгруженное на eQSL)

Но п1-п3 работают при "ручной" отправке по старому методу , в т.ч. работает и новый функционал по отправке графы QSLMSG (ещё бы видеть её содержимое непосредственно в отдельной колонке лога и окнах ввода\редактирования QSO- совсем цены бы не было этому функционалу)
Т.е. что-то не очень работает пока именно в автоотправке (от греха пока отключил её)

+ К этому если сравнить лаконично-функциональное окно информации об отправке в ручном режиме с окном информации при активированной автоотправке - то сравнение явно не в пользу последнего (впрочем дело вкуса).

Алексей , можно проверить п1-п3 именно при автоотправке ? (может это вообще проявляется только у меня .... всякое бывает).
Если надо более точное описание (со скринами и тестовыми QSO во всех вариантах) - то без проблем )))).

[UD7G]

Сообщение от RX4HX
Release build_375
Добавлена возможность сохранять QSO сразу на eQSL

Алексей, привет!
Заметил, что у меня не отправляются связи на EQSL не только в автоматическом, но и в ручном режиме, причем, ещё со старых версий. Поэтому применяю JTAlert, который выполняет эту процедуру без проблем, но ведь это только в цифре. Заметил, что файлы adif от JTAlert и LogHx отличаются и по объёму и по содержанию. Если надо, могу показать их листинг здесь.

[RV9UDO]

может это вообще проявляется только у меня ....

Нет, не только.
У меня тоже самое.

[RW6APC]

Нет, не только.
У меня тоже самое.

У меня тоже самое

[R1BET]

С некоторого времени (заметил в начале декабря) стал творится какой-то винегрет с приемом и отправкой связей через eQSL. То ушедшие судя по loghx от меня подтверждения корреспонденты не видят, то у меня в инбоксе лежит подтверждение, которое даже загружается при синхронизации через loghx, но при этом поле приема в логе не заполняется и оно так и продолжает валяться в инбоксе - вполне возможно я что-то делаю не так, буду благодарен за советы. Попробую показать на примере.

16.12.2017 провел несколько связей. Через Файл->eQSL->Загрузить QSO на eSQL без всяких ошибок загрузил их на eqsl. В колонке eQSLS проставился чекбокс, в аутбоксе на eqsl.cc все связи эти появились, все ок.

Внезапно сегодня по емаилу получаю от одного из корреспондентов 16.12.2017 (UA1AQC) email с просьбой подтвердить QSO через eQSL.

На eqsl.cc в инбоксе лежат две связи за 16.12.2017 от UA1AQC и R1CAV. Делаю Файл->eQSL->Скачать журнал, выставляю дату 16.12.2017 и "Download and syncronize" и ...
ничего не происходит (adif вот такой: https://www.dropbox.com/s/wvxbp7p851...-2017.adi?dl=0). Повторяю несколько раз, ставится чекбокс в поле eQSLR для связи с R1CAV но при этом сама связь так и продолжается валяться в инбоксе на eqsl.cc. При этом для связи с UA1AQC чекбокс eQSLR не ставится, но при этом эта связь из инбокса eqsl.cc переносится в архив как подтвержденная с двух сторон.

[R7AB]

Добрый день!

Сегодня заметил , что у меня поле MODE заменилось на поле USER1 . В меню "настройки колонок" ставлю поле MODE , а в логе появляется поле USER1 и наоборот.
Это у только у меня такое ?

Александр, R7AB