SetScroll hidden scrollbar flashes on input

Posted by Fiendish on Thu 19 May 2016 09:20 AM — 10 posts, 39,507 views.

USA Global Moderator #0
If you hide the scrollbar with SetScroll(-1, false) then the scrollbar still flashes on the screen when you press enter if there is something in the input bar (non-empty input). It happens inconsistently (4/5 for me?), so you may have to try a few times.
Amended on Thu 19 May 2016 09:22 AM by Fiendish
Brazil #1
Happens to me whenever I hit ENTER, regardless of whether I have anything in the input bar or not, and also sometimes when I receive text from the MUD.

I've just tried sending "asd" a couple of times:
Flashes when "asd" is sent 100% of the time.
Flashes when "Please stop mashing random keys on your keyboard." is received about 20% of the time.
Amended on Thu 19 May 2016 10:32 AM by VBMeireles
Australia Forum Administrator #2
Can't reproduce using Windows XP.
USA Global Moderator #3
Definitely happens for me in an XP VM. Very reliably.

It's caused by doing certain kinds (amounts?) of work inside OnPluginWorldOutputResized (which the Aardwolf health bars plugin seems to do) while scroll is hidden.

You can test with this plugin, but be careful with it. Without any other plugins loaded it causes my MUSHclient to completely lock up in an infinite loop.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<muclient>
<plugin
   name="Resize_Test"
   author="Fiendish"
   id="aaaaaaaaaaaaaaaaaaaaaaaa"
   language="Lua"
   requires="4.00"
   version="1.0"
   >
</plugin>

<script>
<![CDATA[
function OnPluginWorldOutputResized()
   print("huh")
   Repaint()
end
]]>
</script>
</muclient>
Amended on Fri 20 May 2016 09:03 AM by Fiendish
Australia Forum Administrator #4
Test how? Resizing the world? I would regard outputting something during a world resize as a bit dodgy.
USA Global Moderator #5
Nick Gammon said:

Test how? Resizing the world?

No. Just load the plugin in the middle of a new session, make sure that the scrollbar is _visible_ and print something to the screen.

Then close out, load a new session, hide the scrollbar, load the plugin, and print something again.

MUSHclient starts resizing _constantly_.
Printing to the screen should not cause a resize, but it does if the scrollbar is hidden, because it momentarily unhides and then rehides it for no reason.

Quote:
I would regard outputting something during a world resize as a bit dodgy.

What? No way! Output shouldn't cause a resize event.
Amended on Sat 21 May 2016 08:30 AM by Fiendish
Australia Forum Administrator #6
Well, that was a little harder to fix than I expected.

It seems that setting the current scroll bar position caused the scroll bar to be shown, and then a moment later other code detected it should be removed. Drawing the scroll bar caused the client size to change, and removing it caused it to change again.

The position is used to detect if we are at the end of the output buffer (for auto-freezing of output, and also for displaying "MORE" in inverse), so simply removing the setting of the scroll bar wasn't enough.

https://github.com/nickgammon/mushclient/commit/1f5f0e7
USA Global Moderator #7
Quote:
It seems that setting the current scroll bar position caused the scroll bar to be shown

I wouldn't have expected that given that the toggle for whether or not to display it seems to be an entirely separate system API call.
Amended on Wed 25 May 2016 02:03 PM by Fiendish
Australia Forum Administrator #8
I didn't expect it either, however it seems I overloaded the system call, and it does more:


void CMUSHView::SetScrollSizes (SIZE sizeTotal, 
                     const SIZE& sizePage, 
                     const SIZE& sizeLine)
  {
CMUSHclientDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
SCROLLINFO ScrollInfo;

  m_scroll_limit = sizeTotal;

  GetScrollInfo (SB_VERT, &ScrollInfo, SIF_ALL);
  ScrollInfo.nMin = 0;
  ScrollInfo.nMax = sizeTotal.cy - 1;
  ScrollInfo.nPage = sizePage.cy;
  SetScrollInfo (SB_VERT, &ScrollInfo, pDoc->m_bScrollBarWanted);
  m_ScrollbarPosition = ScrollInfo.nPos;

  /*
  GetScrollInfo (SB_HORZ, &ScrollInfo, SIF_ALL);
  ScrollInfo.nMin = 0;
  ScrollInfo.nMax = sizeTotal.cx - 1;
  ScrollInfo.nPage = sizePage.cx;
  SetScrollInfo (SB_HORZ, &ScrollInfo, pDoc->m_bScrollBarWanted);
*/

  } // end of CMUSHView::SetScrollSizes


I presume the call to SetScrollInfo is the culprit, however I don't see why that would show the scrollbar if m_bScrollBarWanted was false.




By the way, this should make you laugh. When I was debugging, and resized the window, none of the "huh" messages appeared. This was driving me a bit crazy until I remembered the deferred outputting that you were complaining about. As soon as I hit <enter> they all popped up at once. :)

This was because I had a prompt as the last line on the screen, and it was a prompt not terminated by a newline. So, working as intended. :P
USA Global Moderator #9
Quote:
When I was debugging, and resized the window, none of the "huh" messages appeared. This was driving me a bit crazy

lol