Annoying behavior of build 117

6 posts / 0 new
Last post
n3gb
Annoying behavior of build 117

I been building a new shack computer, with updating all of the software; new OS (openSUSE Tumbleweed), updated KDE, WSJT-X, Hamlib, and finally a new CQRLOG. I haven't tried out all of the changes in 117, but one is really annoying. I received a batch of cards via Buro, and as usual sorted them by date to update the log. But each time I log a card, the log goes back to the top! Then I have to go back to the date in the log I'm working on, and find the next one.

Please restore the old behavior, and don't move the log cursor unless I ask to.

oh1kh
Annoying behavior of build 117

Hi!
Please note that versions starting with (1xx) are my alpha development versions that may contain even serious errors.

Moving cursor over last logged qso when new qso is saved has been there for long. I almost would guess it is even in 2.6.0(001) source, but I am not sure if I am right.

I am using only lotw and eqsl, and no one has ever reported this before. There are 3 "modes" in new qso: new, view and edit qso.
I have feeling I did take account view and edit not moving cursor to last qso with them. But I will check that.

Cqrlog has many ways of use. I assume you are using qso list/edit qso to mark qsl. Is there some other way to do it?
As said I do not play with paper cards. I got enough them already in -80 and -90"s and so this is a gray area for me.

Please tell if you do use another method than qso list/edit to mark received qsls.
I will check that this function works only with saving new qso.
There it is needed when logging a contest or similar where you should see last qsos without actions.

Changes to (1xx) versions appear almost daily if I found something to change or add. But remember source can have also errors that come out after some days of use.

--
Saku
OH1KH

oh1kh
Annoying behavior of build 117

HI!

I made some tests.

I think you are using method QSo list/Edit QSO and then mark qsl as "Q".
In that case if "preferences/NewQSO/Refresh data after save QSO" is checked after qso is saved the cursor moves on last worked qso.
If it is not checked it stays on this qso.

BUT!

If you mark qsl this way the "QSL received date" is not updated. It stays empty.

There is second method that is not depended on "preferences/NewQSO/Refresh data after save QSO" setting:
QSO list/QSL/QSL Received
Even better is to use Ctrl+R keys when wanted qso is selected from qso list, it is faster than opening the menu.
When using that way also "QSL received date" is updated and cursor stays always on selected qso.

I think using this, or if you want to edit qso, uncheck "preferences/NewQSO/Refresh data after save QSO" are the ways.

BTW
"Help/Operation/QSL records"
says : All QSL operations must be done from the QSO list
There is also information how to mark QSL sent or received.

So it seems there is no need to modify source code.

Anyway, thanks for reporting.
Feedback is always welcome!

--
Saku
OH1KH

n3gb
Annoying behavior of build 117

Thanks for your comments, Saku.

1) I realize these builds are not official, and liable to break. As with all OSS, if it breaks I get to keep both pieces :-(
2) It wasn't like this in 2.5.2, or in the 2.5.2+ that I compiled just before 2.6.0 was tagged.
3) Yes, I am moving to the QSO in the QSO list and hitting F4. This allows me to add IOTA/DOK info, grid square, county/oblast/prefecture info, fix misspelling of Name/QTH, etc. Ctrl+R is not adequate for this.
4) Yes, I have "Preferences/NewQSO/Refresh data after save" checked. But this is not a NewQSO, so why should that have any effect?

What I want is for it to act just like an old-fashioned logbook; I can edit what I want, but it doesn't move unless I tell it to.

oh1kh
Annoying behavior of build 117

Hi!

I tested again this (with 117).
It actually should NOT move to topmost qso when qso is in edit:

if (cqrini.ReadBool('NewQSO','RefreshAfterSave', True) and frmMain.Showing) then
begin
frmMain.acRefresh.Execute;
if not fEditQso then <---------------Here if not in edit qso
frmMain.dbgrdMainKeyUp(nil,key,[ssCtrl]); //shows last logged qso
end;

I have to track why the "fEditQSO" is not true when qso was really in edit state.

I will fix this, if root reason is found. At the time I was adding that feature it really worked in way it should.

--
Saku
OH1KH

oh1kh
Annoying behavior of build 117

Hi!
I think I found something.
Please try (117) (version date 2023-07-10 "QsoList:Fix:Return cursor to last worked qso when saving edited Qso should not happen")

It should keep Qso list selected qso after save from edit qso even when "Refresh data after save" is checked.
When saving new qso it should move selection on latest (just saved) qso.

--
Saku
OH1KH