-
Sep 16th, 2020, 10:53 AM
#81
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Originally Posted by LaVolpe
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?
Sorry, that was with PM2 context. I'll test unaware now.
These are the messages the form gets when it is DPI unaware and the DPI setting changes:
Code:
WM_SETTINGCHANGE H1A
WM_WINDOWPOSCHANGING H46
WM_GETMINMAXINFO H24
WM_WINDOWPOSCHANGED H47
WM_MOVE H3
WM_DISPLAYCHANGE H7E
WM_SETTINGCHANGE H1A
WM_WINDOWPOSCHANGING H46
WM_GETMINMAXINFO H24
WM_SETTINGCHANGE H1A
WM_???? HC06A
WM_GETICON H7F
WM_WINDOWPOSCHANGING H46
WM_GETMINMAXINFO H24
WM_SETTINGCHANGE H1A
Three WM_WINDOWPOSCHANGING
Last edited by Eduardo-; Sep 16th, 2020 at 11:01 AM.
-
Sep 16th, 2020, 11:18 AM
#82
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Checked the position of WINDOWPOS that comes in lParam, always the same.
BTW: this time I got four WM_WINDOWPOSCHANGING instead of three , all with the same coordinates.
-
Sep 16th, 2020, 11:19 AM
#83
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Wonder what those magic offset numbers are? We figure that out and the form double-moving-issue is history.
P.S. You chose to create controls dynamically in unaware context while I used a separate, hidden form. Pros/Cons:
1. Pro your method: no secondary form
2. Pro your method: control is on the parent/form
3. Con your method: Need to use WithEvents for created controls else use dummy zero-index controls to Load from. More difficult if a control has read-only, design-time only properties that need to be set
4. Con your method: makes applying to ocxs more difficult without using a dummy zero-index to Load from. Controls.Add not very useful for ocxs, especially if you want design-time properties cached with the control
5. Con your method. Up to 2x the controls needed if Load is used for control-creation. Each ocx with different cached properties will need its own dummy zero-index control. Setting properties @ runtime isn't ideal & kinda defeats the convenience of configuring ocxs @ design-time
1. Con my method: secondary form
2. Con my method: SetParent needed, events handled on parent form, not display form.
3. Pro my method: design-time properties not a problem since control is not loaded dynamically
4. Pro my method: ocxs with cached properties not a problem since control is not loaded dynamically
5. Possible con for my method (not tested). If display form is dragged to another monitor with different DPI, does the hosted control from the other form get scaled too? Its parent form is not on that other monitor. If this is the case, then my SetParent method is potentially down the drain without serious effort applied.
Edited: Odds are that these multi-context solutions will be used only for ocxs since intrinsic controls scale well for PMV2.
Last edited by LaVolpe; Sep 16th, 2020 at 11:45 AM.
-
Sep 16th, 2020, 11:46 AM
#84
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Loading with Controls.Add was for posting a test program here (as simple as possible), I'm planning to hook the forms/controls creation on the fly.
I already acchieved that, but not in the way I thought that could be.
I tried with a CBT hook, but when I get the CBT_CREATEWND hook message that tells that a window is about to be created it is already too late. The window still didn't receive the WM_CREATE message but it iseems that the creation parameters are already set and changing SetThreadAwarenessContext at that instance has no effect on the window.
I would like to know a way to get that notification, because VB don't tell you "hey, I'm about to create Form2", or "I'm about to create Check1 on Form2". It would be nice if there was a way to get that.
I thought about posting the question if someone knows how (not much hope about that, but who knows, perhaps someone has the trick).
What I had to do is to hack the CreateWindowEx API (somewhat a hook). And it worked.
I'll post a text project when I have something more or less working.
Last edited by Eduardo-; Sep 16th, 2020 at 11:53 AM.
-
Sep 16th, 2020, 11:55 AM
#85
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
The form creation must occur before the controls, correct? Well, once you get that CBT hook notification that a top-level window is being created, couldn't you set thread awareness at that point, which should then apply to the all the controls that are created thereafter? You'd have to know when to restore thread awareness after last control is created. And that should occur after your call to Load FormX (or FormX.Show). Just thinking out loud. But I'm thinking maybe you want something more automated? You probably don't want your ocx to have to be told: "Hey I'm loading a form now & want it to be mixed-mode context/hosting compatible".
Otherwise, as for WM_CREATE/WM_NCCREATE, you are correct. The window is already created, just not 'finalized' yet. In fact, via WM_CREATE, one can cancel the creation entirely.
edited: Now I'm thinking that you need this to be per-control type of notification?
Last edited by LaVolpe; Sep 16th, 2020 at 12:06 PM.
-
Sep 16th, 2020, 12:22 PM
#86
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Yes, I need this because for the forms I don't want the host program having to tell "I'm going to load a form", and for the controls because I want to handle the awareness of each one individually and the host program could not tell me when it is going to create a new child window.
-
Sep 16th, 2020, 12:31 PM
#87
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
So how is your UC going to be organized? One for the entire project, hosted on the main form? One per form?
-
Sep 16th, 2020, 12:55 PM
#88
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Originally Posted by LaVolpe
So how is your UC going to be organized? One for the entire project, hosted on the main form? One per form?
One UserControl per form, but there will be some calls that need to be done before any form that needs special handling loads:
The Global class has this code so far:
Code:
Public Enum DHDPIAwareness
dhDADefault
dhDAUnaware
dhDASystemAware
dhDAGDIScaling
dhDASystemAwareAndGDIScalingOnNonNativeDPI
dhDAPerMonitorAware
End Enum
Public Sub EnableDPIHandlingPerForm(Forms As Object, Optional DefaultFormsAwareness As DHDPIAwareness = dhDAPerMonitorAware)
mGeneral.EnableDPIHandlingPerForm Forms, DefaultFormsAwareness
End Sub
Public Sub SetFormDPIAwareness(FormName As String, Awareness As DHDPIAwareness)
mGeneral.SetFormDPIAwareness FormName, Awareness
End Sub
It is a Global Multiuse class (auto instancing, not needed to be explicitely referenced).
The host program need to call in the Sub Main or the Form_Initialize of the first form, or whenever wants to start any special form handling like this:
Code:
EnableDPIHandlingPerForm Forms
Then, for example, it can add:
Code:
SetFormDPIAwareness "Form2", dhDAGDIScaling
Form2, in any instance of it, will be GDI_Scaled.
But the host program can change that at any time with other call to SetFormDPIAwareness.
The EnableDPIHandlingPerForm call, sends the Forms collection for the component to be able to individualize later what form is about to be created. I also set the CreateWindowEx hook upon receiving that.
There is an optional parameter, DefaultFormsAwareness that sets what will be the default awareness for all the forms that are not explicitely set. If not set, its default is dhDAPerMonitorAware (PM2).
Then with as many calls of SetFormDPIAwareness as needed, the host program can set specific awareness for each form that need to be handled with other awareness than the default set in EnableDPIHandlingPerForm (EnableDPIHandlingPerForm needs to be called first to any SetFormDPIAwareness).
That's the idea, already more or less working. But now I'm distracted trying to fix the form jumping of unaware forms that you discovered.
-
Sep 16th, 2020, 02:07 PM
#89
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Well, I could not fix the jump, I'll leave that.
-
Sep 16th, 2020, 02:15 PM
#90
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
It is something of the Windows scaling system. I see the same behavior in other non DPI aware programs (that I don't think they are made in VB6).
-
Sep 16th, 2020, 03:11 PM
#91
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
But not in the cmd prompt window, which is unaware. But that's a Windows app & they may have workarounds built in. I'm curious as to why it appears on my machine a constant offset of -8, -31, regardless of DPI change. I'm still going to try to see if I can track it down. The multiple paints that occur when you try to compensate by moving the control after DPI changes looks ugly too.
-
Sep 16th, 2020, 03:24 PM
#92
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Originally Posted by LaVolpe
But not in the cmd prompt window, which is unaware. But that's a Windows app & they may have workarounds built in. I'm curious as to why it appears on my machine a constant offset of -8, -31, regardless of DPI change. I'm still going to try to see if I can track it down.
I don't see that -8,-31, it seems much more here.
But I repeat: I experience the same behavior on any other unaware program (not tested the cmd, but as you say it can have some special fix).
Originally Posted by LaVolpe
The multiple paints that occur when you try to compensate by moving the control after DPI changes looks ugly too.
I only saw the ghost CheckBox so far and the off coordinates coming back from the second monitor. Seems to be something that should go away by positioning the controls correctly and redrawing the form (my first attemp would be Me.Refresh).
But I'm still not working on these issues.
-
Sep 16th, 2020, 03:35 PM
#93
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Are you sure that cmd is unaware? How to know that?
I see it quite crisp.
-
Sep 16th, 2020, 04:40 PM
#94
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Originally Posted by Eduardo-
Are you sure that cmd is unaware? How to know that?
I see it quite crisp.
Probably using GDI-scaling?
In task manager, details tab, right click on one of the tabs and choose "Select Columns". Scroll more towards bottom of popup window and find/check "DPI awareness". Close popup window and find the cmd prompt in the listing. You should see "unaware" under that column.
Not sure which version added that column; thinking v1809?
-
Sep 16th, 2020, 05:00 PM
#95
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Yes, I see. But it is a 64 bits process, it might behave different perhaps?
-
Sep 16th, 2020, 05:21 PM
#96
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Now I'm wondering why they implemented this hosting behavior APIs instead of just setting all the PM2 parents windows to mixed awareness for hosting the child windows.
Is it slower?
Can it cause issues?
-
Sep 16th, 2020, 09:38 PM
#97
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Given up on trying to get the double move to stop. On my system, the double move is very evident. On a newer system, the double move is so fast that if you weren't paying attention, you wouldn't even notice it. So, gonna look bad on slower systems and bearable on faster ones.
Now, regarding hosting behavior. I wanted to see what would happen if I hosted an external application that was unaware. My IDE is PMV2. So, I ran a test project and then loaded VB's OLE/COM Object Viewer. That app is unaware, 32 bit vs. 64 bit, and is not based on VB classes. Using SetParent, I attached it to my test form, then began changing DPIs. As expected the hosted OLE Viewer was auto-scaled since it is DPI-unaware. But more importantly, it suffered from the same offsetting as your checkbox example and my previous tests.
In summary, I'm leaning towards SetThreadDpiHostingBehavior not being quite ready for prime time; though still open to the possibility that this is a VB internal issue when mixed awareness contexts are in play. Could probably rule one of those out if motivated.
And if curious... I posed a question whether a hosted control from a hidden form would scale if moved to another monitor with different DPI while the actual parent form was on the other monitor. The answer is yes, it scales.
-
Sep 17th, 2020, 02:35 PM
#98
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Hello, I came to the conclussion that VB is not suitable to have forms with custom awareness of Unaware and GDIScaled when it is manifested for Per monitor V2.
1) UserControls don't even show up.
2) UserControls report same Parent.ScaleWidth that you get on the form itself at the ReadProperties event, but different Parent.ScaleWidth at its Show event (and anytime after). At the same time at the form Me.ScaleWidth reports right.
It is weird that you get a value on the form, Me.ScaleWidtn and a different one in the UserControl with UserControl.Parent.ScaleWidth at the same moment.
(In a form that is shown Unaware, full unaware, nothing mixed)
3) In UserControls, when the Parent.ScaleWidth is already changed, if you read a property of a control that is on the parent, like Parent.Controls("Text1").Left it reports right (according to the ScaleWidth that is read in the form itself), but when you set the same value that you can get reading the property, for example if Parent.Controls("Text1").Left reports 1200, if you set Parent.Controls("Text1").Left = 1200 it is set to a scaled value according to the wrong (or changed) ScaleWidth that you can read in the UserControl with Parent.ScaleWidth.
It is very weird that you read some value but setting the same value sets it changed.
Also, non-windowed controls seems not to have the same issue, to add more weirdness.
4) Forms size and position are scaled by Windows without considering what DPI they were originally set, Windows assumes that if they are unaware then they are for 96 DPI. You are not able to set the original intended DPI.
But manifesting VB (or the exe) as DPI aware (or DPI aware per monitor V2 like this case), VB is DPI aware per nature, then when it creates the form, it already creates it for the DPI that it was started (system aware).
For example if you are on 120 DPI and start the compiled program (or the VB IDE and load the project in source code), as long as the exe or the IDE is manifested at least for system aware, as long as you works in Twips, it scales everything.
So if the program starts at 120 DPI, everything is already set for 120 DPI, but showing a second form as DPI unaware or GDIScaled, Windows scales everythign again, resulting in a bigger form than it should be.
Also the positions of the Forms are changed, even setting them with API are changed or scaled by Windows.
I think they should work in the current awareness of the thread and not in the awareness that the window was created (as they are parent windows).
That makes no sense to me, if you want to position a window with one awareness close to a window with other awarenss, you'll have to figure the conversion, that makes no sense.
Also GDIScaled has a different displacement than Unaware, I didn't incvestigate in details what could be the logic of that.
5) In forms created Unaware or GDIScaled (always talking with VB manifetsed as PM2), when they have an UserControls (that does not show anyway as I said), you can't close the form, but not always, sometimes you can and sometimes not.
So my conclussion, is that at best it could be usable for mixing PM2 and system aware, but not the other awareness.
Still not played with the hosting behavior to see if they can be mixed in controls or not either.
But these APIs seems to me buggy so far. Or VB is not suitable for this.
-
Sep 17th, 2020, 02:52 PM
#99
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
In short:
When an app starts with DPI awareness, and some windows are created unaware (or GDIScaled that is other way to show windows that are unaware), Windows perform conversions always to 96 DPI for those specific windows regardless you are positioning parent windows, controls or whatever.
The app itself compute differently the values because it is DPI aware, and also API calls to parent windows (forms) that are DPI aware report other position values (right) than the ones that are unaware.
This issue does not seem to be specific of VB.
To mix windows with context to Unaware or GDIScaled in an app that is DPI aware does not seem a good idea for any app, not only VB.
Only mix system aware with PM2.
-
Sep 17th, 2020, 03:19 PM
#100
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
If at some point MS decides to add an API "SetThreadNativeDPI" or something like that to set the conversion relation with the app instead of assuming 96 DPI, these other awareness could be used too.
-
Sep 17th, 2020, 07:36 PM
#101
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
I've looked over you last few replies and can see some definite problems. I plan on playing with this over the weekend. Regarding the sizes and positions reported from the UCs to/from the form, there may be reasons, some beyond our control without significant effort.
API methods are in the context of the thread's awareness. That is documented. And there are several DPI-related APIs that should be used instead of the unaware versions of the same APIs, i.e., GetSystemMetricForDpi, AdjustWindowRectExForDpi, and more. But that's just one point where we can see problems.
I think another one could be the COM interfaces themselves. COM seems to use himetrics as a preference in many of their interface methods when size/position applies. Are those values being scaled between the parent & UC? Outside of VB, do other prominent coding languages use COM for top-level windows and typical controls? Rhetorical.
Though I am less interested in a PMV2 VB form correctly hosting an unaware control, it would be nice if it worked as one would expect. If it doesn't, it doesn't. I'm more interested if an unaware form can properly interact within a PMV2 application. In many cases, forms don't need to query each others X,Y and size and/or those properties of its controls. Exceptions obviously apply, for example centering one form over another, or aligning them end-to-end. If these forms work fine, then at least that option can be used to display popup forms with unscalable controls with form/controls all being in the same awareness: unaware/GDI-scaling.
-
Sep 17th, 2020, 09:18 PM
#102
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Originally Posted by LaVolpe
API methods are in the context of the thread's awareness.
Not true. Not aware and GDI scaled convert scales always to 96 DPI as I mentioned.
It should be in the thread awareness to be usable. That is the logical thing and what one would expect.
Originally Posted by LaVolpe
That is documented.
Where? May be, but still not true.
Originally Posted by LaVolpe
And there are several DPI-related APIs that should be used instead of the unaware versions of the same APIs, i.e., GetSystemMetricForDpi, AdjustWindowRectExForDpi, and more. But that's just one point where we can see problems.
Even using something like SetWindowPosForDPI if that existed, the host program would use normal APIs to handle windows, and so VB.
So the solution would be for Windows not to assume 96 DPI for unawarness and use the thread system awareness and the DPI in what the app started instead, or, otherwise, let you set the DPI for the conversions to other than 96.
May be they fix that adding some APIs in the future. This is not a problem of VB only.
I think they used the scaling system that they had already developed for unaware apps to make these new APIs, but mixing windows with different awareness is something that should be handled different than the whole program unaware, and they act for the unaware windows as the whole program was unaware.
It is like the APIs are flawed or not finished.
Originally Posted by LaVolpe
I think another one could be the COM interfaces themselves. COM seems to use himetrics as a preference in many of their interface methods when size/position applies. Are those values being scaled between the parent & UC? Outside of VB, do other prominent coding languages use COM for top-level windows and typical controls? Rhetorical.
I didn't test something of COM, but I guess it must probably be the same problem as all the other: VB (the process, the thread) is set to some DPI and Windows, for the virtualized windows convert all the coordinates of these virtualized windows for the host program as it was at 96 DPI.
In other words: it is like that all the operations regarding those unaware windows are converted as if the whole program was manifested unaware.
Originally Posted by LaVolpe
Though I am less interested in a PMV2 VB form correctly hosting an unaware control, it would be nice if it worked as one would expect. If it doesn't, it doesn't. I'm more interested if an unaware form can properly interact within a PMV2 application.
That's exactly the problem I described in my messages: unaware forms cannot property interact within a PMV2 application.
I didn't even begun experimenting with controls (controls unaware in a form aware). All I'm talking is about forms, whole forms with the same awareness.
Suppose you manage to do all the conversion, even when VB tells you same value that it has calculates for one DPI setting that will be the one the program started, but when you set back the same value Windows convert it to 96 DPI (that's the most weird thing I found -reading a property reads some value, but setting the same value to the same property and at the very moment, sets a value converted. If you read it back it is not what you put-).
Let suppose that with much effort that could be handled, still there is something that can't: UserControls don't even show up on unaware forms, and randomly they hang the form. If there is no fix for that, unaware forms are unusable.
So no, a PMV2 manifested app can't show unaware forms (And if you want to have them, then not use any UserControl and manage to convert that weirness of coordinates. For me that is a no).
Originally Posted by LaVolpe
In many cases, forms don't need to query each others X,Y and size and/or those properties of its controls. Exceptions obviously apply, for example centering one form over another, or aligning them end-to-end. If these forms work fine,
Centering should work, aligning shouldn't. Unaware forms use changed coordinates. If you want to show an unaware form sticked to a (normal) PMV2 aware form, it will appear far from it, how much depending on the DPI VB was started.
Originally Posted by LaVolpe
then at least that option can be used to display popup forms with unscalable controls with form/controls all being in the same awareness: unaware/GDI-scaling.
Just use system aware. System aware should scale the forms and dialogs normally on different DPI.
There is really no much point is wanting to have unaware forms and GDI scaled forms (that are also unaware, scaled in an improved way).
Unless the user always starts the app at 96 DPI, they won't show right, because as the app is manifested for PMV2, VB will automatically scale any form by itself when reading the stored properties, and after that Windows will scale everything again.
What are you trying to fix with unaware forms? The errors that VB can make scaling? They are already made, because VB already scaled the forms.
And worse: Windows scale the forms again, that why you can see they are bigger than PMV2 forms of the same size.
-
Sep 17th, 2020, 09:32 PM
#103
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
The more I think the more I realize that showing anything unaware or GDI scale (that is also unaware), any form or control, has no point at all in VB, because VB is already DPI aware.
That awareness options only make sense in VB for the whole program manifested for that awareness, but not per form or control.
The only mix useful or needed is PMV2 (the default, because the program need to be manifested for PMV2) with system aware.
If a control has issues when scaled, set it to system awareness.
As I said I still didn't experiment with controls, but I think that must work. With forms that mix seems to work so far.
-
Sep 17th, 2020, 09:41 PM
#104
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Mixing aware with unaware windows may be useful for other languages that are DPI unaware, but not for VB because VB is DPI aware.
It was DPI aware when it was created in the 90', and worked DPI aware until Windows XP.
It "become" unaware because from Vista+ you need to add a manifest to explicitely say a program is DPI aware, but if it wasn't for that, VB is DPI aware if you work in twips (OK, some things are not handled automatically: images).
Edit: yes, there is an advantage of using unaware forms: that all the images are scaled automatically without the framework or the host porgram doing anything, but as I said: even if you manage to convert all the weirness of the coordinates, there is the issue of the UserControls: the unaware form should not have visible UserControls.
Last edited by Eduardo-; Sep 17th, 2020 at 10:03 PM.
-
Sep 17th, 2020, 10:19 PM
#105
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Originally Posted by Eduardo-
Mixing aware with unaware windows may be useful for other languages that are DPI unaware, but not for VB because VB is DPI aware.
VB may be aware, but not all controls (ocxs) are. Many VB built controls and apps aren't even system-DPI-aware because coders do things like hardcode 15 twips per pixel. But that's the fault of the coder, not VB. VB isn't truly system-DPI-aware, but mostly. If it were, we wouldn't have to jump over hurdles trying to get ocxs to scale correctly in non-integral DPI.
What am I trying to accomplish? Just seeing if there is a reliable workaround for displaying controls that cannot be scaled properly due to DPI changes and without forcing an application to abandon the control or resort to non-PMV2. I think you kinda proved that retro-fitting some existing application will require lots of work and may not be doable in all cases without potentially tearing parts of the application down and rebuilding it?
P.S. In one of my replies, I mentioned that API calls were in the context of thread awareness. I misspoke and generalized too much. Here are some notes from MSDN regarding mixed-mode DPI & SetThreadDpiAwarenessContext
- Any API calls that are made after the context is changed will run in the corresponding DPI context (and may be virtualized).
- When the window procedure for a window is called, the thread is automatically switched to the DPI awareness context that was in use when the window was created.
I'm not really sure how to interpret that first bullet & may just be another case of MSDN not making things clear. Is it saying that an unaware form in PMV2 makes API calls in PMV2 because that's the current context? Hoepfully not. If so, then a form needs to change thread context to unaware before calling APIs? That would be difficult to accomplish since VB makes lots of API calls on our behalf I would imagine
Last edited by LaVolpe; Sep 17th, 2020 at 10:23 PM.
-
Sep 17th, 2020, 10:34 PM
#106
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Originally Posted by LaVolpe
I think you kinda proved that retro-fitting some existing application will require lots of work and may not be doable in all cases without potentially tearing parts of the application down and rebuilding it?
So far I could say that if the app is already DPI system aware, it could be moved to PMV2.
I still didn't play with mixed hosting (having some unaware controls on an aware form), perhaps that works, but I suspect that there will be the same coordinate problems.
Originally Posted by LaVolpe
P.S. In one of my replies, I mentioned that API calls were in the context of thread awareness. I misspoke and generalized too much. Here are some notes from MSDN regarding mixed-mode DPI & SetThreadDpiAwarenessContext
- Any API calls that are made after the context is changed will run in the corresponding DPI context (and may be virtualized).
- When the window procedure for a window is called, the thread is automatically switched to the DPI awareness context that was in use when the window was created.
Yes, the conversions are made in the awareness of the window, not the thread.
That was a wrong decision IMO. In a mixed program the coordinates system should be the same for all the thead, and the awareness should have only visual effects.
Edit: or at least to have that option. Perhaps other environments (C++) need it as it is now.
Last edited by Eduardo-; Sep 17th, 2020 at 10:41 PM.
-
Sep 19th, 2020, 04:44 PM
#107
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
I found that with the hosting behavior changed to mixed mode, if I create a control DPI unaware or set to GDI Scaling, the form enlarges and its coordinates are virtualized.
Also, any other control created after that, is created with the same awareness as this control (unaware or GDI Scaled), being the original awareness set back already to the thread after creating the unaware control.
These APIs doesn't seem ready to be used.
Perhaps they may be used only mixing PMV2 and system aware, or at least for forms.
Last edited by Eduardo-; Nov 26th, 2020 at 03:45 AM.
-
Sep 20th, 2020, 12:15 PM
#108
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
I don't think I'm going to continue with this, too complex and see no clear goal.
Anyway people already have your framework.
Good luck.
Well, the framework is targeted at new applications, not existing ones.
Regarding mixed-mode, ocxs not appearing on forms loaded into unaware/GDI-scaling context while overall thread is PMV2 is a deal-breaker. Any attempts by me to enable mixing modes would have been directly related to using ocxs (as unaware) that cannot be scaled to PMV2 due to lack of support within the compiled ocx. Well, if the ocx isn't even visible; that's an issue.
But have you tried to find out why they aren't visible in those cases? the controls don't exist -- probably failed creation. This also appears, with very little testing, to only apply to VB-created UCs. For example, the RTB ocx shows up.
edited: the control is created, didn't fail. It was parented under a different hWnd than the form -- go figure. I had to debug.print the hWnd, then look for it in Spy++
note: testing was in IDE only; not compiled
Last edited by LaVolpe; Sep 20th, 2020 at 12:29 PM.
-
Sep 20th, 2020, 12:38 PM
#109
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
When it comes to dealing with High DPI (either taking it head-on by using one of the forms of DPI Awareness or falling back on GDI Scaling), I try to test at 200, 175, 150, and 100%. The reasons are both VB/OLE issues that are masked at some settings, and differences in how GDI Scaling works under different settings.
That can be painful. Throw per-monitor into the mix and it can be even more so.
I've dropped down to testing at 200, 150, and 100 but I'm not sure using fewer settings gives reliable results.
I don't see much mention of specific settings for the testing described above.
-
Sep 20th, 2020, 12:43 PM
#110
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
@dilettante, if entire project is in same DPI, all issues can be handled regarding intrinsic controls, and many known common-use ocxs. In the replies within this thread, the scenarios that applied for me were basically:
1. Main thread is PMV2, specific forms are unaware (via changing awareness context only)
2. Main thread is PMV2, a specific control is unaware (via changing awareness context & hosting behavior)
I was not seriously considering using PMV2 intermixed with system-aware until I could get PMV2 intermixed with unawareness working. And that looks like a no-go.
-
Sep 20th, 2020, 01:14 PM
#111
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
LaVolpe, these experiments served me to come to a conclusion: controls mixed mode is unusable, for several reasons.
And for forms... it could be possible to handle the coordinates conversions in some projects but for a component intended to be automated, mixing form awareness is also unusable.
For both cases (controls and forms) you cannot even mix PMV2 with system awareness (as I supposed before).
Not even for foms because when you show a form with system awareness the coordinates to position the form are virtualized.
Yes, you could make conversions, but I don't see a way to automate that or make it transparent for the host program.
So, only PMV2 is left. I'm am at the start regarding awareness: no mixed awareness of any kind.
Well, the framework is targeted at new applications, not existing ones.
I wanted to target existing applications, thinking in that old program of mine of 80+ forms that is currently DPI unaware.
But I realized that it is even more complex that what I thought.
Changing fonts is not so easy, for example the MSFlexGris has .CellFont* properties and any cell can be set to a font individually... how to handle that? And I mean without writing code specifically for every control? Making an "scripting environment" would be cumbersome.
And in the case of the MSFlexGrid.CellFont* properties there is no stdFont object exposed to be able to use .SetRatio.
Perhaps one viable way woud be that the component make some automated tasks and after that and rises an even to the host program, so it can add whatever is needed to finish all the things that the component didn't do.
But I don't think I'll invest time on that. At least not now.
On the other hand, system aware works acceptable fine I think. Perhaps I would focus in something to help indentify what is needed to change in a program to prepare it for being system aware, an Add-In I mean.
(In any case, that would also be needed to prepare a program for PMV2 awareness).
-
Sep 20th, 2020, 09:29 PM
#112
Re: Proof of concept for handling DPI per monitor V2 transparently... or almost
Originally Posted by dilettante
I don't see much mention of specific settings for the testing described above.
The issues arise on any setting.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|