chat stops scrolling if window is unfocused

[soccer]

(v0.704) Any chat and status message window stops scrolling when it loses the focus.

[Pietry (pietry)]

This is not a bug. The chat stops scrolling so you can see the chat exactly from the point you left it.

[Fredrik Ullner (ullner)]

The question rather whether it can presented in a different manner... Eg, XChat display a red line.

[soccer (soccerle)]

I thought as much, that it could be rather a feature. It's kind of unfamiliar.

[poy (poy)]

well in our case the red line is the separation between the chat and the message box. and drawing red lines on top of an edit control may not be very easy...

some DC++ derivatives always scroll the chat, unless you uncheck an "auto-scrolling" option available when you right-click in the chat. what about it?

[Jacek Sieka (arnetheduck)]

I think it should be like this: if scroll bar is at bottom or caret is at end, it should scroll automatically, if not it should not scroll...regardless if it's in the foreground or not...

pre-smartwin dc++ did this and the code is PORT_ME-marked, but I'm not sure it was the best solution as to how to do it - it needs playing with...

[MikeJJ (mrmikejj)]

I've been looking into this, heh, and failing.
But the conclusion i came to is that it's the actual windows library which stops out of focus stuff being scrolled. As a result maybe best to make it so that when "onFocus" it scrolls to the bottom. ? (I did try using sending the EM_SCROLLCARET message after text had been added, but no joy).
(I couldn't work out how to use the onFocus() function from the Smartwin library, hence me failing at being able to provide a suggested patch).

Also i got a bit confused as where to put the stuff. Options being:
WidgetTextBoxBase, WidgetTextBox in smartwin, WidgetTextBox in win32 or HubFrame \ PrivateFrame.

[poy (poy)]

here is a patch that does what Jacek wrote previously: scroll only if the current scroll position is at the end.
instead of porting the WTL code that checked the position of the last character to see if it was in the rect of the last line, i used ::GetScrollInfo which seems like a cleaner way to find out the scroll position.
the scrolling is still disabled using WM_SETREDRAW messages; ::SetScrollInfo could have been used but it seems much easier to just disable redrawing since that works...

MikeJJ: you would have added something like chat->onFocus(std::tr1::bind(&HubFrame::handleChatFocus, this)); in the HubFrame constructor and then a function void HubFrame::handleChatFocus() that would have been called when the chat got focus. there's an example in HubListsDlg.

[MikeJJ (mrmikejj)]

Thanks poy, that kind of helped. :)
It allowed me to write a patch which looked like it should work. heh but didn't, so then i figured it was because it's not when the "chat" gets focus, it's the whole window, so i tried again and failed again. :P

So i added this
 void HubListsDlg::handleFocus() {
+dcdebug("hublist dlg focus");
  editBox->setFocus();
 }
and it never got called either. Is onFocus() broke in Smartwin ?

If so, the attached patch "should" work, if it is onFocus() which is broke. If it's just me being crap, ignore it. :)
(This it to be used in conjunction with Poy's patch, btw :))

[poy (poy)]

if i scroll a chat window up, change windows, come back (so i focus the HubFrame window again), i expect the scroll position to be the same, not to have auto-scrolled to the end as in your patch.
however, if the scroll position was already at the end, then my patch will make the chat control scroll everytime, regardless of what the current focused window is.
in short, i don't think scrolling on focus would be needed (and in the first case, it would even be disturbing).

about the onFocus thing, it looks fine in SmartWin so i would say that it's Windows that isn't sending WM_SETFOCUS messages; that will need checking...

[MikeJJ (mrmikejj)]

Ahh, i see what you mean. When tested though you patch it stopped the scrolling when the window was in focus and the scroll bar wasn't at the bottom, but when out of focus it exhibits the same behaviour as before (never scrolling).
As i said earlier "the conclusion i came to is that it's the actual windows library which stops out of focus stuff being scrolled."
So maybe make a boolean variable for remembering if the scoll is at bottom, when window looses focus.
If at bottom, scroll on focus. If not just don't do anything, and windows will stop it from scrolling ? :)

[poy (poy)]

you're right, it didn't scroll when the chat window didn't have focus. to solve it i added a WM_VSCROLL message in the addChat functions to force the chat control to scroll even when it doesn't have focus. should work fine now.

[MikeJJ (mrmikejj)]

That's much better poy. Should Systemlog also get this fix. ?
Also on a side note, it still fails rarely in HubFrame, though it's kind of hard to spot when. But i think it's onConnecting to a new hub (e.g. at startup autoconnect to many) when it's out of focus, and the MOTD is bigger than the amount of text you can view. I might be wrong on that analysis though, just initial observation. Maybe before a scroll option is available, and the text added is larger than the amount you can view.

[poy (poy)]

this 4th patch is the same as the 3rd one except that it adds the scroll fix into SystemFrame, too.

regarding scrolling failing on auto-connect or with big MOTDs, i tried to add a hub that sends a MOTD with lots of lines (tried with 1 hundred...) in favs, set it to auto-connect before or after other hubs (so it wouldn't have focus when opened) and it always scrolled fine to the last line...
if this happens to you quite often, you could try to add some debug info on variables used there (scroll, scrollInfo.nPos, scrollInfo.nMax, scrollInfo.nPage) with either printf/dcdebug if you run in debug mode or the LogManager LOG macro if you run in release mode. so when it happens, you can take a look at the values and see if there's anything particular...

[MikeJJ (mrmikejj)]

Hope this helps. Looks like it's trying to scroll, but sommit going wrong.
[19:12:49] scroll 1 scrollInfo.nPos 0 scrollInfo.nMax 0 scrollInfo.nPage 1
[19:12:49] scroll 1 scrollInfo.nPos 0 scrollInfo.nMax 1 scrollInfo.nPage 2
[19:12:54] scroll 1 scrollInfo.nPos 0 scrollInfo.nMax 2 scrollInfo.nPage 3
[19:12:59] scroll 1 scrollInfo.nPos 0 scrollInfo.nMax 3 scrollInfo.nPage 4
[19:13:02] scroll 1 scrollInfo.nPos 0 scrollInfo.nMax 4 scrollInfo.nPage 5
[19:13:02] scroll 1 scrollInfo.nPos 45 scrollInfo.nMax 69 scrollInfo.nPage 25 <----- scroll stops here, end of motd
[19:13:04] scroll 1 scrollInfo.nPos 46 scrollInfo.nMax 70 scrollInfo.nPage 25 <----- extra line from hub bots
[19:13:04] scroll 1 scrollInfo.nPos 47 scrollInfo.nMax 71 scrollInfo.nPage 25 <----- fully connected here, extra line from hub bots

[19:14:50] scroll 1 scrollInfo.nPos 51 scrollInfo.nMax 75 scrollInfo.nPage 25 <----- someone typed sommit in hub here
[19:15:30] scroll 0 scrollInfo.nPos 55 scrollInfo.nMax 79 scrollInfo.nPage 24 <----- i put hub in focus and typed something here

[Jacek Sieka (arnetheduck)]

I committed this but it would be nice if the getscrollinfo bit was c++ified and moved to smartwin to avoid some code duplication...

[poy (poy)]

thanks Mike, that helped. :)
in your log, "scroll" is always set to true except when nPage changes from 25 to 24. nPage shouldn't change since it's the number of lines the edit control can display; unless the height of the edit control has been reduced by 1. that actually happens on auto-connect when new hub windows open and the tab rows grow... so i've added a WM_VSCROLL message in layout().

Jacek: i've put it in AspectScrollable.

[Fredrik (fffredde)]

Isn't it possible to get a "don't scroll if unfocused" option? :3
That's much more awesome than autoscrollng. This is the only real thing that has bothered me since i updated to a newer version.