QSL Sent Status

[dl2ki]

If after a QSO in the tab "Details" the "QSL Sent Status" was changed to e.g. "Paper Yes", this status remains, even if the callsign field is empty or another callsign is entered there.

This effect leads to incorrect entries in the database if you do not reset the QSL Sent Status manually after saving the QSO. It may be that this effect also affects other selection fields.

[foldynl]

unfortunately, this is a desired functionality. I thought it would be more natural to leave the last value rather than returning it to some predefined (default) value after each QSO.

It is possible that an operator does not want to send QSL, so he/she fills 'No' and will not want to return the default value after every QSO. That is why I implemented that the last value is remembered after every QSO.

Do you think that my thinking is wrong?

it is very easy to change, but on the other hand it raises questions: 1) what will be the default value? 2) what will the operator do if she/he wants to enter a different value than the default one? As you know me, I don't think there should be any special settings for that in Settings.

[dl2ki]

Yes, you can do it that way.

Since I send QSL cards for already worked callsigns only if it is new band/mode, the default for me would be "No". For new QSO's it depends if the OM wants a QSL via office. In rare cases I send Paper-QSL cards also directly.

For LoTW my default would be "No" because I don't use LoTW and eQSL would be "Queued" because I upload the new QSO's to eQSL regularly.

But since this can be individually different, it is certainly difficult to please everyone. From my point of view it is more likely that the operator decides after each QSO whether to send a paper QSL or not. A natural part of this decision would then be to actively set the QSL status to "Yes".

But you can also leave it like this. In the future I will then consider this and reset the menus after each QSO. Since I noticed the "feature" a bit late, I reset the corresponding entries in the database.

It might be useful to have a hint in the tooltip window or even in the wiki, so that the user can take these properties into account.

Otherwise one could orient oneself at other logbook programs.

From my point of view, such specifications in programs are always problematic because they cannot cover all needs. One could also display the selection field for paper QSL as an empty field, so that the user does not see a default, but can make the selection himself.

LoTW and eQAL are special cases, because the upload here will surely be automatic once.

[foldynl]

QSL sent field is ltricky. Based on ADIF specification, if the field is empty then its default value is 'N'. It is also important to note that, this field has values defined in ADIF https://www.adif.org/314/ADIF_314.htm#QSLSent_Enumeration where in my opinion all values except 'Y' can be used for a new QSO.

Comboboxes have tooltips where the values and their meanings are described.

You are right that the functionality of "remembering" the last state is not described anywhere. I should work on that.

[dl2ki]

There are, as everywhere, certainly different points of view.

That's another one of those questions where a broader discussion would be helpful. I think you will find a good solution here. I just put a request in the mailing list once, hoping that more people in the list will get in touch, hi.

From my point of view the fields "LoTW" and "eQSL" can be preset with "Cueued" without any problems. The user has set up these variants in the "Sync & QSL" settings. Thus it is to be assumed that the user wants to upload the QSO's over these platforms. It makes also no sense to upload here only certain QSO's. Therefore, one can assume in practice that the user wants to upload all QSO's via "LoTW" and "eQSL".

With paper QSL's this looks different. Here it is not to be assumed that for each QSO always a paper QSL is to be sent. It can be that the QSO partner already has a QSL card for the band/mode. Many stations do not want paper QSL cards (e.g. DX stations), other stations do not participate in QSL card shipping, or note on QRZ.com that they do not collect QSL cards.

Therefore, from my point of view, sending paper QSL cards is not an automatism, but a conscious active decision. This would include that also the "QSL Send Status" for paper QSL has to be actively set from "No" to "Yes".

It is also unlikely with paper QSL cards that a previously set value (no matter which) is always valid for the next QSO. Therefore, from my point of view, the default "No" would be more reasonable and more likely for paper QSL cards.

However, I currently have no overview of how this is handled in other logbook programs.

But, as I said, I personally can also adjust to other defaults. It would only be important to point out program defaults in selection fields or generally separately in the wiki, so that a new user can take this into account.

[foldynl]

That's another one of those questions where a broader discussion would be helpful. I think you will find a good solution here. I just put a request in the mailing list once, hoping that more people in the list will get in touch, hi.

Good idea but we will see if someone answers. There are not many people.

From my point of view the fields "LoTW" and "eQSL" can be preset with "Cueued" without any problems. The user has set up these variants in the "Sync & QSL" settings. Thus it is to be assumed that the user wants to upload the QSO's over these platforms. It makes also no sense to upload here only certain QSO's. Therefore, one can assume in practice that the user wants to upload all QSO's via "LoTW" and "eQSL".

yeah, I agree with you.

With paper QSL's this looks different. Here it is not to be assumed that for each QSO always a paper QSL is to be sent. It can be that the QSO partner already has a QSL card for the band/mode. Many stations do not want paper QSL cards (e.g. DX stations), other stations do not participate in QSL card shipping, or note on QRZ.com that they do not collect QSL cards.

Therefore, from my point of view, sending paper QSL cards is not an automatism, but a conscious active decision. This would include that also the "QSL Send Status" for paper QSL has to be actively set from "No" to "Yes".

I partially agree with you. The paper QSL Sent Status is different from e-QSL Statuses. But I can image that status will be "No" and an operator actively change it to 'Queued' - keep in mind that 'Yes'-state means that you already sent the QSL. 'Queue' means that you will send the QSL in the near future.

It is also unlikely with paper QSL cards that a previously set value (no matter which) is always valid for the next QSO. Therefore, from my point of view, the default "No" would be more reasonable and more likely for paper QSL cards.

Yes, it makes sense. Everything makes sense even in this situation. "QSL Sent" field will always have default values Lotw&eQSL = Queued, Paper = No. Then you can find an operator who mostly does not send his QSO to eQSL, so eQSL= 'N' will be more useful for him. Just for this case, when I don't want to introduce new settings, I implemented a function where the last state is remembered, which is then used in other connections. If I will implement the function that after each QSO the Paper status returns to 'N', I have to implement the same functionality for eQSL and LotW fields as well, otherwise it would be confusing for operators.

However, I currently have no overview of how this is handled in other logbook programs.

I did research and it is mostly solved by having a tab in the main setting where you can choose what the default value is.

[dl2ki]

I partially agree with you. The paper QSL Sent Status is different from e-QSL Statuses. But I can image that status will be "No" and an operator actively change it to 'Queued' - keep in mind that 'Yes'-state means that you already sent the QSL. 'Queue' means that you will send the QSL in the near future.

Let's move from the theoretical to the practical.

Here it is so that I write paper QSL cards directly after the QSO and collect these here. At the same time I change the QSL send status to "yes". At the next opportunity I then hand in the collected QSL cards in the local club for sending. If I mark the QSO's first with "Cueued", I would have to change then yes all markings again.

"Cueued" could possibly be used by the person who after some time uses this marker to automatically print a number of QSL cards and then automatically set the field to "Yes". This would be a functionality later that could be implemented.

But this is all depending on the individual way of working. I'll wait and see what you decide. You could otherwise discuss it for a very long time, hi.

[foldynl]

So in this case it makes perfect sense to me. Yes is correct in this case.

[dl2ki]

Yes, but only if paper QSL cards are issued for all QSO's in a row. I'll close this one now, though. There are certainly more important things to solve, hi.