Announcement

Collapse
No announcement yet.

Graphics Tools Screen Smaller than Console in Win10 - Revisited

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Daniel Raymer
    replied
    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.

    Leave a comment:


  • Daniel Raymer
    replied
    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.
    Last edited by Daniel Raymer; 27 Sep 2016, 10:33 AM.

    Leave a comment:


  • Eric Pearson
    replied
    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.)

    Leave a comment:


  • Daniel Raymer
    replied
    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?

    Leave a comment:


  • Eric Pearson
    replied
    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.

    Leave a comment:


  • Daniel Raymer
    replied
    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?

    Leave a comment:


  • Eric Pearson
    replied
    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.

    Leave a comment:


  • Daniel Raymer
    replied
    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:

    Click image for larger version

Name:	Win10_Graphics_Screen_Smaller_than_ConsoleScreen.gif
Views:	3
Size:	21.2 KB
ID:	752929 Click image for larger version

Name:	Screenshot (6).bmp
Views:	2
Size:	22.5 KB
ID:	752930

    Leave a comment:


  • Manuel Valdes
    replied
    Is it possible that a Shortcut ( Direct Access ) copied from a different OS is causing the problem?
    Last edited by Manuel Valdes; 22 Sep 2016, 05:42 PM.

    Leave a comment:


  • Dave Biggs
    replied
    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 ?

    Leave a comment:


  • Eric Pearson
    replied
    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.

    Leave a comment:


  • Daniel Raymer
    replied
    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

    Leave a comment:


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

    Leave a comment:


  • Daniel Raymer
    replied
    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

    Leave a comment:


  • Michael Mattias
    replied
    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.

    Leave a comment:


  • Eric Pearson
    replied
    Please read the rest of my post #17 above.

    Leave a comment:


  • Daniel Raymer
    replied
    Hi Eric. The GFXrefresh fixed the problem where the red line didn't go corner to corner, but didn't fix the problem where the Graphics Window only covers about 80% of the Console screen, leaving black bars to the right and bottom. I'll email you a screen shot.

    All I'm doing is starting the EXE, authorizing Contools, authorizing GFX, and doing lResult& = ConsoleGfx(0,0,0,0) . But the Graphics Window doesn't cover the whole Console.

    Leave a comment:


  • Eric Pearson
    replied
    Also see https://forum.powerbasic.com/forum/u...e-resize-quirk

    Leave a comment:


  • Daniel Raymer
    replied
    Hi Eric, Thanks - just got back from two busy weeks and saw your post. I'll give those ideas a try. Let you know. /Dan

    Leave a comment:


  • Eric Pearson
    replied
    Hi Dan, I apologize for the LONG delay in getting to this. I experienced (ok, I caused) a multiple hardware failure before Labor Day, and I'm still trying to recover and catch up.

    > On Win10, the same EXE makes a black Console which covers the whole screen properly,
    > but its gray Graphic Window only covers about 80% of the Console,

    I'm not seeing that. I suspect that if you add a GfxRefresh before the WAITKEY$ you won't either but let me know.

    I do see a problem with the console resizing on Windows 10. For example on one of my Win10 systems, your program is requesting 87x271 (rows by cols) and Windows is changing the console size to 88x274. The amount of the error seems to vary depending on the console font; sometimes it gives me 86 instead of the requested 87, and sometimes it rounds the column count up to the next multiple of 10. Always even numbers. I tried replacing the relevant Console Tools functions with the PB/CC CON.SCREEN statement and it does exactly the same thing so it's not a ConTools or GfxTools problem. I don't know how you're going to get around that, unless you can find a console font that works predictably. You may be able to set the size and then check the size to see if you got a value that's close enough, and then re-do the re-size based that. Or maybe instead of calculating the size your program could contain a list of screen resolutions and use pre-selected, hard-coded row/col counts that work best for each screen size.

    The other problem I see is that the Windows 10 console does not have a dialog-sized border, as with all previous versions of Windows. That should be easy enough to patch; your code will need to detect the Windows Version and not subtract the ConsoleMetrics(%FRAME_WIDTH)*2 number from the calculation if Windows 10 is detected. (Or maybe Win8 or greater?) That alone might be enough to get you in the ballpark.

    FWIW, as far as I can tell none of this would have been affected by changing over to the native PB graphics and PBCC console statements.


    Leave a comment:

Working...
X