I have a cursor what the size size 128x128, but when i used LoadCursor to load and show it, it only has 32x32. Which API can make it correctly? It seems MS resize it. Thanks.
Windows XP does not include any system cursors that are larger than 32x32. (If larger cursors were included, they would be stretched down to 32x32 when the standard APIs load the cursors.)
For high-DPI systems, Windows XP has adjusted the SM_CXCURSOR and SM_CYCURSOR values to be 64x64 pixels. This size adjustment is to prevent the mouse pointer from virtually disappearing because it is too small to be effectively used. Although the other aspects of the system scale with DPI, the mouse pointer does not scale. Microsoft does not try to enforce a DPI-independent size for the mouse pointer.
The system also provides the SetSystemCursor API function that you can use to change the system cursor for specific categories. You can use this function to set a cursor of any size. However, you must call the function programmatically, and you can only use it to set a cursor for a specific category. You cannot use it to make all cursors on the system the same size.
http://support.microsoft.com/kb/307213
Don't use LoadCursor, use LoadImage() instead.
SM_CXCURSOR by SM_CYCURSOR is the only cursor size the system can currently use.
Use GetSystemMetrics to find out those values.
Related
When the LoadCursor function is used to load a cursor from a resource, the resulting HCURSOR can be used across different monitors and always appears at the correct size.
ie: typically:
on a 96 dpi monitor the 32x32 resource is used,
on a 192 dpi monitor the 64x64 resource is used.
However, when a cursor is programmatically created from memory (say using LookupIconIdFromDirectoryEx and CreateIconFromResourceEx) the resulting cursor has a fixed resolution. This means it appears at the wrong size on at least one monitor in a mixed DPI multi-monitor setup.
I also checked out the LoadCursorFromFile and it too provides this dynamic resolution behaviour like LoadCursor.
Is there a way to programmatically create a cursor that dynamically switches depending which monitor it's shown on? What magic is going on behind the scenes for cursors loaded with LoadCursor to work differently?
After much experimentation I finally discovered that WPF can load cursors from resource and memory streams and get the correct DPI behaviour if the scaleWithDpi option is used:
public Cursor(Stream cursorStream, bool scaleWithDpi)
Looking at the reference source it ends up in the function LoadFromStream which loads the stream by writing it to a temporary file and the loading from the file. See source
To sum up:
It seems the only way to get a dynamic DPI cursor like this is with the Win32 native resource loading functions and by loading from a file. It doesn't seem like you can load a cursor directly from memory with this behavior.
The "dynamic dpi" part of this behavior seems to be related to the LR_DEFAULTSIZE flag passed to the LoadImage function.
I'm using accessibility with the AccessibleObjectFromPoint function, and I'd like it to work correctly on a per-monitor DPI environment. Unfortunately, I can't get it to work. I tried many things, and the situation for now is:
My app is marked as per-monitor-DPI-aware in the manifest. (True/PM)
I use GetCursorPos and then AccessibleObjectFromPoint.
How can the problem be reproduced:
Have two monitors, one with 100% DPI, the other with 125%.
Run Chrome on the 125% monitor.
Use AccessibleObjectFromPoint on one of the tab names, it won't work.
It works with some apps (DPI-aware, it seems, like explorer), but doesn't work with others. I tried several relevant functions, such as GetPhysicalCursorPos and PhysicalToLogicalPointForPerMonitorDPI, but nothing works.
It's worth noting that Microsoft's inspect.exe works as expected.
I’ve been struggling with this exact same problem for several weeks and can now tell you my findings. Unfortunately I can’t give you more than a hint of code, because the project I am working on, is proprietary.
The issue started at Windows 8.1. The problem did not exist on Windows 7 or Vista, because AccessibleObjectFromPoint always used raw physical coordinates, as documented here: https://msdn.microsoft.com/en-us/library/windows/desktop/dd317984(v=vs.85).aspx .
“Microsoft Active Accessibility does not use logical coordinates. The following methods and functions either return physical coordinates or take them as parameters.” This has not been true since Windows 8.1.
AccessibleObjectFromPoint now uses a flawed calculation that cannot always find the correct window for reasons similar to my question here: High DPI scaling, mouse hooks and WindowFromPoint .
My findings lead me to one conclusion: The API is broken. This does not mean it is not possible though.
Possible solutions I have partially tested that seem to work follow.
Prerequisites are that you
1/. Make your process per monitor DPI aware, NOT USING THE MANIFEST (more on that later).
2/. Determine the hWnd of the window you want to query (WindowFromPoint() variants)
3/. Determine the monitor DPI of the queried hWnd
4/. Determine the DPI of your process
5/. Determine the DPI of the queried hWnd
6/. Determine the monitor origin and offset for the queried hWnd (MonitorFromWindow() and GetMonitorInfo() )
Next, depends on your platform
Windows 10.0.14393+
Write a function that finds the IAccessible (AccessibleObjectFromWindow() ) from the top level window, and then recursively call IAccessible::accHitTest until you reach the bottom-most IAccessible and perhaps ChildID data. Return that as if you would call AccessibleObjectFromPoint.
To call it successfully, you will need to scale the (x,y) co-ordinates into the scale system of the queried hWnd, using the DPIs and co-ordinates fetched in the list above. Watch out for systems where monitors are not the same size or if monitors are partially offset, or above and below.
And now for the important part for 10.0.14393 – Set your thread to the same DPI_AWARENESS_CONTEXT of the hWnd you are querying. Now call your new function. Now revert your thread to monitor DPI aware, and voila, it works, even if the window is not maximised. This is why you must not use the manifest.
If you are on Windows 8.1 to 10.0.10586 you have a tougher task.
Instead of calling accHitTest, as above, you have to recursively call AccessibleChildren and iterate the call IAccessible::accLocation to determine if your test point is within each child. This is tricky and starts to get really messy when you get to e.g. combo boxes in products like Office, which is only system DPI aware.
That’s all I can give you for now.
To do it successfully on multi-platform (mine has to work from Vista to Windows-Current) the only really safe bet is to write a wrapper DLL in C++ that can determine at runtime which OS it is on and change code path accordingly. The reason you want to do it in C++ is to avoid passing IAccessible objects across the .Net/unmanaged marshalling boundary. You can call IUnknown::Release on objects you don’t need to return n the unmanaged side. You can do it all in .Net, but it will be slow.
P.S. also watch out for Chrome returning infinite trees where parents are children of their parents, some snity checks are required. Also, Chrome does not return accRole correctly, and will give you HTML tags instead of VT_I4.
Good luck
A fairly workable solution is as follows, in your IAccessible recursive function:
Use getwindowrect to capture the physical right on main window
Use accChild.accLocation in loop to capture left and Width on each Object
Add this simple test
If l > rct2r.Right And l > arrIACC.x2 Then
arrIACC.x2 = l + w
End If
if dpi = 100 then no Object is furter out than physical right
if dpi > 100 then closebutton is...x pix offset
Use the difference to rescale all values you are in use of Width
arrIACC.w1 = CInt(((-rct2r.Left + arrIACC.w1) / arrIACC.x2) * rct2r.Right)
This solution is from an Excel plugin I have developed, I was testing the Width of the quick access toolbar qat and my result was +- 5 pixels regardless of any DPI.
What is the difference between GetDC(hwnd) and GetDC(NULL)? I understand that the latter gets a DC for the entire (virtual) screen, but I'm not sure what that means practically.
I want to set the size of an initial window based on the font in use. I use CreateFontIndirect to create the font handle but, in my opinion, only when you SelectObject that font into a DC can you use GetTextMetrics to figure out the actual height used rather than one specified. I'm going on the assumption that they may not be the same.
I would normally use GetDC(hwnd) to get a DC and select the font into it. But, given I don't have a hwnd yet, can I select a font into a DC returned from GetDC(NULL)?
Edit: Related. I guess it may make no difference! GetDC(NULL) gets primary monitor or virtual screen?
You don't own the screen DC and should not select objects into it. What you can do is use CreateCompatibleDC, passing the screen DC, to get a DC into which you can perform text metrics calculations.
I am posting here on the off-chance that someone knows why my screen size is reported as 611 instead of 600?
GetSystemMetrics(SM_CYFULLSCREEN)
returns 611. My netbook is 1024x600, so I expected 600, not 611.
Googling for 1024x611 turns up a surprising number of results, also.
from other forum threads, it seems that GetSystemMetrics(SM_CYFULLSCREEN) does not always return the exptected result. it seems to be adjusted, and may not be the value you want.
try using GetSystemMetrics(SM_CYSCREEN), which will return the size of your primary monitor.
(also, note that some people use multiple monitors: take care of not constraining your application to a single monitor)
SM_CXFULLSCREEN and SM_CYFULLSCREEN returns the size of a full screen window, so would usually be less than your screen size due to the taskbar:
The width of the client area for a full-screen window on the primary
display monitor, in pixels. To get the coordinates of the portion of
the screen that is not obscured by the system taskbar or by
application desktop toolbars, call the SystemParametersInfo function
with the SPI_GETWORKAREA value.
Compare it to what SPI_GETWORKAREA in SystemParametersInfo returns for your display? Or what is your display set to in the control panel??
A 1024x640 screen would be a true 16:10 ratio and would amount to ~ 611 y available desktop size.
I want to adjust a Static control's size to its content size, so I need to calculate the size of its text content first. I found a way to use GetTextExtentPoint32 to calculate the size, but I need to set the DC's font to the same as the control's font first. Is there a better way to do this? I've set the Static control's font once, I think maybe I don't need to set the DC's font the second time.
What is the best way to calculate the size of a Static control's text content? And is there a better way to autosize the Static control?
It sounds to me like you've already figured out the correct way to do it. Call GetTextExtentPoint32 to figure out the ideal size of the control given the text that it contains, and then resizing the control to the calculated size.
It's a lot of work, but that's what happens when you're working with the raw Win32 API. You don't have a handy wrapper library that abstracts all this for you in a Control.AutoSize() function. You could easily write your own function and re-use it, but the Win32 standard controls do not expose an "auto-size" API.
As far as the font, you will definitely need to make sure that the device context is using the same font as the control, otherwise you'll calculate the wrong size. But you don't have to create a new device context, request a handle the static control's font, and select that into your new DC. Instead, you can just use the static control's DC using the GetDC function and passing in the handle to your static control window. Make sure that if you call GetDC, you always follow up with a call to ReleaseDC when you're finished!
However, do note some caveats of the GetTextExtentPoint32 function that may interfere with the accuracy of the size you calculate:
It ignores clipping.
It does not take into account new lines (\n) or carriage returns (\r\n) when computing the height.
It does not take into account prefix characters (those preceded in the string with ampersand) and used to denote keyboard mnemonics if your static control does not have the SS_NOPREFIX style.
It may not return an accurate result in light of the kerning that may be implemented automatically by some devices.
(This is all mentioned in the linked documentation, but does anyone actually read that?)
Perhaps an easier alternative is to draw the text the same way that the static control is already doing. Unless you have the SS_SIMPLE style set (which uses TextOut or ExtTextOut to draw text as an optimization), static controls draw their text by calling the DrawText function with the appropriate parameters, given the other control styles that are set (reference).
You can do exactly the same thing, and add the DT_CALCRECT flag in your call to the DrawText function, which causes it to determine the width and height of the rectangle required to draw the specified text without actually drawing the text.
Most windows using static text controls are dialogs, where the static control's size is expressed in dialog units (DLU), which account roughly for the size of the font. In this way, dialog controls tend to have sensible sizes.
If you are not using dialogs, you can attempt to fake dialog behavior using MapDialogRect.
Otherwise yes you must use GetTextExtentPoint32.
There is no autosize for static control as far as I know. You are doing it correct.
Use GetWinDowText to get the text of static window
Use GetDC to get the dc for the window
Use WM_GETFONT to get the font for the window and select the font into the dc
Use one of the text size calculation function to calculate the text size
Restore the the original dc font
Release dc
You will always have to select the proper font into the dc to get accurate result. Also I personally prefer DrawText with DT_CALCRECT to calculate the size of a text. Refer http://msdn.microsoft.com/en-us/library/windows/desktop/dd162498%28v=vs.85%29.aspx
With DrawText, you dont have to supply the character count if the text is NULL terminated. Plus you can combine various formatting option to adjust the calculation. For example, an Ampersand(&) character in a static control text underlines the next character. With Drawtext you will be able to calculate the size properly but in GetTextExtentPoint32 there is no provision to specify this.