Results 1 to 4 of 4

Thread: High DPI behaving erratically and 'crashing'

  1. #1

    Thread Starter
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    5,647

    High DPI behaving erratically and 'crashing'

    So in my shell browser control app, and not quickly reproducible in others, after a few clicks and/or folder changes, two things happen:
    1) The popup menus, both a GetCursorPos placed TrackPopupMenu call (unmodified), suddenly become offset to the left/top by about what you would expect with my 150% scaling. Debug info indicates GetCursorPos is returning the exact same position. This happens in both IDE and compiled.
    and 2) DPI scaling in the IDE becomes all wonky; menu items disappear; form design appears magnified; various graphics glitches. This doesn't happen if I exit the app before the menu offsets start. If I restart the app at this point, DPI scaling is entirely disabled and everything appears tiny (but on the good side, it's no longer possible to get the menus offset); this only applies to IDE. Have to restart the IDE then everything is normal again. (This is what I mean by high DPI is 'crashing')

    It always happens after a few clicks, but exactly how many I get before it happens is random, and it doesn't seem linked to clicking in any particular position. I'm trying to see if anything similar is happening in my other apps, and so far no, but I don't understand what would be different... the API menu routines I'm using are mostly copied identical between the apps I've tested, and I even made a similar setup where it specifically alternated between a button popup and shell context menu in my shell tree app.

    Everything in VB6 and Win7 had been going so perfectly since I got my new 4k monitor a month ago too

  2. #2
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: High DPI behaving erratically and 'crashing'

    Maybe see Improving the high-DPI experience in GDI based Desktop Apps?

    This only works on Windows 10 1703 and later though.

    You'd need to apply GDI Scaling to VB6.EXE and your compiled programs. This can be selected via application manifest or an appcompat shim (Explorer Properties dialog or Application Compatibility Toolkit) or a Group Policy setting.
    Last edited by dilettante; Aug 16th, 2018 at 10:21 PM.

  3. #3

    Thread Starter
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    5,647

    Re: High DPI behaving erratically and 'crashing'

    I could see if there was never correct scaling... that would be easy. But like right now I clicked around for 5 minutes and all the positions and scale factors are perfect; sometimes 1 or 2 clicks it breaks--- all this executing the same two menu routines. And none of my other apps seem to have a similar issue, despite extremely similar code. So the issue is really what could be 'breaking' the DPI scaling randomly like this. I was thinking of trying marking it as DPI Aware in the manifest; does that mean I'd have to manually scale the controls? Right now since it's just LV/TV/Command Buttons manual adjustments haven't been needed, just relying on the Windows default.

    Limiting compatibility to Win10 is definitely not possible; need to support high dpi on 7.. which again though has been going really well, this is the first problem to crop up in over a month.


    Edit: After 10 minutes this time it finally broke again, and this graphics glitch appeared. Those partially obscured big buttons work too; clicked maximize and it maximized the app.
    Last edited by fafalone; Aug 16th, 2018 at 11:34 PM.

  4. #4
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: High DPI behaving erratically and 'crashing'

    If you have not been marking the program as DPI Aware one way or another then you are probably defaulting to one form or another of DPI Virtualization (depending on the OS version and settings of the specific PC).

    If you mark it DPI Aware then your program has full responsibility for scaling everything. There are a few helpers in VB6 itself but many of those go off the rails a bit when the twips per pixel goes fractional. There are also some Win32 API helpers for scaling icons down smoothly instead of up crudely. But all of it can be a lot of work to try to retrofit into an existing large program.

    For most legacy code your best bet is to develop on a conventional monitor at 96 DPI and rely on GDI Scaling (Win 10 1703 and later) to cope with gratuitously high resolution monitors. If you must support obsolete or dying OSs like Windows 7 it is best to stick to 96 DPI monitors. The only alternative is a lot of work and testing with some level of DPI Awareness selected.

    GDI Scaling falls down in many cases, but it was only meant as an appcompat strategy for keeping old programs alive and simplifying new development. Some of the things it doesn't handle are described near the end of the article I linked above.


    This isn't really a VB6 issue. Even .Net's WPF UIs can fall down at handling High DPI. If it wasn't a universal issue we'd never have gotten GDI Scaling.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width