TabSRMM: if you scrolled up the chat log and new msg arives - don't autoscroll to the bottom

[GoogleCodeExporter]

IIRC, before there was such a behavior, which was good and comfortable.
Now it automatically scrolls down to the last arrived message, so if you were 
reading chat-log - your reading will be interrupted every time the contact 
sends you a new message. And it will be the pain in the eyes if he repeatedly 
sends you new messages, when you try to scroll up again and again.

Original issue reported on code.google.com by iDru...@gmail.com on 10 Jan 2011 at 6:27

[GoogleCodeExporter]

And I know that I can hit F12 to freeze autoscroll, but that is uncomfortable. 
I'm too lazy to do 2 extra clicks - why can't theis freezing get activated 
automatically, if the scroll is not at the most bottom position?

Original comment by iDru...@gmail.com on 10 Jan 2011 at 6:35

[GoogleCodeExporter]

This feature is in SRMM for sure.

Original comment by sami%mir...@gtempaccount.com on 10 Jan 2011 at 6:36

[GoogleCodeExporter]

The labels got lost...

Original comment by sami%mir...@gtempaccount.com on 10 Jan 2011 at 6:37

• Changed state: Assigned
• Added labels: Component-IM-TabSRMM

[GoogleCodeExporter]

This behavior is available for group chats but not for normal chats where you 
need to hit F12.

There are no plans to change this.

Original comment by silverci...@gmail.com on 10 Jan 2011 at 6:42

• Changed state: WontFix

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> There are no plans to change this.

Why? Could you please add this feature? It was very comfortable, when it worked.
If it bothers someone - you could do it optional and even switched off by 
default.

Original comment by iDru...@gmail.com on 10 Jan 2011 at 6:46

[GoogleCodeExporter]

Nope.

Reason is simple: It would work with the default message log but not with 
IEView or H++ unless someone implements the same feature in either plugin.

The manual (F12) method always works while an automatic method would not. SRMM 
does not support IEView or H++ for viewing the log.

So no, there is no chance for this feature being implemented.

Issue can be closed.

Original comment by silverci...@gmail.com on 10 Jan 2011 at 6:55

[GoogleCodeExporter]

But it worked before! Means, the code should already be written.
+ well, the feature for the default view would personally satisfy me, as I see 
no difference between the log modes and I do use default.

Original comment by iDru...@gmail.com on 10 Jan 2011 at 7:06

[GoogleCodeExporter]

No, it did never work in TabSRMM, it does work in SRMM though.

>well, the feature for the default view would personally satisfy me, as I see 
no difference between
>the log modes and I do use default.

Doesn't matter. I'm not going to implement a feature that would only partially 
work and confuse people who are not using the default log viewer. Bad idea.

So please stop from requesting it - if you absolutely need it, then use SRMM.

Original comment by silverci...@gmail.com on 10 Jan 2011 at 8:30

[GoogleCodeExporter]

Tell me how to enable tabbed mode in SRMM and I will switch to it.

Original comment by iDru...@gmail.com on 10 Jan 2011 at 9:07

[GoogleCodeExporter]

>Doesn't matter. I'm not going to implement a feature

You seem to be too hostile for adding any new features. What do other 
developers think about that request? what is the point of saying "we are open 
for feature requests" if you reject them?

Original comment by iDru...@gmail.com on 10 Jan 2011 at 9:12

[GoogleCodeExporter]

> No, it did never work in TabSRMM, it does work in SRMM though.

TabSRMM 2.2.1.14 (+ Miranda 0.8.9 Build Oct 21 2009 18:06:43) - it works in 
this version.

Original comment by iDru...@gmail.com on 10 Jan 2011 at 9:24

[GoogleCodeExporter]

Why option "... (only works with default log viewer)" can confuse any people?

It's strange to remove very useful feature.

Original comment by infocatc...@gmail.com on 10 Jan 2011 at 9:30

[GoogleCodeExporter]

I'm not hostile and a developer always has the right to reject a request if it 
doesn't make sense or cannot be implemented in a satisfying way. Which is 
clearly the case here.

IF you can convince devs to implement such an option in IEView and History++ I 
would be happy to add such a feature to TabSRMM, because it would then work as 
it should for ALL users, not only for those who are using the default log 
viewer.

This is the final word here.

Original comment by silverci...@gmail.com on 10 Jan 2011 at 9:36

[GoogleCodeExporter]

well, I've created the corresponding bugs, I hope those devs won't be hostile.

https://code.google.com/p/historypp/issues/list?thanks=11&ts=1294697200
http://developer.berlios.de/bugs/?func=detailbug&bug_id=17853&group_id=3292

Original comment by iDru...@gmail.com on 10 Jan 2011 at 10:07

[GoogleCodeExporter]

H++ implements IEView's API, which is definitelly contains scroll-to-bottom 
handler.
So, if tabsrmm sends this command, log scrolls to the bottom, no matter where 
it was.
And doesn't in case of command absence.
Did I miss smth? 

Original comment by v...@orient-96.ru on 10 Jan 2011 at 11:19

[GoogleCodeExporter]

The problem is to find out the current scroll position to determine whether the 
log is already at the bottom or not and if it is not, because the user is 
reading elsewhere, it should not scroll. There is no reliable way to do this 
with IEView or H++ via subclassing. The rich edit control, used by the default 
message log, provides this functionality and that's why it works in SRMM and 
group chats.

So yes, you missed something important.

Original comment by silverci...@gmail.com on 10 Jan 2011 at 11:25

[GoogleCodeExporter]

Nightwish, hi, the previous  message was mine
Actually, only log control (external) could efficienty deside is it at the 
bottom or not. As for me, I can provide such information, if tabsrmm (or 
whatever) ask for it, like id does IEE_GET_SELECTION.

Original comment by themiron.ru on 10 Oct 2011 at 6:46