Page 2 of 3 FirstFirst 123 LastLast
Results 41 to 80 of 112

Thread: Proof of concept for handling DPI per monitor V2 transparently... or almost

  1. #41
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    In High DPI Reference I see GetWindowDpiHostingBehavior() but no SetWindowDpiHostingBehavior().

  2. #42
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by dilettante View Post
    In High DPI Reference I see GetWindowDpiHostingBehavior() but no SetWindowDpiHostingBehavior().
    There's a few DPI APIs like that (Get but no Set). You'll notice that in those cases, the "Get" returns a static value. In the above case, the API returns a static value because once a window is created the hosting behavior can't be changed. To set the behavior: call SetThreadDpiHostingBehavior before creating the window.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  3. #43

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    I think we found what can fix third party ocx windows hosted in a PM2 aware program then.

    SetThreadDpiHostingBehavior:

    DPI_HOSTING_BEHAVIOR enables a mixed content hosting behavior, which allows parent windows created in the thread to host child windows with a different DPI_AWARENESS_CONTEXT value.
    This is only necessary if your app needs to host child windows from plugins and third-party components that do not support per-monitor-aware context. This is most likely to occur if you are updating complex applications to support per-monitor DPI_AWARENESS_CONTEXT behaviors.

  4. #44
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    If you play with that API, you'll see it is designed for out-of-process windows. Or out-of-thread windows. VB standard exes are single threaded. In one of my recent replies, I mentioned changing thread context for a top-level window. In VB, without introducing multithreading, I think that is the solution for now. Create popup forms or separate top-level forms containing the controls that can't be scaled for PMV2, change the context to unaware/GDI scaling, then create the form & restore context. Changing thread context for new top-level forms supported as v1703.

    And, that option also allows one to piece-meal their application for conversion to PMV2. Spend time getting the main GUI forms PMV2, while launching the other forms into unaware/GDI-scaling context. As time permits, convert the remaining forms to PMV2.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  5. #45

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    So, in short, do you think that entire forms can be set to a different DPI awareness (other than PMV2 as the program is manifested) but not each child window separately?

  6. #46

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by LaVolpe View Post
    If you play with that API, you'll see it is designed for out-of-process windows. Or out-of-thread windows. VB standard exes are single threaded...
    MSDN:

    Sets the thread's DPI_HOSTING_BEHAVIOR. This behavior allows windows created in the thread to host child windows with a different DPI_AWARENESS_CONTEXT.
    . This property only effects new windows created within this thread while the mixed hosting behavior is active. A parent window with this hosting behavior is able to host child windows with different DPI_AWARENESS_CONTEXT values, regardless of whether the child windows have mixed hosting behavior enabled
    Where did you read that they must run in other thread?

  7. #47
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    I was talking about "another thread" or "another process" in the context of the child window, not the host window. Any child window created is in the DPI awareness context of its parent window. In VB, we can host an out of process window via SetParent.

    As for your 2nd quote, that is trying to describe that when you call SetThreadDpiHostingBehavior, newly created windows in your project (top level) will have that hosting behavior, until the thread's behavior is changed again/restored. You can't change the window's behavior after the window has been created.

    When I first saw that MSDN article, I read it exactly how you were interpreting it. Only when I began experimenting, then did I understand what it really meant. In my opinion, it is just worded awkwardly for VB, because we are single threaded whereas the rest of the code-world is mostly multithreaded.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  8. #48

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by Eduardo- View Post
    So, in short, do you think that entire forms can be set to a different DPI awareness (other than PMV2 as the program is manifested) but not each child window separately?
    ????

    (and please forget about "other theads or processes", there is nothing like that in normal VB)

  9. #49
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    ActiveX EXE?

  10. #50

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by dilettante View Post
    ActiveX EXE?
    I meant "normal VB" for usual, or what people normally use.
    Of course you can do threading in different ways.

  11. #51

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    LaVolpe: how did you catch the creation of the child windows in your experiments?

  12. #52
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by Eduardo- View Post
    So, in short, do you think that entire forms can be set to a different DPI awareness (other than PMV2 as the program is manifested) but not each child window separately?
    Yes, as of v1703, see post #38. I had 3 forms, each with different DPI awareness contexts running in the same application.

    P.S. Regarding SetThreadDpiHostingBehavior there are other restrictions too. For example, I tried this out of curiosity: Create a form in unaware-context, and hidden (Form2). On Form2 was a simple listbox with scrollbar visible. From Form1 (PMV2 & mixed-mode hosting behavior), I tried to use SetParent API to move Form2 listbox to Form1, hoping that the ListBox would be displayed and still be unaware-context. SetParent fails.

    LaVolpe: how did you catch the creation of the child windows in your experiments?
    No. Per MSDN, child windows always inherit the awareness context of their parent -- no exceptions.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  13. #53

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by LaVolpe View Post
    I tried to use SetParent API to move Form2 listbox to Form1, hoping that the ListBox would be displayed and still be unaware-context. SetParent fails.
    SetParent is something else, not true child window creation.

    Quote Originally Posted by LaVolpe View Post
    No. Per MSDN, child windows always inherit the awareness context of their parent -- no exceptions.
    Where can I read that? (it seems to contradict the other page).

    But then, you didn't try changing the thread hosting awareness just before the child window creation as the other page states?

  14. #54
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    I got it. I had a boolean value set incorrectly which caused the problem. I can get a form to host a control in a different context -- Eureka!!!

    After getting that unaware listbox over to Form1, I increased DPI to 150%. The Listbox is clearly bitmap-stretched and the existing listbox on that PMV2 form was scaled perfectly via PMV2. Now we have a workaround for controls that can't be scaled for PMV2. Does requires Win10.v1803+

    Where can I read that? (it seems to contradict the other page).
    I'd have to search for it again, I think it was in some sort of table when comparing DPI contexts. But it was clearly stated.

    Edited: Here's one such quote from MSDN (not worded clearly), but I've seen it elsewhere also, explicitly using the word "inherit". Regardless, you'll see comments all over MSDN regarding setting awareness context applies either to entire process and/or top-level windows only, depending on O/S version.
    Prior to the Windows 10 Anniversary Update (1607), the DPI awareness mode of a process was a process-wide property. Beginning in the Windows 10 Anniversary Update, this property can now be set per top-level window. (Child windows must continue to match the scaling size of their parent.) A top-level window is defined as a window with no parent.
    https://docs.microsoft.com/en-us/win...ectedfrom=MSDN
    Last edited by LaVolpe; Sep 15th, 2020 at 09:58 AM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  15. #55

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by LaVolpe View Post
    I got it. I had a boolean value set incorrectly which caused the problem. I can get a form to host a control in a different context -- Eureka!!!


    Quote Originally Posted by LaVolpe View Post
    After getting that unaware listbox over to Form1, I increased DPI to 150%. The Listbox is clearly bitmap-stretched and the existing listbox on that PMV2 form was scaled perfectly via PMV2. Now we have a workaround for controls that can't be scaled for PMV2. Does required Win10.v1803+
    There will be several versions testing to perform, SetThreadDpiHostingBehavior requires 1803 and DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED requires 1809.
    If DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED is not available it will have to default to DPI_AWARENESS_CONTEXT_SYSTEM_AWARE or DPI_AWARENESS_CONTEXT_UNAWARE.

    And the PM2 was introduced on 1703, so no to bother to execute any of this code if version is less than that.

    Quote Originally Posted by LaVolpe View Post
    I'd have to search for it again, I think it was in some sort of table when comparing DPI contexts. But it was clearly stated.
    Perhaps the page was for a previous Windows version.

  16. #56
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    There will be several versions testing to perform, SetThreadDpiHostingBehavior requires 1803 and DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED requires 1809.
    If DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED is not available it will have to default to DPI_AWARENESS_CONTEXT_SYSTEM_AWARE or DPI_AWARENESS_CONTEXT_UNAWARE.
    Yepper. In my framework (which has that boolean bug), I can load a form into a different context with/without host-behavior option. If the O/S doesn't support host-behavior settings, that option is ignored. If O/S doesn't support setting GDI-scaling, then defaults to unaware since the option chosen was unaware+GDI-scaling
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  17. #57
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    FYI, here's a screenshot. Hosted listbox is top-left. Left-side of image is unaware+GDI-scaling, right-side is just unaware. Screenshot taken after moving from 100% to 150% DPI

    Name:  SShot.jpg
Views: 449
Size:  15.1 KB
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  18. #58

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Good LaVolpe, it opens the door to better awareness handling.

    Even without going into child windows specific handling, one thing that can be done is:

    For a program that is already prepared for system aware, manifest it for PM2, then if a form is about to be created in the primary monitor (or a monitor with the same DPI setting as the primary), create it as system aware, but if the form is about to be created on another monitor with different DPI setting, set the awareness to GDI_Scaling.

    If the user drags it from one monitor to another it will remain with the same awareness it has from when it was created, but users normally are not dragging windows between monitors much.
    At least in that way forms could use the best possible awareness for each case.

    Of course, if the program is ready for PM2, or at least some of the forms are, use PM2 on them.

  19. #59
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    A learning curve will be in play for managing a hosted control.

    - events are sent to the 'hidden' form; so all related code needs to go there or dim hosted control WithEvents
    - scaled position may be off as DPI changes. For example, moving back to 100% from 150%, the hosted control shifted top/left out of the client area nearly completely.
    - not sure how hosted events' mouse coordinates are received but don't expect issues. I could easily click on list items and the scrollbar buttons
    - should remember to unhost the control before form is unloaded
    - I'm sure there will be other gotchas

    However, it's still an option and handling the gotchas may not be difficult at all
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  20. #60

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    I don't know what hidden form are you talking about LaVolpe.

  21. #61
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by Eduardo- View Post
    I don't know what hidden form are you talking about LaVolpe.
    Form2 in my testing. A loaded, not-shown form. That is the form that was loaded in a different context and SetParent was used to get its listbox to Form1 from Form2. See bottom of post #52
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  22. #62

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by LaVolpe View Post
    Form2 in my testing. A loaded, not-shown form. That is the form that was loaded in a different context and SetParent was used to get its listbox to Form1 from Form2. See bottom of post #52
    Then you used Setparent I guess.

    I resumed testing, I have in mind another approach (I briefly commented before about setting a CBT hook).

  23. #63
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Yes, SetParent is how I can get a control from one Form (one dpi context) onto another Form (another dpi context). Can't use Set .Container because forms are different and there is no Set .Parent option as that is read-only.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  24. #64

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    OK LaVolpe, I want to test without changing the parent.

  25. #65
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by Eduardo- View Post
    OK LaVolpe, I want to test without changing the parent.
    Good luck with that . Definitely report back on your success/findings.

    I want to say, but am no longer 100% sure, I tried to set the thread context before creating a control. The test was like this:
    - Use an arrayed combobox, i.e., Index=0
    - Set thread context to unaware while app was PMV2
    - Create new combo: Load Combo1(1)
    - Restore thread context
    - Using similar logic, I might have even tried to create a control via VB's Controls.Add("VB.ComboBox,", "cboTest")

    If I did those tests, it was early this year or late last year, I just don't recall. And if I did those tests, it didn't work for me else I would've added the solution to my framework for dealing with controls that don't scale well for PMV2. As for the "SetParent" attempt I tried today; that was something I didn't really consider before today -- I was just thinking outside the box. But then again, I didn't really spend a lot of time on this specific topic either.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  26. #66
    Fanatic Member
    Join Date
    Aug 2016
    Posts
    597

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by Eduardo- View Post
    OK LaVolpe, I want to test without changing the parent.
    I used SetWindowLongW GWL_HWNDPARENT = -8 in some case instead of SetParent to synchronize with Owner's DpiScale.

  27. #67

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by LaVolpe View Post
    Good luck with that . Definitely report back on your success/findings.
    I found that the hosting behavior needs to be set before the host form is created and not before the hosted child window is created.

    Test project attached.
    Attached Files Attached Files

  28. #68
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by Eduardo- View Post
    I found that the hosting behavior needs to be set before the host form is created and not before the hosted child window is created.
    Some odd graphics artifacts and other observations

    - @ 100% dpi, run project & click button to use SetThreadDpiHostingBehavior
    - Change dpi to 150% (modern Win10 doesn't require logoff)
    - Checkbox scales & moves ok, but the form needs refreshing else a 'ghost' checkbox (before scaling) is still visible
    - Return to 100% dpi
    - Checkbox is rescaled ok but positioned nearly off the form towards top/left.
    - The position before scaling to 150% DPI and after returning to 100% DPI is not visually the same, not even close, and it should be the same after as was before.
    - Though not true, VB still believes the checkbox is still at 1000,1000 twips, debug.print for proof. GetWindowRect will show that the checkbox physically moved on the form.

    These are the same things I'm seeing doing the way I tried.

    Edited: I think the problem is actually with mixed contexts within VB. If you run the sample again, but choose just to display Form2 as unaware (2nd button), notice how the form jumps around after changing DPI settings. That is probably what's happening with the checkbox in the previous test.
    Last edited by LaVolpe; Sep 16th, 2020 at 09:35 AM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  29. #69

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Yes, it seems it needs some "help" after the DPI change (windows repaint, controls reposition).
    But at least it is working in principle.

  30. #70
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by Eduardo- View Post
    But at least it is working in principle.
    See my edited reply also. In principle? Yes. Practical, not yet. Likely gonna need to manually set the X,Y position of such controls after DPI changes and set it via APIs.
    Last edited by LaVolpe; Sep 16th, 2020 at 09:47 AM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  31. #71

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by LaVolpe View Post
    Edited: I think the problem is actually with mixed contexts within VB. If you run the sample again, but choose just to display Form2 as unaware (2nd button), notice how the form jumps around after changing DPI settings. That is probably what's happening with the checkbox in the previous test.
    Running the IDE unmanifested (DPI unaware as it is), I see the exact same bahavior.

  32. #72
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Oh, recall when we were theorizing that we could display some forms unaware while other forms could be PMV2. Not so simple, at least not in VB.

    That jumping around doesn't look professional at all. Last night I tried playing with it a bit. Attempted to subclass the form to prevent the WM_PositionChanged/Changing & WM_Move messages, but it still happens. I spent like 15 minutes playing; that's all. Don't know if VB is doing a move while Windows is also. Don't know if Windows is passing messages directly to the class procedure or some other actions are being done by the O/S. I think that jumping (double moves with what appears to be a 8,31 difference between moves), is flat out ugly.

    Edited: Oh, wow. Didn't get your drift, now I do. Yes, that looks like default behavior for unmanifested projects. Yuck.
    Last edited by LaVolpe; Sep 16th, 2020 at 09:52 AM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  33. #73

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by LaVolpe View Post
    That jumping around doesn't look professional at all.
    I think that it has nothing to do with mixed content, as I said in my previous message.

    That's seems to be something that VB does for any program when the DPI is changed.

    Just test: run the IDE unaware (the original exe -or manage to run it unaware if you use an external manifest-), start a new project, run.
    Change the DPI setting. The form jumps.

    I didn't test the program compiled to see if the same happens. (*)

    Quote Originally Posted by LaVolpe View Post
    Last night I tried playing with it a bit. Attempted to subclass the form to prevent the WM_PositionChanged/Changing & WM_Move messages, but it still happens. I spent like 15 minutes playing; that's all. Don't know if VB is doing a move while Windows is also. Don't know if Windows is passing messages directly to the class procedure or some other actions are being done by the O/S. I think that jumping (double moves with what appears to be a 8,31 difference between moves), is flat out ugly.
    WM_WINDOWPOSCHANGING?

    (*) Edit: tested compiled: it seems to happen to every VB program when it is DPI unaware and the DPI is changed.

  34. #74
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    While you were replying, I edited my reply. Your notes didn't register right away.

    Maybe that double sizing due to unawareness is related to GetWindowPlacement values? Might play with SetWindowPlacement later. For example, the cmd prompt window is unaware and doesn't behave like VB; so maybe there is an 'easy' fix; however, rarely is anything easy with VB nowadays.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  35. #75

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    I would try subclassing the WM_WINDOWPOSCHANGING message and replace the X and Y in the WINDOWPOS structure with the right values.

    Otherwise to try to change it after the position was already changed would be too late.

    Edit: the problem is how to know when to subclass or change them, because it is not in every form move, but when the DPI was changed. But the windows that are DPI unaware does not receive the WM_DPICHANGED message.

    Perhaps it is needed a helper hidden window to receive that message (or WM_GETDPISCALEDSIZE), and the program must be manifested for PM2.

  36. #76
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    The values for WM_WINDOWPOSCHANGING were correct in every message & several were triggered. The X,Y and size didn't change in any one of them. But a WM_MOVE was posted with the X,Y offset to what looks like a static -8,-31 difference, regardless of the DPI change. Then afterwards the window is repositioned again correctly. When I subclassed for WM_MOVE to prevent VB from getting it, the double move still happened. There may be direct communication between O/S and the DefaultWindowProc?
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  37. #77

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Try WM_MOVING instead. WM_MOVE happens when the window was already moved.

  38. #78
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Quote Originally Posted by Eduardo- View Post
    Try WM_MOVING instead. WM_MOVE happens when the window was already moved.
    That message didn't come to VB. I was using Spy++ on the form.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  39. #79

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    Yes, it does not come upon the DPI change (but it comes moving the form normally).

    The list of messges that I get when the DPI changes are:

    Code:
    WM_GETICON    H7F
    WM_SETTINGCHANGE            H1A
    WM_GETDPISCALEDSIZE              H2E4
    WM_WINDOWPOSCHANGING        H46
    WM_GETMINMAXINFO            H24
    WM_DPICHANGED              H2E0
    WM_WINDOWPOSCHANGING        H46
    WM_NCCALCSIZE H83
    WM_NCPAINT    H85
    WM_GETICON    H7F
    WM_ERASEBKGND H14
    WM_WINDOWPOSCHANGED         H47
    WM_MOVE       H3
    WM_SIZE       H5
    WM_WINDOWPOSCHANGING        H46
    WM_GETMINMAXINFO            H24
    WM_SETTINGCHANGE            H1A
    WM_WINDOWPOSCHANGING        H46
    WM_GETMINMAXINFO            H24
    WM_SETTINGCHANGE            H1A
    WM_DISPLAYCHANGE            H7E
    WM_????              HC06A
    WM_GETICON    H7F
    WM_WINDOWPOSCHANGING        H46
    WM_GETMINMAXINFO            H24
    WM_SETTINGCHANGE            H1A
    You can see that the WM_WINDOWPOSCHANGING comes five times
    I didn't check the params values.

  40. #80
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Proof of concept for handling DPI per monitor V2 transparently... or almost

    You got that with an unaware-context? I didn't see WM_GETDPISCALEDSIZE or WM_DPICHANGED in my tests. Or are those from moving to another monitor while unaware too?
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

Page 2 of 3 FirstFirst 123 LastLast

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