Contest window / QSO window synchronization bugs.

4 posts / 0 new
Last post
Contest window / QSO window synchronization bugs.

Much to my dismay, some time into the IARU HF contest, I found that quite a few QSOs had no information in the SRX_STRING aka MSG_R column whatsoever. Although I never saved any QSO without typing something in there. I also find it difficult to add such information to a QSO in retrospect.

I have been riding the bleeding edge and used a self-compiled recent cqrlog version (from Git SHA #9f7c328502) to log my participation in this weekend's IARU HF championship. I duly type "ITU region" info received into the MSG_R field in the contest window. I operate a rig that has not CAT, so I type the frequency into the new QSO window. (I had wanted to log precise QRG info, for no particular reason.) Depending which windows of those two I use to trigger the actual saving of the QSO to the database, the MSG_R info gets there (contest window) or does not (new QSO window).

In my opinion (and expectation), the "contest window" should act as if it were an extension of the QSO window. So I consider the non-storage of the MSG_R when the saving is triggered from the new QSO window a bug.

So now, I have some QSOs with missing MSG_R in my database. I open such a QSO, it gets displayed in the "edit QSO" window. The MSG_R field does not show up anywhere in that window. That does not concern me, I simply move over to the contest window and expect information and edit-ability to be available there. (It is still my opinion (and expectation) that the "contest window" should act as if it were an extension of the QSO window. So I should find the info of the QSO that I'm in the process of editing there, and I should not matter which window I use to do editing.) But I do not find QSO info in the contest window. I consider that as a bug as well.

Contest window / QSO window synchronization bugs.


First of all to you and all others who compiled latest version from source or install alphaTest binary:

Please make sure that you are installing and *reading* help files too!

Producing good, up to date, help section is a huge operation. I have tried to update always that part of help what the new property or fix concerns. I admit that there should be more (better) help sections. How ever some things to explain you notice only after received user comments/problems feedback.

Contest form (contest notepad) is a child form of new qso helping just access right columns fast, automate the serial numbering and offering a simple band+mode dupe chek.

Why? Why not completely new qso input window?

Simply for that reason that all routines are already written for new qso and so it is very easy to use contest form as filler of new qso columns and finally for triggering save qso.

That same concerns to N1MM remote and WSJT-X remote. They also fill new qso columns and then trigger the saving.

At the save phase first collected information from child process (contest from or remote) is transferred to new qso and then new qso save process is triggered.
It means that all this information overwrite existing values in new qso columns.

It is expected that user does not use new qso form for entering information when he/she uses contest form or N1MM or WSJT remotes.
Program can not guess what is the right information: From child process or entered to new qso.
With remotes we have some sort of lock in new qso, but it is only for the callsign. With contest form there is nothing.
Easiest way would have been to make new qso invisible while contest form or remotes are active. But that is not good as you can see some additional information from qrz/Hamqth while qso is going on (wsjt-remote) and with contest from there was not dupe check in first versions and then "show recent QSO recods for X days" at the top of new qso served as dupe check.

In edit qso mode contest message columns are visible and can be edited (that is in help) when
1) contest form is open and 2) new qso window is stretched horizontally (contest message columns are under dxcc info)


Programm architecture recommendation: Model and view separation.

Hi, Saku,

you say:

Program can not guess what is the right information: From child process or entered to new qso.

But there is a programming trick how programs can handle this nicely. If followed, no need for guessing remains. The trick is called "separation of model and view". I have used it with success in programs that I have written for my daytime job. If you can manage to introduce this to cqrlog, I recommend you do so. It will spare much pain.

Here is how that would work:

The QSO information exists in only one place (model datastructure).

There can be one or several windows (views). They all operate on the same model.

Whenever the user enters anything, it does not matter through which window. The data always is written to the same place: The single, unique model.

This happens immediately. Preferably: As the user types, on every single letter entered. Also possible: When the user moves on to the next input field with "tab" or something of that sort (technically, when the input field suffers "focus lost").

There is an "event" infrastructure in place. As they are created and closed, views (windows) register themselves with the single model. On any change that comes in from any one view, the model actively informs all of the views of that change. This information can be specific: "Frequency has changed" or so. Alternatively, it is easier, though slightly wasteful of CPU cycles, to just note all windows "something has changed", causing them to re-read the entire model and re-draw themselves. Either way, when the user enters anything in one window, the display changes consistently in all windows.

For all of this, it does not matter whether we talk about entry of a new QSO, or editing of an existing QSO. The logic is always consistent, always the same.

When the user orders "save" in any window, it is the model data that gets saved to the database.

Not sure whether this helps you. But I did want to mention this.

I speculate the present program has duplication of QSO data in several places, in code and data associated with the windows. (No time to actually dig into the code right now to check.)

If so, I am afraid that this architecture will cause pain to users. You already do something different from what normal users expect, and then ask them to wrap their mind around it, and read the documentation. That is an option, but not one I recommend.

And QSO data spread over several places will also cause pain to developers. In my fears, I see you adding lines and lines and lines of complicated code syncing stuff, that will always leave some gaps and some users puzzled. Or else, you'll add locking code. Locking code can be made to work reliably, but in effect creates modal windows. In my experience, users hate modal windows. (Personally, I certainly do.)

I hope this is helpful. If not, kindly ignore.

Vy 73, Andreas, dj3ei

Programm architecture recommendation: Model and view separation

Yes. You are right. But that simply needs complete rewriting of program.

I am not a programmer, it is just hobby. Actually cqrlog is my first try to learn Lazarus. And it is Petr's made, not mine. I'm just trying to clear it to myself and make some additions that I need for myself (with minimized code changes) and then share them for others too.

It would be nice to have more professional contributors, but it is understandable that they get enough of programming during daily job.