octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #52496] Command Window can't scroll up on Wind


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #52496] Command Window can't scroll up on Windows 10 v. 1709
Date: Sat, 28 Jul 2018 11:48:08 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

Follow-up Comment #21, bug #52496 (project octave):

There is QtConsole a fork of QConsole that is referenced in
QWinTerminalImpl.cpp. QtConsole is based on Qt5's QTextEdit. [1]

Judging from the description, it should be able to do most things we need as
it is. At least it could serve as a starting point for our own QTextEdit
command window.

Could this be a GSOC project? Albeit I won't be able to help (no Qt skills)
and it would be too late for Octave 5.

[1]: https://github.com/uglide/QtConsole


Meanwhile I tried to understand what is happening in QWinTerminalImpl.cpp: 
TL;DR: "SetConsoleWindowInfo" doesn't seem to update the scroll position for
the modern Windows 10 console any more.

More in detail:
It looks like we spawn a Windows console which is hidden off screen. The
command window that we see in the GUI seems to copy the content of the
"actual" console. The function "monitorConsole" keeps track of the cursor and
scroll position in that console (among other things). If they get out of sync
with our command window (for example some new output gets displayed in a new
line in the "actual", invisible console), the visible copy in the command
window gets updated (so we can see the results without manually scrolling
down). This function is executed on a 10ms timer.
The problem arises because scrolling the Octave command window doesn't seem to
scroll the "actual" console any longer. Each time the function
"monitorConsole" executes, it resets the scroll position to the one of the
"actual" invisible console.
Scrolling the "actual" console with "SetConsoleWindowInfo" in
"setVerticalScrollValue" does report success. But it doesn't seem to affect
the srWindow position of "GetConsoleScreenBufferInfo". But I think it should
(and it seems it did on previous Windows versions).
I didn't find any reports that "SetConsoleWindowInfo" suddenly stopped working
with a Google search. So at the moment I am out of ideas.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52496>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]