I'm using the HTMLHelp function with C to provide short, context sensitive help for the edit fields on various dialogs. It works perfectly except when the dialog is located on a monitor whose screen has negative X coordinates.
For example, I have three monitors and the top, left point on the CENTER of the three is the (0,0) point on the screen. That makes ALL X-coordinates on the LEFT screen have negative values. When I call HTMLHelp for HH_DISPLAY_TEXT_POPUP, the tooltip it displays shows up stuck to the left edge of the CENTER screen instead of on the LEFT screen, where it belongs. When the coordinate for the help popup is on the center or right screens, the popup is exactly where it should be.
Does anyone know a way to get the HTMLHelp function to work correctly and just use the given coordinates instead of applying an invalid range check and "fixing" my X location?
If not, I guess I will be forced to write my own version of a help popup function, but I'd much rather use the system feature.
Related
I noticed that the focus rectangle has changed in one of our legacy app when it works in Windows 10. It turned out that there are other old-style Microsoft apps in which we see the same effect - for example, in HTML Help Workshop. The focus rectangle must be a dotted rectangle consisting of alternating black and white dots, but we see a 2-pixel rectangle blended with the selection that looks like a red-orange rectangle:
The problem appears only on 2 computers with Windows 10, version 1909. One of them is the Pro edition, the other is the Home edition.
The focus rectangle is drawn in our app with the WinAPI DrawFocusRect function. The documentation for the DrawFocusRect function states the following:
Windows XP: The focus rectangle can now be thicker than 1 pixel, so it
is more visible for high-resolution, high-density displays and
accessibility needs.
But this does not help to understand why the problem occurs only on those 2 computers. They are equipped with normal 96dpi displays, and as I know, no accessibility options are turned on in them.
What it could be and how to fix the drawing of focus rectangle to see the traditional 1-pixel black/white dotted rectangle?
If it helps, here is an example of code used to draw the focus rectangle in our VB6 app:
Dim hBrBlack As Long
hBrBlack = CreateSolidBrush(vbBlack)
FrameRect hMemDC, rcFocusRect, hBrBlack
DeleteObject hBrBlack
SetBkColor hMemDC, lColor1
SetTextColor hMemDC, lColor2
DrawFocusRect hMemDC, rcFocusRect
Thank you all who commented my question. The situation became clear, but not in all parts of the problem. I am resuming all what we know by now in this kind of an answer.
Yes, indeed, in Windows 10 we can open Control Panel > Ease of Access > Ease of Access Center > Make the computer easier to see and find the Make the focus rectangle thicker option:
The first thing I do not understand is that why this option became checked. Simon Mourier thinks it is a carryover from a previous Windows installation, but I doubt this is true. I definitely know that at least on my dev pc nobody checked this as only me could do that. It seems that Windows decide at some point to check this option itself depending on some system parameters.
The second incomprehensible point is why the focus rectangle became dark-orange-red. But maybe, this is by design. Perhaps, somebody in Microsoft decided that this color is the best choice for the focus rectangle.
Taking into account all this, I think, the best choice for me and other developers who need the focus rectangle in our apps is to draw the focus rectangle by ourselves using the thickness defined by the SPI_GETFOCUSBORDERHEIGHT and SPI_GETFOCUSBORDERWIDTH system parameter values.
Is there a way to place window in the same point for example in top-right corner on the to displays with different resolution?
For example you have Macbook and you connected it to big display.
Note: windows property "Spaces" in IB is set to "Can join all spaces"
Spaces and displays are two separate concepts. So, "Can join all spaces" is not relevant to your question.
A window can only be at one position in the global screen coordinate system that spans the whole desktop. Each display constitutes a separate part of that coordinate system (ignoring mirroring). Therefore, no, it's not possible to have a window show up in the top-right corner of two separate displays. You would need two separate windows to achieve that.
I'm running Matlab 2015a on a Windows 7 laptop connected to two external monitors using nvidia's nView desktop manager. Recently, my figure positions have been screwey. When I set a positive x position, the figures appear off the right side of the screens. Pulling them in view (with Windows Key + Arrow) shows a negative value for anything in view. This is a big problem for my default positions (Waitbars and such are appearing out of view) and if I share my scripts with anyone (otherwise I'd just set my figures to show up at [ -1000, 10, w, l], but that'd put them off the left of other people's screens)
Any ideas what might cause this? I've had the same computer/moniter/GPU set up for over a year, and this only popped up in the past few weeks.
this might help: [1,1] is the position of the lower left corner of your Main Display. Its not the most left nor the first montior. you can check and change taht in control panel/Display/Settings (or similiar depending on windows version and language). So if your main screen is in the middle the display on the left of it will have a negative value on x
I am trying to get the width and height of all the windows. I did this easily with GetWindowRect however the styling in Win8.1+ seems such that there is a border on some windows and thats not being included. When I move/drag the window, this area moves with the window, so I expected it would be apart of its geometry. Is this known? Is there away to include the border width?
New Example
I created a second screenshot to explain after I see some confusion in the comments.
I have two windows side by side as seen in this image here:
Now if I take the GetWindowRect of the left and right windows, it should be a continuous rectangle around both of thse windows. However in the below we see this is not the case. I put a black fade over the whole desktop and cut out just the parts of the GetWindowRect for each window, we see the left window GetWindowRect is a bit smaller, this is my problem.
Old Example
For example this is a screenshot, using the cleared/non-black curtain area is what GetWindowRect identified as the width height, x and y:
We see there is some area of the window not included, I think this is the border? I used photoshop here to put a blue border around what all should have been:
And just for clarity I put an inner red border to show that the area between the red and blue borders was what should have been included, but was not:
Does anyone know how to include this "border" in the GetWindowRect?
Yes, GetWindowRect() lies to you. As you found out. It is a necessary lie. Goes back to Vista, the first Windows version that gave resizable windows their fat border. A pretty necessary feature, high screen resolutions were getting pretty common and the traditional 2-pixel border was getting too hard to hit with a mouse.
That created a massive compatibility problem however, many programs that create a window use CreateWindowEx(), you specify the outer window size. And don't use AdjustWindowRectEx(), the function that you must use to calculate the window size you need. Necessary because almost every window actually cares about the client size of the window. The part you fill with content. If they would have done nothing then legacy programs would end up creating windows with a client area that is too small, no longer fitting the content or aligning it out of whack. Very, very ugly.
So GetWindowRect() lies and pretends that the window has the traditional 2-pixel border. Pretty consistent lie, if you ask for the border size with GetSystemMetrics() then you get 2 back, even though it is 5. All works pretty well, until you start caring about positioning windows next to each other. Impossible to lie about that.
Turning off the lies requires letting Windows know that you are aware of the consequences of the fat borders. And know how to deal with Aero being turned off, possible on Vista and Win7. You must select the sub-system version number in the EXE file header and pick at least 6.00. The vast majority of programs use the legacy value, 4.00. Exactly how that's done depends on your tooling, for the Microsoft linker it is the /SUBSYSTEM option. It can be changed after the program was built with Editbin.exe, /SUBSYSTEM option. The program will no longer run on XP and earlier.
Windows 10 took an interesting new approach to this problem. The skinny borders are back. But now with a much bigger drop-shadow, the mouse is active beyond the border, even for windows that don't have a shadow. Works pretty well, hopefully we can all forget about this appcompat detail soon :)
I'm trying to coordinate the scrolling of a CListCtrl with another control. Contrary to the documentation on Win 7 you can call CListCtrl::GetViewRect or CListCtrl::GetOrigin to get the viewable area coordinates.
e.g. If you're scrolled 10 units across CListCtrl::GetOriginwill return x=10, y=0.
Unfortunately Win XP does follow the SDK documentation which says "... if the control is in report view, the return value is always zero".
I'm sure this must be really simple but whats the best way to get the top left coordinates of a CListCtrl viewable area?
It turns out that GetScrollInfo will do the trick. The nPos value matches the window coordinates (ie the min/max range represents the total size of columns not a fixed 0-100 range).