bugGNU Octave - Bugs: bug #52496, Command Window can't scroll up on...


bug #52496: Command Window can't scroll up on Windows 10 v. 1709

Submitter:  None
Submitted:  Fri 24 Nov 2017 04:16:48 PM UTC
Category:  GUI Severity:  3 - Normal
Priority:  7 - High Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Jop Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.4.1-rc1
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Fri 31 Aug 2018 02:34:38 PM UTC, comment #37: 

There is still a small problem with this fix as shown by this sequence of actions:

1. Clear the console buffer using clc command

2. Use the scroll bar to scroll down so that the prompt disappears off the top of the screen. Obviously this is not a particularly useful thing to do but it can happen accidentally.

3. Hit enter.

The desired behaviour I assume is that the console would scroll back to show the cursor however this does not happen. It is necessary to scroll up manually using the scroll bar.

I do not regard this as a serious problem, but if the code is to be looked at again due to https://savannah.gnu.org/bugs/index.php?54604 it might be worth considering for being fixed.

Ian McCallion <ianmcc>
Thu 16 Aug 2018 07:16:08 AM UTC, comment #36: 

Tested 4.4.1 on Windows 1803 with latest security updates and works fine with both legacy and new console. Many thanks on behalf of windows 10 users for this.

Re comment #19 I use octave a lot for scripting. I have never used the ability to run windows .cmd or .bat files and cannot imagine any reason to need it.

Ian McCallion <ianmcc>
Thu 09 Aug 2018 01:53:53 PM UTC, comment #35: 

I tested the 32-bit version on a Windows 10 system (1709) and it seems to be fine.  Unless there are any objections, I'll start making the release.

John W. Eaton <jwe>
Group administrator
Thu 09 Aug 2018 09:52:27 AM UTC, comment #34: 

If we are confident enough that it doesn't break anything (and I think we can be - thanks to John and Philip), I believe we can go ahead to the release without another candidate.
What's your opinion on the matter?

Markus Mützel <mmuetzel>
Group administrator
Wed 08 Aug 2018 07:23:42 PM UTC, comment #33: 

Since it appears to be working, I'll close this report.  It's also fine with me to remove the Windows 10 warning unless someone knows of another serious issue with Windows 10.

Should I make another "official" release candidate before the release?

John W. Eaton <jwe>
Group administrator
Wed 08 Aug 2018 07:02:10 PM UTC, comment #32: 

Can the bug report be closed then?

Philip Nienhuis <philipnienhuis>
Group Member
Wed 08 Aug 2018 12:01:15 PM UTC, comment #31: 

A 32 bit build running on my Windows 10 machine also works

John Donoghue <lostbard>
Group Member
Tue 07 Aug 2018 04:08:30 PM UTC, comment #30: 

Maybe someone on a 32bit Windows 7 can confirm? My systems are all 64bit

Philip Nienhuis <philipnienhuis>
Group Member
Tue 07 Aug 2018 12:26:37 PM UTC, comment #29: 

Very nice! So (slightly off topic) can we remove the Win10 warning from the installer ?

John Donoghue <lostbard>
Group Member
Mon 06 Aug 2018 09:21:09 PM UTC, comment #28: 

Works fine on Win 7 Prof. & Win 10 Prof. 1803

Philip Nienhuis <philipnienhuis>
Group Member
Mon 06 Aug 2018 07:52:31 PM UTC, comment #27: 

I'll try on Win 7.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 03 Aug 2018 08:55:19 PM UTC, comment #26: 

Not much help, but it works on my 64bit Win10 v1803 as well.
OS build 17134.191

John Donoghue <lostbard>
Group Member
Fri 03 Aug 2018 07:28:19 AM UTC, comment #25: 

It would be nice if this change could be tested on as many different versions of Windows to make sure it doesn't introduce any regressions.

It is working nicely for my Windows 10 1803 64bit.

Markus Mützel <mmuetzel>
Group administrator
Thu 02 Aug 2018 09:58:58 PM UTC, comment #24: 

I pushed a patch to stable here:

And merged to default.

This implements a workaround for the scroll position of the WinAPI Console not being updated properly. When scrolling up, the auto-scrolling of our Qt Command Window is disabled until scrolling down again or entering any key on the command prompt.

Markus Mützel <mmuetzel>
Group administrator
Thu 02 Aug 2018 12:18:51 PM UTC, comment #23: 

It would be great if you have found something that will work.  I won't be able to make the release until after the weekend anyway.

John W. Eaton <jwe>
Group administrator
Thu 02 Aug 2018 10:09:44 AM UTC, comment #22: 

I might be close to having a work-around for this.
Can the 4.4.1 release be delayed until after this weekend?
If I won't have it ready until then, it's going to take considerably longer until I can come back to it.

Changing targeting release to 4.4.1-rc1 and increasing priority.

Markus Mützel <mmuetzel>
Group administrator
Sat 28 Jul 2018 03:48:08 PM UTC, comment #21: 

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.

Markus Mützel <mmuetzel>
Group administrator
Thu 26 Jul 2018 09:10:28 PM UTC, comment #20: 

I'd tried the same things as comment #17 as well as setting some values using the console modes of the WinAPI, but had no luck either.

John Donoghue <lostbard>
Group Member
Thu 26 Jul 2018 07:16:25 PM UTC, comment #19: 

Longer term, I'd like to make the Octave command window just be a Qt text widget that interacts with the Octave interpreter differently than it does now.  So instead of trying to be a command terminal that allows running programs it would just allow command input and echo output from Octave.  Things like the system function could run programs and display output, but not run console programs.  That doesn't generally work now anyway, apparently doesn't work in Matlab, and I don't think it is really necessary.  When this is done, the Octave command window would use exactly the same code on both Windows and Unixy systems and won't involve the Windows Console thing at all.

John W. Eaton <jwe>
Group administrator
Thu 26 Jul 2018 07:03:39 PM UTC, comment #18: 

just a warning, this may not be the end of Windows CMD changes.


and apparently "Windows Subsystem for Linux" is a feature with some attention from the MS development community.  It maybe that there will be a better way to hook into the Windows CLI moving forward? That may require someone who knows what it is that project is trying to do in the first place.


Nicholas Jankowski <nrjank>
Group Member
Thu 26 Jul 2018 06:50:43 PM UTC, comment #17: 

I have a System running Windows 10 and can duplicate the problem.

I'd be glad to fix this if I knew how.

Is there a way to set the "ForceV2" registry key to 0 just for Octave?  That seems like the simplest fix for now.

My copy of Octave is installed in C:\Octave\Octave-4.4.0.  The octave.vbs script is ultimately runs C:\Octave\Octave-4.4.0\bin\octave-gui.exe.

After seeing the comment on this page:


I tried to use regedit to set the ForceV2 key just for Octave by adding a key under HKEY_CURRENT_USER\Console with the name %SystemDrive%_Octave_Octave-4.4.0_bin_octave-gui.exe using a DWORD value of 0x00000000 (0).  This did not seem to have any affect.  I also tried without the ".exe" suffix and using "C:" directly instead of %SystemDrive% but nothing I tried seemed to work.

Maybe someone else who has a better understanding of the Windows Registry better will have some ideas.

John W. Eaton <jwe>
Group administrator
Sun 22 Jul 2018 08:26:09 PM UTC, comment #16: 

Oddly, I didn't encounter the bug on Windows 7 Ultimate in an AMD64
That's not so odd, as this bug report is about a Windows-10 only bug related to changes made in Windows 10 and not in Windows 7.

@comment #14:
"damage system console' - powershell may be a better tool than the old cmd.exe

Philip Nienhuis <philipnienhuis>
Group Member
Sat 21 Jul 2018 03:04:12 PM UTC, comment #15: 

I can confirm this bug. It's specific to the GUI; octave-cli works fine.

Oddly, I didn't encounter the bug on Windows 7 Ultimate in an AMD64.

- <arenal5>
Sat 16 Jun 2018 10:24:01 AM UTC, comment #14: 

awful. why dies cross-platform software relies on windows orifinal and very outdated feature? Why have I to damage my system console in order to work with user-mode software?

Mon 16 Apr 2018 12:30:01 AM UTC, comment #13: 

This issue does seem to be related to the new console features in Windows 10 1709.  A workaround is to go to the cmd properties, and in 'Options' enable the "Use legacy console" option.  Scrolling should now work, although the possibly useful new console features will be disabled in all Command Prompt windows.

Fri 13 Apr 2018 08:11:52 PM UTC, comment #12: 

The GUI command window seems to be attached to Windows cmd.exe's properties.

If you change the properties of the cmd.exe by clicking on the top bar then going to Properties (or Defaults for that matter) and under the layout section increasing the Window Height, it helps.

It does not solve the problem but at least you can see more lines.

alpay <alpay>
Thu 15 Mar 2018 03:04:35 PM UTC, comment #11: 

Re: comment #10
The same trick works with "pause". While it is waiting for a key, it is possible to scroll the command window.

Markus Mützel <mmuetzel>
Group administrator
Thu 15 Mar 2018 02:21:19 PM UTC, comment #10: 

Same scrolling behaviour after updating to 4.2.2. There exists a sort of emergency workaround for temporatily enabling the scroll functionality. I found out, that scrolling is possible while a program is waiting for button clicks in an Octave UI function, for instance in msgbox(".."). Write a tiny function like:


Execute the function and a message window pops up and the function is waiting for an OK click. While waiting you may scroll the command window. As soon as you click OK, scrolling is prohibited again. Well, not the optimum solution, but at least a way to look a bit in the past of the command window.

Tue 13 Feb 2018 03:16:55 PM UTC, comment #9: 

This bug also affects me. I have Octave version 4.2.1 configured "x86_64-w64-mingw32". My OS is Windows 10 Home, Version 1709, OS build 16299.192

I can scroll down past the current line and past all text in the Command Window, but any attempts to scroll up bounce right back to where the cursor is.

Dana Conrad <dconrad>
Sun 31 Dec 2017 08:25:42 PM UTC, comment #8: 

Seeing same behaviour
Microsoft Windows [Version 10.0.16299.125]
GNU Octave v4.2.1

David Chalmers <dchalmers>
Thu 28 Dec 2017 07:44:02 PM UTC, comment #7: 

When more is active with large output showing "-- less -- (f)orward, (b)ack, (q)uit", then vertical scroll shows the same behavior of keeping the cursor on the screen, but with some nuances. Scrolling up works, but the "-- less --..." line moves up with the screen, and scrolling down only goes till the current cursor position is at the top of the screen. scrolling down shows garbled text interspersed with "-- less --..." lines. Pressing the down arrow moves that line with the cursor down and cleans up the text again. Pressing 'q' before getting to the bottom leaves the garbled text on the screen and now scrolling up only works until the cursor is at the bottom of the screen, and scrolling down works as far as there is the garbled "more" text still below it, even though the cursor has moved off the screen.

Marshall <marsian>
Thu 28 Dec 2017 07:11:23 PM UTC, comment #6: 

I've noticed that sometimes horizontal scroll has the same behavior, but the way it does it might provide some more insight into what's happening with the vertical scroll problems as well: When scrolling is being blocked I find that it is resetting the scroll position to keep the cursor on the screen. For very long lines, as long as the cursor is on the screen, it doesn't jump. But if I drag the scrollbar to move the cursor off the screen, then it will jump to where the cursor is at the edge of the screen. Sometimes it doesn't do it and sometimes it does: I can reliably get it to show the jumping behavior by pressing the up arrow to get to a prior long line, and using the left/right arrow keys to move the cursor to different positions to test the scrollbar-drag-jumping.

Marshall <marsian>
Wed 13 Dec 2017 08:45:25 PM UTC, comment #5: 

Confirmed on dev Octave as well, on Win10 version 1709.

Pager ("more ...") on or off makes no difference. The window contents just can't be scrolled back.

I'm afraid this is caused by Win10's newest feature update. Win10 is a moving target it seems :-(

Philip Nienhuis <philipnienhuis>
Group Member
Wed 13 Dec 2017 02:24:55 PM UTC, comment #4: 

I have this problem too. I noticed also that I can use the scroll bar to scroll up and briefly see text above what's shown, but it jumps back to the bottom persistently. I have to keep dragging it to have it jump to the right location for a brief second, but as soon as I stop it jumps back down. I can't say when it started, because it certainly used to be able to scroll up.

Marshall <marsian>
Sat 09 Dec 2017 05:02:29 PM UTC, comment #3: 

Same problem here.

Microsoft Windows [versão 10.0.16299.64]
GNU/Octave 4.2.1

GNU Octave Version: 4.2.1
GNU Octave License: GNU General Public License
Operating System: MINGW32_NT-6.2 Windows 6.2  x86_64
Package Name         | Version | Installation directory
     communications  |   1.2.1 | C:\Octave\OCTAVE~1.1\share\octave\packages\communications-1.2.1
            control  |   3.0.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\control-3.0.0
     data-smoothing  |   1.3.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\data-smoothing-1.3.0
           database  |   2.4.2 | C:\Octave\OCTAVE~1.1\share\octave\packages\database-2.4.2
          dataframe  |   1.1.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\dataframe-1.1.0
              dicom  |   0.1.1 | C:\Octave\OCTAVE~1.1\share\octave\packages\dicom-0.1.1
          financial  |   0.5.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\financial-0.5.0
               fits  |   1.0.7 | C:\Octave\OCTAVE~1.1\share\octave\packages\fits-1.0.7
fuzzy-logic-toolkit  |   0.4.5 | C:\Octave\OCTAVE~1.1\share\octave\packages\fuzzy-logic-toolkit-0.4.5
                 ga  |  0.10.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\ga-0.10.0
            general  |   2.0.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\general-2.0.0
      generate_html  |  0.1.13 | C:\Octave\OCTAVE~1.1\share\octave\packages\generate_html-0.1.13
           geometry  |   2.1.1 | C:\Octave\OCTAVE~1.1\share\octave\packages\geometry-2.1.1
                gsl  |   2.0.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\gsl-2.0.0
              image  |   2.6.1 | C:\Octave\OCTAVE~1.1\share\octave\packages\image-2.6.1
 instrument-control  |   0.2.3 | C:\Octave\OCTAVE~1.1\share\octave\packages\instrument-control-0.2.3
           interval  |   2.1.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\interval-2.1.0
                 io  |   2.4.5 | C:\Octave\OCTAVE~1.1\share\octave\packages\io-2.4.5
     linear-algebra  |   2.2.2 | C:\Octave\OCTAVE~1.1\share\octave\packages\linear-algebra-2.2.2
               lssa  |   0.1.2 | C:\Octave\OCTAVE~1.1\share\octave\packages\lssa-0.1.2
              ltfat  |   2.2.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\ltfat-2.2.0
            mapping  |   1.2.1 | C:\Octave\OCTAVE~1.1\share\octave\packages\mapping-1.2.1
      miscellaneous  |   1.2.1 | C:\Octave\OCTAVE~1.1\share\octave\packages\miscellaneous-1.2.1
                nan  |   3.1.2 | C:\Octave\OCTAVE~1.1\share\octave\packages\nan-3.1.2
             netcdf  |  1.0.11 | C:\Octave\OCTAVE~1.1\share\octave\packages\netcdf-1.0.11
              nurbs  |  1.3.10 | C:\Octave\OCTAVE~1.1\share\octave\packages\nurbs-1.3.10
                ocs  |   0.1.5 | C:\Octave\OCTAVE~1.1\share\octave\packages\ocs-0.1.5
             odepkg  |   0.8.5 | C:\Octave\OCTAVE~1.1\share\octave\packages\odepkg-0.8.5
              optim  |   1.5.2 | C:\Octave\OCTAVE~1.1\share\octave\packages\optim-1.5.2
         quaternion  |   2.4.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\quaternion-2.4.0
           queueing  |   1.2.5 | C:\Octave\OCTAVE~1.1\share\octave\packages\queueing-1.2.5
             signal  |   1.3.2 | C:\Octave\OCTAVE~1.1\share\octave\packages\signal-1.3.2
            sockets  |   1.2.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\sockets-1.2.0
          sparsersb  |   1.0.2 | C:\Octave\OCTAVE~1.1\share\octave\packages\sparsersb-1.0.2
            specfun  |   1.1.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\specfun-1.1.0
            splines  |   1.3.2 | C:\Octave\OCTAVE~1.1\share\octave\packages\splines-1.3.2
                stk  |   2.3.4 | C:\Octave\OCTAVE~1.1\share\octave\packages\stk-2.3.4
            strings  |   1.2.0 | C:\Octave\OCTAVE~1.1\share\octave\packages\strings-1.2.0
             struct  |  1.0.14 | C:\Octave\OCTAVE~1.1\share\octave\packages\struct-1.0.14
             tisean  |   0.2.3 | C:\Octave\OCTAVE~1.1\share\octave\packages\tisean-0.2.3
                tsa  |   4.4.5 | C:\Octave\OCTAVE~1.1\share\octave\packages\tsa-4.4.5
              video  |   1.2.3 | C:\Octave\OCTAVE~1.1\share\octave\packages\video-1.2.3
            windows  |   1.2.4 | C:\Octave\OCTAVE~1.1\share\octave\packages\windows-1.2.4
             zeromq  |   1.2.1 | C:\Octave\OCTAVE~1.1\share\octave\packages\zeromq-1.2.1

João Nier <joaonizer>
Fri 01 Dec 2017 01:56:05 AM UTC, comment #2: 

I also have this problem. This seems to have started after the Windows 10 FCU update. Octave 4.2.1 from the installer.

Fri 24 Nov 2017 05:55:40 PM UTC, comment #1: 

I am also having this problem, Windows 10, Octave 4.2.1. Any thoughts anyone?

Fri 24 Nov 2017 04:16:48 PM UTC, original submission:  

When executing command:

I can scroll up the command window, while 'more' is not finished.
When it is finished, I can't scroll up anymore.

Another strange this is this:
The command window seems to have some sort of line buffer,
I can scroll down, into the space where nothing has ever been printed (what's the use for this?), but I can't scroll up.

It seems the algorithm which checks where the cursor is, and keeps it in view, is wrong.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by ianmcc (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by svillemot
  • -email is unavailable- added by arenal5 (Posted a comment)
  • -email is unavailable- added by alpay (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dconrad (Posted a comment)
  • -email is unavailable- added by dchalmers (Posted a comment)
  • -email is unavailable- added by marsian (Posted a comment)
  • -email is unavailable- added by joaonizer (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-08 jwe StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-08-02 mmuetzel StatusConfirmed Ready For Test
    2018-08-02 mmuetzel Priority5 - Normal 7 - High
        Releasedev 4.4.1-rc1
    2018-07-26 svillemot Carbon-Copy- Added svillemot
    2018-03-16 mtmiller Dependencies- bugs #53360 is dependent
    2018-01-05 qformula Carbon-Copy- Added qformula
    2017-12-13 philipnienhuis StatusNone Confirmed
        Release4.2.1 dev
        SummaryCommand Window can't scroll up Command Window can't scroll up on Windows 10 v. 1709

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code