How to get the size of the windows console form?

Question

I'm looking for a way to get the size of the actual window of the console in pixels. All what I've found this far are uses winforms or WPF, both of which I don't use. I'm not looking for how to get the size inside the console window but how big the window itself is.

Answer 1

I search the web but I found nothing usefull.

All answers return either number of characters either the full screen resolution.

The Windows console is historically an emulation of the DOS shell.

From How to get the screen size of Console Application?:

using System.Management;  // Need assembly reference added to project

Console.Write("Console resolution in char:");
Console.Write(Console.WindowWidth + "x" + Console.WindowHeight);

var scope = new ManagementScope();
scope.Connect();
var query = new ObjectQuery("SELECT * FROM Win32_VideoController");
using ( var searcher = new ManagementObjectSearcher(scope, query) )
  foreach ( var result in searcher.Get() )
    Console.WriteLine("Screen resolution in pixels: {0}x{1}",
                      result.GetPropertyValue("CurrentHorizontalResolution"),
                      result.GetPropertyValue("CurrentVerticalResolution"));

It returns the screen resolution from the current video driver mode.

The Windows command line is no more a DOS command line but a reduced shell.

Many things and many DOS commands were lost.

You cannot create programs in the console itself anymore.

The command line outputs API is now very simple and basic.

Today a console app can only know its resolution in chars.

There is no more advanced API nor interrupts available.

The Windows DOS shell COMMAND.COM has been abandonned for Command Prompt CMD.EXE after Windows Me.

There is no simple way to know what is the resolution in pixels of the Windows that "hosts" the inner console.

using System.Diagnostics;
using System.Drawing;
using System.Runtime.InteropServices;

[DllImport("user32.dll")]
private static extern int GetWindowRect(IntPtr hwnd, out Rectangle rect);

Rectangle rect;
GetWindowRect(Process.GetCurrentProcess().MainWindowHandle, out rect);
Console.WriteLine($"Console window location: {rect.X}x{rect.Y}");
Console.WriteLine($"Console window resolution: {rect.Width}x{rect.Height}");

But the result is not very accurate.

For example it shows:

Console window location: 187x174
Console window resolution: 1336x812

When the real resolution is 1149x638...

And this console window resolution vary at each run...

Console window location: 99x58
Console window resolution: 1248x696

Console window location: 143x116
Console window resolution: 1292x754

Console window location: 77x29
Console window resolution: 1226x667

Console window location: 187x174
Console window resolution: 1336x812

---

The real console form size is:

RealWidth = rect.Width - rect.X;
RealHeight = rect.Height - rect.Y;

Answer 2

The issue and its history

I doubt the Console is in any way under the level of control that you would need for this. Basically, when the console was originally designed, the idea of a Window had not yet been thought up. They are assumed to be full-screen in very low resolution, which was common back in those days. And they never really changed since then.

On higher resolutions, the best equation possible is to make a Window that covers part of the screen. But it is a Window only under OS control, not yours.

You could have a Console Window in parallel to a normal Desktop GUI interface. It is actually pretty simple. But it is still the same old console with all limits you got right now.

My best advice is:

Stop trying to use console. Instead, fake a Console Window using WindowsForms, WPF or UWP.

Using Process and Input/Output stream redirection, you can easily control a command line from your WinForms/WPF program. Just be warned that there is 3 Stream. Input, Output and Error (which is usually also sent to the console window). All without the console showing. It used to be a common approach to control programs that were command-line only, but nowadays it is mostly forgotten outside of the Unix/Linux World, as nearly everything has a Frontend.

You can then map the input/output to a label, textbox, richtTextBox or the like that mostly behaves and looks like a Console Window, without being one. And since it is Window of your display technology of choice, you got all the options to manipulate it.