Layout/resizing console window in Windows - will become broken

[jbinko]

First of all thank you for this project. It was always something what I wanted (to have TVISION enabled in PC again) and you actually overachieved this with Unicode support and Linux portability. Great job!

One thing which I’m seeing is that if you run app in Windows console (E.g. tvdemo.exe with some window open in app) and you do resize of console with Alt+Enter or resizing with dragging right corner of Windows console, the layout will become broken. Not sure if this can be fixed somehow or if this is known limitation but would be nice to have this working properly.

[Michael137]

@jbinko interesting that you mention this. I've previously ported a tvision-based console application from Windows 7 (which had the legacy terminal) to Windows 10 (with its new 64-bit terminal). I bet if you go into the settings of your cmd window on Windows 10 and enable legacy mode, resizing won't break the app (well resizing isn't really supported on the legacy terminal). It's possible to hack the event loop to "fix" the screen in response to a Windows console resize event, but from what I recall, you'll always have a tiny interval where the UI appears scrambled.
But I might also be completely wrong and it's not the new console's fault...

[magiblot]

Hi @jbinko, thanks for your comment! Handling resize events is precisely one of the things I tried hard to get done right, so are you sure you are using an updated version of tvdemo.exe?

• If you compiled it yourself, what commit are you at?
• If you downloaded the binary directly from GitHub, remember that:
  • The binaries in Releases are outdated.
  • You can find up-to-date binaries in Actions. For example, these are the latest x86 binaries.

If you still experience the same issue using the latest version, can you then please share a screenshot of what you see?

Thank you very much.

[magiblot]

Hi @Michael137!

I bet if you go into the settings of your cmd window on Windows 10 and enable legacy mode, resizing won't break the app (well resizing isn't really supported on the legacy terminal).

Using the legacy console shouldn't make a difference because the Win32 console resize events are the same in either case. And actually, the legacy console can be resized via the settings dialog.

I've previously ported a tvision-based console application from Windows 7 (which had the legacy terminal) to Windows 10 (with its new 64-bit terminal).

I'm curious about the history of that application :). But just to clarify things, this port of Turbo Vision supports all Windows versions from Vista onwards. It doesn't matter whether you are using the legacy or the modern console or whether you are generating 64-bit or 32-bit binaries. There used to be font issues when using the legacy console, but they got fixed earlier this year.

Cheers!

[Michael137]

Using the legacy console shouldn't make a difference because the Win32 console resize events are the same in either case. And actually, the legacy console can be resized via the settings dialog.

Yea it might be a completely different resizing issue than I had (picture by OP would be helpful :)). IIRC, depending on how you resize the console, the events the app receives are different beween legacy and new console. But maybe that got fixed in later releases; or it's very plausible I'm misremembering :)

Either way, a screenshot would help..and a quick check if the behaviour is different in the legacy console

[jbinko]

Thank you for response. Attaching screenshots. First is OK, others are damaged as you try to resize window or use fullscreen (Hit Alt+Enter mutiple times). Legacy settings helps because it is preventing you to do resize. But I think this is not the right solution and it has global impact/gobal settings.

[magiblot]

Thanks for the screenshots! Now I understand what you meant. It's not that the layout is broken; the problem is that the application doesn't fit the whole console surface after the console resize. I looked into this issue in the past and came to the conclusion it's a bug in the Windows console. I guess I can look deeper into it and see whether there is any way to work around it or submit a bug report if there is none.

Thank you!

[guy-rouillier]

I just tried this version of TVision after working with SET's TVision at set-soft/tvision. Thank you for the work you've put into this.

I compiled your TVision on Windows 7 64-bit using Mingw-w64 in a 64-bit msys2 environment. Both TVision and the tvedit example build without error, following your instructions. However, tvedit has trouble with resizing via dragging on the bottom right corner.. After it is running and I've opened a text file, I can decrease the window size by dragging the corner with my mouse. However, having done that, I cannot then reverse that; that is, I cannot drag the same corner to increase the window size back to the original size. The mouse pointer changes to the resizing image, but nothing happens when I try to drag the corner.

Strangely, I discovered that if I open a DOS shell from the File menu, the shell window is back to the original size. When I then exit that, I'm back in tvedit.exe which is now also back to its original size.

[magiblot]

Hi Guy!

tvedit has trouble with resizing via dragging on the bottom right corner.. After it is running and I've opened a text file, I can decrease the window size by dragging the corner with my mouse. However, having done that, I cannot then reverse that; that is, I cannot drag the same corner to increase the window size back to the original size. The mouse pointer changes to the resizing image, but nothing happens when I try to drag the corner.

If you are using the native Windows console, then that may be a console issue. You can still change the console size from the Properties dialog. If this is not the case, can you please share a screen recording?

Strangely, I discovered that if I open a DOS shell from the File menu, the shell window is back to the original size. When I then exit that, I'm back in tvedit.exe which is now also back to its original size.

This behaviour is deliberate, although it can probably be improved. The point was to preserve the original screen buffer's contents.

Cheers.

[guy-rouillier]

I forgot to mention that I have set-soft/tvision on the same installation of msys2 and Mingw-w64, and resize works fine there: both to shrink and then return to original size. I run both versions in the standard Windows console. Interestingly, in set-soft, the mouse doesn't work with the menus. But it does with magiblot. After running magiblot, if I then run set-soft in the same console window, then the mouse now works with the menus! Apparently magiblot is making some setting that remains with the window. So each version of TVision brings something to the table. :)

Here are some screen recordings I've made of tvedit running under set and magiblot. Not much see, really, other than sizing back to original size works with set, but not with magiblot.

tvedit_window_resize_magiblot.mp4

tvedit_window_resize_set.mp4

[magiblot]

That's definitely a console issue. The Windows Console handles the window size separately from the buffer size (the size of the application that's running inside the console). Prior to Windows 10, resizing the window with the mouse would only change the window size, not the buffer size. Making the window larger than its initial size would require extending the buffer to left or to the bottom, so you are not allowed to enlarge the window.

Note that with SET's Turbo Vision you are only changing the window size: scrollbars appear when you shrink the console window but the application's contents have not changed, and you are still not allowed to make the console larger than the initial size.

My Turbo Vision autoadjusts itself so that the buffer size matches the window size and there are no scrollbars. On Windows 10 the result is what you'd expect, but on older consoles it's not. I don't know of a way to work around this.

[magiblot]

Strangely, I discovered that if I open a DOS shell from the File menu, the shell window is back to the original size. When I then exit that, I'm back in tvedit.exe which is now also back to its original size.

This behaviour is deliberate, although it can probably be improved. The point was to preserve the original screen buffer's contents.

This is now fixed in 1db2606.

[guy-rouillier]

Thanks for the update!