Posts 1 - 10 of 13
First | Prev. | 1 2 | Next | Last
|
|
|
|
aweber
Posts: 83
Joined: 2013-11-21
|
This seems trivial and I don't know why I am getting the wrong values...
I simply want to know my Form Control's actual width when displayed in an Inspector.
If I use "Me.Width" I get a large number that is probably actually 2x what is currently displayed in the inspector. I do not know what that corresponds to, but it is _not_ the width of the form at runtime.
Me.Height seems correct though.
I am trying a hack/workaround to a control that does not dynamically scale properly and I am simply wanting to check if my Forms.MonthCalendar is fully shown in the region (not clipped or scrollbars required). But I can not compare the control's Right boundary to the form's width...because I have not been able to accurately determine the visible width!
Please advise what I missed here?
Thanks,
AJ |
|
|
Posted 23 Jul, 2019 15:24:21
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18825
Joined: 2006-05-11
|
Hello AJ,
Do you want to scale a Forms.MonthCalendar on monitors having different DPIs?
Can you provide a sample project showing what you do?
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 24 Jul, 2019 05:49:43
|
|
Top
|
|
|
aweber
Posts: 83
Joined: 2013-11-21
|
We have users who have laptops with external monitors attached...sometimes. We have not isolated how to re-create the issue exactly, but if the users use our form with multiple monitors running, the form seems to display properly. When they switch configurations - not dynamically, just take their laptop home and work with just the laptop's screen - the form does not display properly.
Because they are not actually moving the form between monitors, nor are they changing the monitor's display settings while the add-in is running, we do NOT get any DPIChanged events from ADX...and that is correct, it is not changing while the form is running.
It may be that the form is saving some kind of size/location info on each use and when you switch from one set of monitors to a different configuration, that is an invalid set of metrics. Still not sure.
Most of the controls scale pretty well. The MonthCalendar is a known control that was not improved until .Net 4.7 and even then, it requires some "opt in" settings in the manifest...and then it appears that Office 2016/19 does not adhere to the PerMonitor, etc. DPI enhancements thoroughly.
I moved the calendar to be the last control on my form, and my intended "hack" is to simply determine if its right/bottom is off the form's display area (or causing scrollbars) when the form is Shown. If it is not fully on the form, I want to dynamically resize my form/region on the Inspector to accommodate showing it. In tests on a user's machine, it is usually only clipped by a 10-12 pixels...but I assume this could change depending on each user's DPI and multi-monitor settings.
So while I would love to see some code that actually forces the .Net 4.0 (or even 4.5/4.6) control to scale properly (I know we can retrieve the form's "DPI" property to help), I am simply looking to implement this work-around and be done with it for now.
I think I can do this if I can determine what the actual Width of the displayed form/region is...but as I said in my OP, the integer being returned is way off of actual, displayed size. |
|
|
Posted 24 Jul, 2019 07:29:52
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18825
Joined: 2006-05-11
|
Hello AJ,
We *suppose* that when you try to get the Width, the DPI context is different from the context in which the pane (and the control) was created. To bypass this, try this:
1) GetWindowDpiAwarenessContext(HostHandle) and compare it with GetThreadDpiAwarenessContext()
2) if these return different values, set the correct context: SetThreadDpiAwarenessContext(GetWindowDpiAwarenessContext(HostHandle))
Note that these functions aren't available in Windows versions before Windows 10 version 1607. Also, you may want to check descriptions of these functions at https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-improvements-for-desktop-applications.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 24 Jul, 2019 09:31:23
|
|
Top
|
|
|
aweber
Posts: 83
Joined: 2013-11-21
|
When I debug my form via Visual Studio...on the same machine as I have designed the form, the initial width is roughly 2x the "Size" and "Minimum Size" (which are set to the same values).
I know this Inspector is not visually the size it is reporting (Me.Width). It is saying the form is 1492 wide - my display is 1920, and the form absolutely does not take-up more than 1/3 of the width.
Why is Me.Width (the form) reporting an incorrect value? |
|
|
Posted 24 Jul, 2019 09:49:56
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18825
Joined: 2006-05-11
|
Hello AJ,
aweber writes:
Why is Me.Width (the form) reporting an incorrect value?
API functions returning the window size work incorrectly, if the current DPI context is different from the DPI context in which the form was created.
On how to deal with this, please check my previous message.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 25 Jul, 2019 05:26:45
|
|
Top
|
|
|
aweber
Posts: 83
Joined: 2013-11-21
|
OK, forgive me. Your post seems to have some APIs to switch the thread's DPI resolution.
Is it "safer" to retrieve form Height and Width immediately after calling the SetThreadDPIAwarenessContext() ? Are you saying that I should get the right value after issuing those APIs from there forward (while that form exists)?
ALSO: Is it possible to include these pinvoke functions in my project/source if I need to support Windows 8.x? They would not exist in the supporting DLLs. I can determine whether I'm running a Win10 version that allows for it at run time, but would my add-in "blow up" if I try running on Windows 8, just because the DllImport is specified in the class (but never called)? |
|
|
Posted 25 Jul, 2019 08:00:08
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18825
Joined: 2006-05-11
|
AJ,
It is safer to execute that code block before you call these properties. The idea is to set the correct DPI context.
As to your other concern, could you please check whether this approach works at all?
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 25 Jul, 2019 10:07:59
|
|
Top
|
|
|
aweber
Posts: 83
Joined: 2013-11-21
|
The WindowDpiAwareness and ThreadDpiAwareness are the same in my tests.
Therefore, this will not have any effect on the form's width being reported incorrectly.
Is this not a bug? When I get ADXOlForm.Width and it does not return the correct value, that would be a bug in the ADX code, right?
As an additional test, I logged the ActiveExplorer.Width, which is (visually) about 2-3x the width of my shown Inspector with my form...the Explorer.Width = 1389. There is no way my Form's width can be 1492. |
|
|
Posted 25 Jul, 2019 11:13:11
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18825
Joined: 2006-05-11
|
Hello AJ,
This property originates form the .NET Framework. We don't override it.
Can it be that the form is developed using a given DPI (say, 100) and you use it on a monitor with a different DPI (say, 125)?
Is this issue reproducible using a simple add-in project?
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 26 Jul, 2019 04:42:35
|
|
Top
|
|
|
Posts 1 - 10 of 13
First | Prev. | 1 2 | Next | Last
|
Forums
Topics
Search
Help
Login
Register