LOTW upload Probleme

[DL6ER]

Hallo zusammen,

ich habe vorhin eine sehr ausführliche E-Mail erhalten. Ich fasse hier das Wichtigste zusammen:

• Der eigentliche Grund, warum als Standard-Aktion nun der Editor und nicht das Signieren aufgerufen wird, soll darin liegen, dass das bisherige Verhalten nicht konform mit den "OSX user interface guidelines" war.
• Die Änderung sei seit ca einem halben Jahr aktiver Diskussionsgegenstand auf der LoTW und TQSL-Mailingliste gewesen und viele Logbuchautoren hätten sich beteiligt. Die aktuelle Version ist ein Mehrheitsentscheid gewesen. Alpha/Beta-Versionen hätten sich bereits seit Sommer so verhalten (natürlich hat sie sich keiner von uns angeschaut).
• "-x" sei schon lange vorhanden (i.e. wohl mindestens seit v1.4) und sei seit jeher die empfohlene Variante gewesen, da man TQSL dann aus seinem Logbuch-Programm verwenden kann und TQSL nur ein Minimum an eigenen Fenstern zeigt, "so the log signing is quietly done - including upload - transparent to the user".
• "Invocation Examples" auf der Dokumentationsseite, verwendet ebenfalls "-x".
• Ein Grund wieso die Dokumentation nicht aktualisiert wurde, nannte er nicht. Der Grund ist also möglicherweise eine zu-viele-Köche-verderben-den-Brei-Sache.

Zusammenfassung:

1. Es wird sich nicht wieder zurück ändern.
2. Ich werde mich in der TQSL-Mailingliste eintragen und etwaige, neu aufkommende Probleme dann frühzeitig hier melden.

73 und einen schönen Sonntag,
Dominik

[DL7UCX]

Hallo Dominik,

danke für Deine Erläuterungen und Aktivitäten.

Ich hatte ja keine Ahnung, welche Diskussionen ein so einfaches Progrämmchen erfordert
Wenn da schon die Logbuch-Autoren der ganzen Welt mitmachen, werden die TQSL-Schnittstellen hoffentlich auch bei TTIP nicht vergessen
Dafür braucht man natürlich viele Entwickler, da kann ich nicht mithalten

Ich gehe dann davon aus, daß es mit UcxLog 7.53 Beta 8 nun wieder einfach funktioniert, solange TQSL nicht erneut verschlimmbessert wird

73 Ben

[DF2LH]

Moin moin!

Vielen Dank für Eure ganze Mühe!

Hier das Ergebnis meines Versuchs einen UCXLog/TQSL Upload auf einem 'jungfräulichen' PC zu starten. Das gesicherte .p12 Zertifikat in TQSL geladen und einen QSL Upload von UCXLog aus versucht. Klappte (natürlich ) nicht, denn ich habe meine 'Station Location' nicht neu eingegeben. TQSL meldet das Fehlen des Eintrags beim Aufruf über UCXLog nicht und tut einfach nichts. Beim händischen Upload über die TQSL Benutzeroberfläche bekommt man dann einen Hinweis und kann die Daten eintragen. Wie immer RTFM..

'73s und schööne Woche!

Thomas

[DL6ER]

TQSL meldet das Fehlen des Eintrags beim Aufruf über UCXLog nicht und tut einfach nichts.

Ein weiterer Blick in den Quellcode von TQSL zeigt, dass wenn Du keine Location ausgewählt hast (was ja in dem Fall nicht ging), sich TQSL folgendermaßen verabschiedet:

Code: Alles auswählen

exitNow(TQSL_EXIT_CANCEL, quiet);

TQSL_EXIT_CANCEL führt daraufhin zum Abbruch mit der Ausgabe: "User Cancelled"
(nicht getestet)

Möglicherweise kann Ben noch eine Erkennung einbauen, ob sich TQSL mit "Success" zurückgemeldet hat und anderenfalls eine Warnmeldung ausgeben.

73 Dominik

[DL6ER]

Hallo zusammen,

ich habe gerade eine weitere, weiter ausführende Antwort erhalten. Insbesondere die Antwort auf meine Frage, ob "-x" für irgendeine Version schädlich sein könnte:

Using "-x" when signing a log will work with no side effects for any version of TQSL from 1.13 onward.

Das sollte also in allen Versionen kein Problem sein.

73 Dominik

[DL7UCX]

Hallo,

das wird immer konfuser...

Ich dachte jetzt erst, es darf in UcxLog die Angabe der Location nicht mehr leer bleiben.
Das ist aber nicht so, wie früher öffnet TQSL dann die Auswahlliste der Locations und alles ist ok.

Dann habe ich das verstanden:
Die Location-Liste in TQSL war noch völlig leer.
In dem Fall verhält sich TQSL dank des jetzt erforderlichen Parameters -x (wirklich "no side effect" ???) anscheinend plötzlich doch wie im "Batch Mode" zu erwarten.
Da hat wohl einer der Entwickler gegoogelt, was Batch Mode üblicherweise bedeutet

Die Abfrage des Exit-Codes des TQSL-Prozesses durch UcxLog ist prinzipiell möglich, es darf dort nur nicht endlos hängenbleiben, bis TQSL beendet ist.
Der Exit-Code ist nur eine Zahl, die in TQSL gesetzt wird.
Ich vermute, SUCCESS ist 0 ?
Wie groß ist TQSL_EXIT_CANCEL ?
Was soll ich da als Warnung anzeigen, so daß es dem UcxLog-Nutzer weiterhilft ?
Ist TQSL_EXIT_CANCEL oder "User cancelled" besser als nur die kommentarlose TQSL-Beendigung ?

73 Ben

[dl8dww]

Hallo,

in Version 7.53 Beta 8 habe ich den "Work around" eingebaut.
Wenn noch jemand TQSL 2.0... verwendet, bitte ich um Rückmeldung, ob das auch damit funktioniert.

Ansonsten versuche ich weiter, mir NICHT diese Art der "Nutzerbetreuung" à la ARRL zu eigen zu machen.

73 Ben

kein Problem bei TQSL 2.0.3

73 Wolfgang

[DL7UCX]

Danke Wolfgang,

das hatte ich so gehofft.
Es war sehr clever von Dir, TQSL nicht ohne Not zu updaten.

73 Ben

[DL6ER]

Hallo Ben,

Der Exit-Code ist nur eine Zahl, die in TQSL gesetzt wird.
Ich vermute, SUCCESS ist 0 ?
Wie groß ist TQSL_EXIT_CANCEL ?

aus dem Quellcode:

Code: Alles auswählen

// Exit codes
enum {
	TQSL_EXIT_SUCCESS = 0,
	TQSL_EXIT_CANCEL = 1,
	TQSL_EXIT_REJECTED = 2,
	TQSL_EXIT_UNEXP_RESP = 3,
	TQSL_EXIT_TQSL_ERROR = 4,
	TQSL_EXIT_LIB_ERROR = 5,
	TQSL_EXIT_ERR_OPEN_INPUT = 6,
	TQSL_EXIT_ERR_OPEN_OUTPUT = 7,
	TQSL_EXIT_NO_QSOS = 8,
	TQSL_EXIT_QSOS_SUPPRESSED = 9,
	TQSL_EXIT_COMMAND_ERROR = 10,
	TQSL_EXIT_CONNECTION_FAILED = 11,
	TQSL_EXIT_UNKNOWN = 12,
	TQSL_EXIT_BUSY = 13
};

Die Beschreibung der Exit-Codes hat die gleiche Reihenfolge:

Code: Alles auswählen

	const char *errors[] = { __("Success"),
				 __("User Cancelled"),
				 __("Upload Rejected"),
				 __("Unexpected LoTW Response"),
				 __("TQSL Error"),
				 __("TQSLLib Error"),
				 __("Error opening input file"),
				 __("Error opening output file"),
				 __("No QSOs written"),
				 __("Some QSOs suppressed"),
				 __("Command Syntax Error"),
				 __("LoTW Connection Failed"),
				 __("Unknown"),
				 __("The duplicates database is locked")
				};

Was soll ich da als Warnung anzeigen, so daß es dem UcxLog-Nutzer weiterhilft ?
Ist TQSL_EXIT_CANCEL oder "User cancelled" besser als nur die kommentarlose TQSL-Beendigung ?

Damit es kein unendlich langer Text wird, der mögliche Fehler auflistet, kannst Du dem User vielleicht mitteilen, dass das Signieren nicht erfolgreich war und er zur Problemlösung versuchen soll die ADIF-Datei manuell mit TQSL zu verarbeiten.
Die meisten anderen Fehlercodes sind dann eher offensichtlich (wie z.B. "LoTW Connection Failed") und das könntest Du auch an den User weiterleiten.

73 Dominik

[DF2LH]

Moin, eine kurze Meldung wie:

Your LOTW QSL upload could not be signed by TQSL.
Please start TQSL.exe and try to sign and upload your file: \User\tom\documents\UCXLog\Log\df2lh_upload.adi by hand.

Den Filenamen habe ich mir eben ausgedacht, sorry bin im qrl Einen Hinweis welches File aktuell genutzt werden soll finde ich hilfreich.

Thomas

[DL6ER]

Hallo zusammen,

die heute noch verfügbar werdende Version 2.1.3 kehrt nach regen Diskussionen zwischen mir und dem Chef-Entwickler wieder zum ursprünglichen Verhalten zurück (nicht ADIF-Editor starten, sondern Log signieren). Somit verhalten sich auch ältere UcxLog-Versionen wieder korrekt mit der aktuellen TQSL-Version.

Sie halten sich aber offen irgendwann in "fernerer Zukunft" das Verhalten wieder zu ändern. Daher sollte UcxLog TQSL in allen (auch älteren) Versionen immer mit "-x" starten um sich auch in Zukunft Probleme vom Hals zu halten (Empfehlung/Anweisung der Entwickler).

73 Dominik

[DL7UCX]

Hallo Dominik,

dann ändere ich also erstmal nichts.
Ob die Auswertung des unspezifischen (nichtssagenden) Rückgabewerts von TQSL wirklich etwas bringt, überlege ich noch ...

Bei den TQSL-Entwicklern würde es ja schon reichen, wenn sie ihre eigene, veröffentlichte Beschreibung der Start-Parameter einhalten oder wenigstens updaten.

73 aus Wien
Ben