Rx pane scroll bar fix#309
Conversation
start and save the scroll bar position on settings reload
punk-kaos
left a comment
There was a problem hiding this comment.
Looks clean and simple to me.
|
While this works, I wish I could figure out the mechanism that causes the behavior. Accepting settings triggers a lot of UI work: displayActivity(true), setupJS8(), enable_DXCC_entity, etc..... The history in textEditRX is loaded from a HTML string in JS8Call.ini so it actually repopulates that pane when the settings are accepted with OK. But why it jumps back to a certain place in time when it is reloaded by accepting settings remains a mystery. In theory, when the program is started it should do the same thing, but doesn't. It sets the scroll bar to the top at the very beginning of the log instead of at that point in time that accepting settings moves it to. I could find nowhere in the code in either path that explicitly tell that text pane to scroll anywhere except in some conditions like writeNoticeTextToUI() and those don't run on a settings save. So it has to be some quirk in Qt doing it, which makes it not a bug in our code. And like @Joe-K0OG noted where he can't duplicate it, if I clear that incoming pane, let it load up with "normal" stuff it won't do it. But if I let it collect several days worth of stuff, then it starts happening. Like right now, in v3.0.2, starting with scroll bar at the bottom, open Preference, click OK and it jumps back to this exact point in time, every time, which was about 3 or 4 days ago. 
So obviously, to jump back to that exact point every time, means something here is being cached SOMEWHERE. But where? I'm not using ALL or DIRECTED.txt so it's not coming from there. The js8call_wisdom.dat appears to store some fftw stuff and I don't think it's coming from there. It could be coming from JS8Call.ini but I can't identify what key it would come from. So as far as I can tell, what causes it is good for an episode of Unsolved Mysteries on TV. |
Joe-K0OG
left a comment
There was a problem hiding this comment.
@Chris-AC9KH I tested your patch on both Linux and Windows, and it does not cause any problem that I can find. Of course, I didn't observe the scroll-back problem to begin with, and I still don't, so it seems your fix is at worst harmless, and at best fixes a real problem I just can't observe. You mentioned that you see it after a few days' operation. I NEVER leave my station on-air when I'm not present (at least in the house and pass by it occasionally), so don't have days-worth of RX Text to scroll through, only a few hours at most.
So, it seems good to me.
|
I'll merge this. I been running it for a couple days with no issues at all. |
Force Rx pane scroll bar to the bottom on program start and save the scroll bar position on settings reload.
This fixes an issue noted on the forum where when the Settings dialog is opened and click OK, the scrollbar in the Rx pane will jump back to a certain position in time. I thought this was coming from reloading the settings in JS8Call.ini but I was wrong. I never did find the actual call site that is triggering this. And it does not happen all the time but I also did not figure out the exact set of parameters that sets it off. It appears to happen when there is a variety of ACK's, maybe a directed or two, possibly mixed in with some MSG's you have gotten? Who knows? I only know that it does happen and it started doing that this afternoon. So this is a good opportunity to see if I can fix it.
Since this is not a bug, it is perfectly normal from Qt's standpoint and maybe they even consider it a "feature", and I could not identify the exact mechanism that causes it, I took the easy way out:
It works, even though it was not quite the type of "fix" I had envisioned.
Fixes #302