Graphics Tools Screen Smaller than Console in Win10 - Revisited

[Eric Pearson]

Please read the rest of my post #17 above.

[Michael Mattias]

Probably will not be the first choice on your "possible workarounds" list, but another option is to replace the console screen with a GUI screen.

GUI screens are pretty much infinitely resizable and are not at the mercy of the console subsystem vagaries across Windows versions.

[Daniel Raymer]

Hi Eric,

I read #17 like my life depended on it!

My big problem is happening BEFORE the resizing. I'm getting the Graphics screen much smaller than the Console, before doing anything at all.

I can probably kludge something to handle the row/column/border things, but the Graphics screen is much smaller and I cannot draw past its limits. If it isn't fixable oh well, but then I'm totally screwed.

Dan

[Eric Pearson]

I'm not seeing that at all, using the program you posted. Is that screen shot from the same test program?

[Daniel Raymer]

Yes, from same program. Even the minimal code below shows a vertical black stripe to the right of the white graphics screen, of roughly 20% of the Console width. In the vertical direction it shows all white, but with a slider to the right indicating a huge screen area below (slider is tiny).

Maybe Win10 is giving the wrong info to ConsoleGfx(0,0,0,0)? I'm running a new Dell laptop, nothing exotic, and it came with Win10.

#REGISTER NONE
#COMPILE EXE
#INCLUDE "GFXT_Pro.INC"
#INCLUDE "CT_Pro.INC"
FUNCTION WINMAIN(BYVAL hCurInstance AS LONG, BYVAL hPrevInstance AS LONG, _
BYVAL lpszCmdLine AS ASCIIZ PTR, BYVAL nCmdShow AS LONG) EXPORT AS LONG
1019 ConsoleToolsAuthorize &hAxxxxx
lResult& = InitConsoleTools(hCurInstance,100, 2, 3, 0, 0)
lResult2& = GraphicsToolsAuthorize(&hA586xxxx)
lResult& = ConsoleGfx(0,0,0,0)
GfxWindow %GFX_SHOW
WAITKEY$
END FUNCTION

[Eric Pearson]

The Windows 10 default console is 80 columns x 300 rows, so Windows adds that scroll bar to the default console window. It has nothing to do with Console Tools, Graphics Tools, or your code.

As with the program in your first post, adding GfxRefresh to your program in post #25 fixes the black stripe on the right, at least it does on my Win10 systems. Except for the Win10 console-resizing weirdness that I documented, I'm not seeing anything unusual on any of the three systems I tested.

Let's not muddy the waters with different programs... Are you saying that the program in your first post -- but with GfxRefresh before the WAITKEY$ -- produces a black bar on the right side of the console? If so, 1) Are you having to manually move the console after the graphics window has been created, in order to see all of it? 2) What happens if you auto-hide the Task Bar or move it to a different location on the screen before you run your program? The fact that your Task Bar is on the left and the problem is on the right is suspicious.

Have you looked at the possible solution in the thread in my post #19? I see now that you did, I missed your post.

[Dave Biggs]

No screen shots available for the lurkers but from the descriptions Eric and Daniel aren't seeing the same thing - could it be an issue related to screen resolution / DPI ?

[Manuel Valdes]

Is it possible that a Shortcut ( Direct Access ) copied from a different OS is causing the problem?

[Daniel Raymer]

Eric - adding GfxRefresh didn't work. I put it between every line of code after GraphicsToolsAuthorize. I also tried using [CON.SCREEN = 10,20] with various numbers before ConsoleToolsAuthorize to see if I could trick it into returning the right numbers. It still looks like Win10 is giving the wrong info to ConsoleGfx(0,0,0,0). Can I start Contools & GFX without using ConsoleGfx, or somehow force it into a certain size? Or set my screen a certain way, or....?

Manuel - maybe you are on to something. I noticed that the screen looked different after I set up a Shortcut, even when I ran it from PBCC or by clicking on the EXE. Win10 seems to seek out and use a shortcut's settings even if you haven't used the shortcut! To get around this I've changed the name of the test program several times. But, maybe there is some Display setting to make it act like earlier Windows version. Or....?

I really appreciate the help you both are giving. Sorry that it seems machine-specific. That always makes it more difficult. But, my machine is a plain-jane Dell laptop, factory loaded with Win10, so if it doesn't work, many of my users will have the same problem. Unless I did something stupid when taking it out of the box, turning it on, and installing my usual software like Office, Kaspersky, and PBCC.

Samples for Lurkers are below:

[Eric Pearson]

Dan, please try this:

Windows Start Menu
Type REGEDIT and press Enter.
In the left pane of the Registry Editor...
Expand HKEY_CURRENT_USER
Select "Console"
In the right pane...
Double-click ForceV2
Change the value to 0
Click Ok
Close REGEDIT

After that you'll find that the console window will behave according to the old rules.

You'll still need to modify your program according to the paragraph above that starts "The other problem I see".

Let me know how the results look.

[Daniel Raymer]

I soooooo wanted that to work. But it made no difference. I tried rebooting first. Nope.

I searched the whole Registry for similar things, but nothing popped up.

Any similar ideas to try?

[Eric Pearson]

Oh wow, I bet I know what it is. This would affect both versions of the console, and it would explain why it is machine-specific.

By any chance have you adjusted the system-wide Windows font size, the modern equivalent of the old "Large Fonts"? If Windows 10 resizes the console fonts too, that would create the effect you are seeing. Windows 7 didn't resize the console font based on that setting.

[Daniel Raymer]

Hmmmm..... If I did, I didn't realize it.

Under Settings-Display I find Customize your Display (can also get there by right click on desktop, Display Settings). There is a slider called "Change the size of text, apps, and other items" which is set at 125% (Recommended).

Is that the one, or is there another place to look?

[Eric Pearson]

This makes perfect sense now. Change it to 100% and everything will be fine. (With the exception of the math that calculates spXSize and spXYSize; remember to detect Win10+ and do the calculation differently.)

[Daniel Raymer]

I should have been more clear - when I found it, I tested it. Made no difference.

Ahhhh - on a whim, I just tried rebooting after changing that text slider to 100%. That seems to work! The simple test case now shows correctly. I'll work it some more and post a final "all fixed, here's what to do" when I'm sure it is working.

Only problem - gotta get stronger glasses now that the Windows text is so much smaller.

[Daniel Raymer]

Interestingly, it now works great for the sample program I uploaded here but still messes up for my full program. The Console is initially made the correct Width but is still made 9001 rows in Height, causing problems when trying to scale the console to fit the screen. The buffer for Height can't then be set to a smaller value than the screen buffer.

I found a sneaky workaround:

ConsoleControl %CONSOLE_LEFT ,1 : ConsoleControl %CONSOLE_RIGHT ,80 'force console small so buffer can be set properly in Win10
ConsoleControl %CONSOLE_TOP ,1 : ConsoleControl %CONSOLE_BOTTOM ,25

and then
ConsoleControl %BUFFER_WIDTH, INT(spXSize*ConXsizemult)
ConsoleControl %BUFFER_HEIGHT, INT(spYSize*ConYsizemult)

This seems bulletproof, and also works on my WinXP machine.

BTW, this problem happens even when I copy the sample program right after WinMain() and put a WaitKey$ right after that. So something in the stuff before WinMain() is doing it, such as the #Includes or Globals or Functions. Beats me.

But bottom line is, my aircraft design program programmed in PBCC with Contools/GFX now CAN run on a Win10 machine. Thanks so much to Eric and Michael for all the help.

And to Bob Zale - thanks and RIP.