Log4OM

Yes, it's not in the release notes...
Copy data from previous QSO is only intended for the NAME field.
There is not a common logic that can be shared when you request to use "previous QSL SENT status"...

if you sent the QSL one month ago, no new QSL is required? or one year? and if you have received a QSL? for band? mode? and what about references (abbeys, IOTA, SOTA, ...)...
It's a bit too risky to assume the new QSL behaviour from previous contacts.

"i will check" was related to the CAT issue, that i'm unable to reproduce at this time (the issue is still open)

Ciao Daniele,
mni tnx for quick response.

A "user choice" to let the user decide whether or not to import the status of previous qsl would be great as not all of hams like awarding (IOTA, SOTA and so on).

My personal preference is to send a qsl card ONCE per station, but it seems to be only my problem and all other users are prefering different, so...it is OK! I will continue to check it by myself, no problem at all!!

OK abt the CAT issue, to check it will be enough to start Log4om while leaving RIG switched off hi hi

Thanks for the great work you all are doing for us.

Ciao Manuel,
everything is possible. If we keep the thing limited to something that is reproducible and "standard" it's ok.
But some logics are required.
QSL Sent status are 5

YES
NO
QUEUED
REQUESTED
INVALID

What status from previous QSL should be checked to have the current QSL set as NO? and if we have a REQUESTED (but presumably not sent?). And QUEUED is the same of YES?
Many variables make this thing a bit complex, but you can write down your proposal

I spent some time to download and check again how other sw manage qsling.
The major give you a chance in the option to set:

A) qsl EACH qso
B) qsl ONCE per qso
This is the key!

Option A is easy to understand. Let me try to evaluate case B.

Now, others are "poor" because they usually only have 2 conditions:
QSL SENT = Y or N (where Yes may also be: B(uro), E(lectronic), L(otw) and so on, but B,E,L are in any case the same as Y).
The same for QSL RECEIVED (By)

So if I set option B (qsl once per qso) the previous status (Y,B,E,L...) will be suggested if the station has already been worked. By this way when I qso for the second time with IW3HMH the qsl status is suggested (example) to B and I immediately know that QSL was already sent by Buro to Daniele and will not lose time, paper to write one more o to check whether or not it has been sent, this is also because I am used to write the card while qso.
Of course, qso with IW3HMH is not the same as 9M/IW3HMH.
This is also very usefull with their own "qsl management" or qsl report.

But...Log4om has 5 different status, and a different way of managing.
I suppose the field in the db refering to this 5 different status is the same one, well I am quite sure abt that so the status to be checked is not the status HI...but the field.
By this way I suppose the following:

Previous QSL Sent = NO -> Current QSL Sent = NO (not already qsled, don't want to? will do later for this one?.......)
Previous QSL Sent = YES -> Current QSL Sent = YES (already qsled, QSL Management will thanks)
Previous QSL Sent = QUEUED -> Current QSL Sent = YES (as I want to qsl once x station)
Previous QSL Sent = INVALID -> Current QSL Sent = INVALID (qsl invalid? lid operator? pirate?)
Previous QSL Sent = REQUESTED -> Current QSL Sent = YES (as I want to qsl once x station)

That only means that you immediately know the status of the previous qso and than decide whether or not to do something more or not and in all cases I will be able to set different if needed.

I think the key of anything is giving the chance to decide in the option if you want to qsl:

ONCE x QSO or ONCE per STATION ?

Beleave me, I will appreciate, but do not want to overcharge all of the team for something that will be usefull to only one person!
It is a great product and I will continue to use and suggest even without this chance!!