We have been using IHTMLStyle::put_height to set a max height for an element we use in a dialog that has the WebBrowser control in it. This has always worked for us. If the height of the element is larger than the value we send to put_height, the WBC shows a scroll bar. If our dialog is sized, the scroll bar disappears and reappears right on cue.
But customers with a 4k monitor have issues. So I acquired a desktop topology that includes a 4K monitor as my main monitor.
Like customers, I scale it to 200%. When we make the call to put_height, the height we set doesn't work properly (but get_height does return the same value). We never see scroll bars no matter how small we resize the dialog (and the WBC it contains). When
OnSize is called with the client sizes, neither SpyXX nor paint agree with the client size of the dialog nor of the WBC size we change in OnSize. I tried a number of things like passing in "Npx" (N is the height) and other units to no avail. I tried
other APIs that set the size with no luck.
Finally today I had an ideal. Before setting the height (the "cy" in OnSize) of the element, I scale it by 1/DPI setting. So if the setting is 200%, I send in cy/2. This fixes the issue with put_height I get the same "result", meaning behavior, when my 4k monitor is set to 100% or 200% (or whatever).
I never found any documentation that indicated this is what I should do. I decided to do the scaling since I know the WBC returns 200 (in my 200% dpi case) for an OLECMDID_OPTICAL_ZOOM call I made.
For our app, I set the DPI awareness to per monitor (but not "V2" as bad things happen all over the place). I see the same issue if I set it to high DPI aware (system aware).
So, is this expected? Should I actually be calling to get OLECMDID_OPTICAL_ZOOM and scaling by it before calling IHTMLStyle::put_height? Something different than either approach?
R.D. Holland