Tool tips showing in the wrong monitor

[loweskid]

Latest version of IMatch - experimental features enabled.

I have three monitors attached with various panels open on the right hand monitor (Metadata, Keywords, filters, etc.), but nothing on the left hand monitor.

When I hover the mouse over the icons on the new type ribbons, on either the right or central monitors, the 'tool tips' always show on the left-hand monitor.  On the old type ribbons they pop up at the mouse curser as normal.

[Mario]

Fixed for the next release, thanks.

[Bolitho]

2023.5.2
Seems not to be solved completely.
Two monitor setup (with different resolutions).
File categories panels on the right (secondary) monitor.
Tooltips shown somewhere (far away) to the right of the panel (but on the same monitor).
(Can't provide a screenshot since tooltip disappears when I do the screenshot.)

[Mario]

More details please. Screen resolution. DPI settings. Windows text scaling settings. A screen shot.
Use <Windows> + <Shift> + <S> to make one. This should also grab the tooltip.

[Bolitho]

Use <Windows> + <Shift> + <S> to make one. This should also grab the tooltip.

I know this should do the trick - but it doesn't :-(
After some further testing/playing around I think it's the old known Win (drivers?) problem of attached monitors with different resolution. (I haven't searched for the respective thread.)
An open panel on the main monitor shows the tooltip as expected.
I don't want to spend more time on it - neither should you.
It should just be listed as a known bug (which is out of your control to be solved).
Probably a new forum category should be introduced - something like "mysteries" or so.
JRiver forum has an area "weird and wonderful"...

[loweskid]

Everything now seems to be working fine on my system.  Three panels open on one secondary monitor - Metadata, Keywords and Filters.  Also tried the Categories panel on the third monitor - all fine.

Main monitor 1920x1200, other two 1280x1024

[Mario]

I could reproduce it by setting my second monitor to 1920 x 1080 pixel and 100% DPI scaling (96 DPI).

This was quite a puzzler (again)...

The math in my code checked out correctly, but the window was moved to the wrong position by Windows!

What IMatch basically does:
- it has to display a tooltip for an element in the ribbon
- it asks Windows for the current mouse cursor position using GetCursorPos()
- it calculates the required with and height for the tooltip
- the cursor x/y position + some offset becomes the top/left corner of the tooltip
- Then IMatch determines the monitor from the cursor position and gets the "work rect" where stuff can be displayed
- If the tooltip would show partially outside the monitor work rect, the tooltip rectangle is adjusted to fit within the work rect.
- Then IMatch calls the Windows function MoveWindow to move the tooltíp window and shows the window

All pretty simple. And the same code is used independently from which monitor the tooltip is shown on.

During my tests:
- I let IMatch display the mouse cursor position.
- the panel window position and size.
- the calculated rectangle for the tooltip.
It all was correct and made sense. But the MoveWindow function still moved the tooltip window to the wrong position.



IMatch is a so-called DPI aware application.
It declares itself as multi-monitor DPI aware during startup. This usually ensures that when multiple monitors are used and these monitors have different DPI settings, things like cursor coordinates and window positions work. Having multiple monitors with different DPI settings is quite challenging and a lot relies on built-in Windows functions and maybe even the graphics driver to get stuff right. I've spent a lot of time with this years ago, around IMatch 2017 or so.

So I was puzzled and maybe even bamboozled.
Numbers correct, tooltip window positioned wrong. I cannot look "into" the Windows function MoveWindow(). I can see the requested rectangle is correct, but MoveWindow moves the window too far on the left. But why?

I finally noticed that the Windows function GetWindowDpi() returned 144 for the tooltip window on the 100% monitor. This should have been 96!

After googling a lot and reading all the docs and specs regarding DPI aware applications again (https://learn.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process) I've decided to not only call

SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)

while IMatch is starting (which marks the IMatch process as DPI aware even for multiple monitors and is in place for many years) but also to update the IMatch manifest (which is embedded in IMatch and read by Windows when it starts IMatch) to include the line

Code Select Expand

<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
in addition to the

Code Select Expand

<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
line already in place.
This should do the same as calling SetProcessDpiAwarenessContext(). But apparently it does not. Because, after updating the manifest and rebuilding IMatch, the tooltip was displayed at the correct position! Yay!

This is one of those Windows things were Microsoft updates the documentation or specification for a function years after the function was introduced. Or suddenly, after a Windows update, stuff in an application that worked for years is broken. Or works slightly different than before. Especially with evolving things like multi-monitor multi-DPI support.

I finally found this tech note from Microsoft:

It is recommended that you set the process-default DPI awareness via application manifest, not an API call. See Setting the default DPI awareness for a process for more information. Setting the process-default DPI awareness via API call can lead to unexpected application behavior.

There you have it.
And users sometimes ask me why I charge money for IMatch and upgrades...

[janb83]

It is recommended that you set the process-default DPI awareness via application manifest, not an API call. See Setting the default DPI awareness for a process for more information. Setting the process-default DPI awareness via API call can lead to unexpected application behavior.

Interesting. I'll pass this on to a colleague of mine. I am pretty sure we are also only using SetProcessDpiAwarenessContext.

[Mario]

Be my guest

[Bolitho]

Looks like you like to be challenged 
And it's good it's solved finally - thank you!
How much time one can (must?) spend on others work to get the job done as expected.
Hope it didn't spoil your sunday!

[Bolitho]

Just installed 5.4

Not solved completely

Yes - tooltips show at the expected position.

BUT  (I have read the release notes):

This change may cause panels you have moved to a secondary monitor to slightly change their size and/or position.

Size increased by more than (estimated) 50% - far too big and more than "slightly".
Panels of other (non IMatch) apps display fine.

Of course I can resize e.g. Quick View panel (which shows an image only).
Text contents in panels like "Info & Activity" and "File Categories" is too big.
The panel headers! are fine.

[Mario]

Show us a screen shot. I've tested this from 1920+ and 100% Scaling+ in a wide range of resolutions and scales.

[Bolitho]

See the difference of panel title and panel text(contents):



Title is okay (as before and as expected), contents far bigger.

[Mario]

I don't understand...?

[Bolitho]

Show us a screen shot.

I wondered what this screenshot should show if the panels (i.e. contents of it) are just too big.

So I marked the panel title which has the right size (as a reference).
The text in the panel should have the same size as the title (as it was in the releases before) but is bigger.

I never fiddled with the Win screen resolution(s) - I left them as set by MS.
Also I use native resolution: Both monitors 27", main 4k (3840 x 2160), secondary 2560 x 1440.

[Mario]

The caption font used by Windows must not necessarily match the font or font size used in property grids.
Captions use the system "caption" font and for grids IMatch uses the "Control" font, which is based on the "Menu" font. For dialog controls IMatch uses the "Dialog" font, which is based on the Windows "Dialog" font. The actual font sizes and font faces vary by Windows version, screen resolution, screen DPI, Windows text scaling settings etc.

[Bolitho]

Okay - I don't get how this information helps me to solve the problem?

Before the recent change the panels always were okay.
(Just the tooltips were off - I could easily live with that.)

Now they are too big and waste valuable screen estate.
I'm not talking about cosmetics.

"Info & Activity" and "File Categories" panels (just the two) now occupy almost 1/2 of the secondary monitor.
Before it was just 1/4 (with the same contents).

Since IM 2023.5.4 this has changed to the worse!
Can it rolled back please?

As you mention the "Menu" font - the menu bars (new ribbons) on the secondary monitor are bigger than on the primary monitor, too.

To me it looks like IMatch does some upscaling since IM 2023.5.4.

[Mario]

Windows renders the text and the menus for the ribbon. IMatch does not set a font for the menus.
It's just now that the panels show correctly DPI-scaled. They should have always displayed that way, but Windows ignored IMatch's request to be "DPI-ware" (see my long post above). The tooltips were in the wrong spot, and the UI too small since Windows did not render IMatch UI items correctly on secondary monitors with non-default DPI scaling.

When you place a panel in the mid between two monitors, you'll see how Windows is behaving and scaling the panel and all contents according to the DPI settings of each monitor.

I can either undo the DPI-aware declaration in the manifest for all users, or I keep the now correct setting.
After shipping 3 IMatch versions in two weeks, I'm done for now. Maybe I'll come up with yet another idea next year.

[Bolitho]

I'm done for now. Maybe I'll come up with yet another idea next year.

This is fully understandable!

Thank you for your support - Happy holidays!!!!

To provide some more information which might help to improve the current behaviour (in the future!):

A) Moving a panel from a non IMatch application from the main to the secondary monitor:
  When the panel is on both ("between the") monitors the part on the secondary monitor is upscaled.
  As soon as the move is completed and the panel displayed fully on the secondary monitor it is downscaled (and finally looks identical in size to the main monitor).
E.g. a Thunderbird panel behaves like this.

B) Moving an IMatch panel:
The panel on the move between the two monitors is upscaled on the secondary monitor too.
Contrary to "A" ist is not downscaled as soon as the move is completed and the whole panel visible an the secondary monitor alone.

[Mario]

The scaling is done by Windows, not IMatch.

[Bolitho]

IMatch panels are the only ones on my PC which show this behaviour (since the recent change).

Probably IMatch doesn't tell Win to scale (according to the secondary monitor - not the main)?

[Mario]

IMatch always declared itself as DPI aware. This tells Windows to scale windows according to the DPI of the monitor where the window is placed. All this is done in the GDI system in Windows. IMatch does not tell Windows to scale anything. This is controlled by the DPI setting for the monitor.

Before this change, the mouse coordinates IMatch got from Windows were incorrect, resulting in left-click issues, wrong coordinates for tooltips etc. The change has resolved that and things work fine. A window with a certain pixel size appears larger on a monitor with lower resulting / DPI, which is expected.

When I use Windows Calculator, the size of the calculator window is quite different at different screen resolutions and DPI settings:

[Bolitho]

Do you ever sleep or take a day off?

Hope you had some quiet holidays!

Thank your for the fast response.

I have taken up and extended your approach of showing the Calculator as a reference.

To reproduce:

Both monitors are of identical size (27")

Main monitor has 4k, secondary 3k

1.) On the main monitor I opened a LibreOfficeWriter Document (as scaling reference)
An IMatch Info panel (to show text) and QuickView panel (with video controls) as well as the Calculator are placed on top:



2.)One by one I moved all four panels to the secondary monitor with the mouse.
(I.e. I just moved them without changing size.)



The Writer panel and Calculator adapt nicely to the lower resolution and appear as big as on the main monitor.

The IMatch panels become bigger - it's impossible to reposition them to appear identical (in size and relation) to the main monitor.

This is IMatch specific and has been introduced with the recent change.

Sinus observed the same:

Text is too big on my second monitor

[Mario]

Why do you show the Quick View Panel in the first screen shot but the Info & Activity Panel in the second?
My screen shot shows that the Windows Calculator fills almost the entire 1980 x 1020 (100%) screen, does not even fit on a 1980 x 1020 at 175% and fits nicely on the 4K 150% screen - just dragging it around without resizing it. Why would that work differently on your setup?

[Bolitho]

Why do you show the Quick View Panel in the first screen shot but the Info & Activity Panel in the second?

Apparently I haven't been clear with my explanation.

Both screen shots show the same panels. Really the same (identical).

First screen shot shows them all on the main monitor - one sees their individual dimensions/proportions and how these relate to each other.

Second screen shot shows the same (really the same!) panels moved to the secondary monitor.
IMatch panels optically become bigger and change their dimensions in relation to the non IMatch panels.

If I may guess: IMatch panels keep their size pixelwise(!) when moved from the 4k (main) to the 3k (secondary) monitor. 3k has less dpi than the 4k monitor (given identical physical(!) dimensions of the displays) - thus making objects appear bigger than on the 4k monitor.
Nevertheless non IMatch panels adapt to the different monitors whilst IMatch panels don't.

Whatever scaling (percentwise) you set in your tests shouldn't matter as my example shows how IMatch and non IMtach panels change their size in relation to each other.

 
 

[Bolitho]

Additional observation:

Just because of curiosity I played around a bit:

I moved IMatch as a whole to the secondary monitor - it becomes (optically) bigger :-(

So it's a general (not only affecting some panels) IMatch behavior different to other applications.

What has changed, too (since the recent change):

Before the change:

When I moved one panel from one monitor to the other it couldn't been done with one draw. It must be moved almost half to the other monitor, then grabbed there and moved completely. The panel then adapted to the different monitor scaling.
(This has been discussed on IMatch forum a long time ago.)

After the recent change:

The panels now can be moved smoothly from one monitor to the other.
However, they don't adapt to the different sizes - while all other (non IMatch) do as soon as they are moved more than halfway to the other monitor.

[Mario]

As I said, I will look into it. And I did.

I've figured out why Windows was moving the tooltip popup window to the wrong location when the monitors used different DPI. This was a side-effect of how the tooltip declared it's parent window. Very obscure and not documented anywhere.

I can now move back and declare IMatch as non DPI-aware so Windows does the scaling when you move windows / panels to a different monitor. The same behavior we've had before.

[Bolitho]

IMatch 2023.6.4

Ribbon tooltips on secondary monitor (3K) work fine (shown to the bottom right of the selected item).

Ribbon tooltips on primary monitor (4K) are far off (usually to the left) and the text/letters is/are very small.

(Same HW equipment as in my posts above.)

I didn't expect it to be such complicated stuff 
Also I don't know whether the following may be of any help for you:

There is a thread on the ExifTool forum regarding an updated ExifToolGUI addressing similar issues:

https://exiftool.org/forum/index.php?topic=15053.30

They refer to Github:

https://github.com/FrankBijnen/ExifToolGui/blob/main/Docs/Readme%204K%20monitor.txt

[Mario]

Show us a screen shot.
 I assume you use the default 150% DPI scaling for the 4K screen and the default 100% text scaling? 

I doubt this was ever reported and I use 4K monitors myself, plus a 2560px and 1920px monitor.
Any other users with the same issue? This is really ridiculous and I've spent to much time already for one (?) user?

[Tveloso]

This issue does not manifest with my setup.

I use a Laptop (1920 x 1200) with a single external monitor (2560 x 1440) configured as the primary display.

I floated the Metadata Panel over to the secondary display (the laptop's own display), and just as they had done when the Panel was docked on the primary monitor, the Ribbon Tooltips appeared to the lower-right of the hovered pointer, and the text was a good readable size.

But this is probably not a good test, as I have both displays set to 100% DPI scaling, and no changes to Text Scaling.

I can only imagine how difficult it must be with IMatch running in so many different "display environments" (video cards, monitor counts, display drivers, and all the configuration options available therein)...

[Bolitho]

Show us a screen shot.

Does not work with active tool tip.

I assume you use the default 150% DPI scaling for the 4K screen and the default 100% text scaling?

Yes, this is Windows recommended.

This is really ridiculous and I've spent to much time already for one...

Could be my text - IMatch is the only app showing this.
It applies to the "new" ribbon tooltips only - everything else is fine.

[Mario]

I don't see any problems on my monitors and no other user has reported something similar, especially not on the main monitor where IMatch is running. No idea why only your system would be affected. If I cannot reproduce this, I cannot fix it.

Does not work with active tool tip.

Use <Windows>+<Print> to make a screen shot (stored in the Images\Screen Shots folder on your system:



Make a screen shot from the leftmost button in the ribbon and one of the rightmost, crop and attach. Maybe this gives me an idea.

The screen shot above is from a 4K monitor with 150% DPI scaling and 100% text scaling.

IMatch just opens the tooltip at the pixel coordinates of the bottom right corner of the button. I don't see how this could fail?

[David_H]

I don't see any problems on my monitors and no other user has reported something similar, especially not on the main monitor where IMatch is running. No idea why only your system would be affected. If I cannot reproduce this, I cannot fix it.

I think I can duplicate it.
IMatch open on one screen; no issues.



Open another panel on a different screen (in my case, the category panel), then whilst the tooltips in that panel are fine, the ones back on the main IMatch window are now incorrect :






If the panel opens on the same screen, the tooltips are fine; move it elsewhere and they break again.

[Mario]

Thanks. I'll see if I can reproduce it.
What do you mean by 3K? 2560 pixel I assume? At 125% scaling?
Each ribbon creates and maintains its own tooltip window. There should be no difference...

[Tveloso]

I could also reproduce this as described by David_H.

I could not initially...(when both my monitors were at 100% DPI Scaling).  But when I changed my secondary monitor to the Microsoft recommended value (of 125%), the tooltips back in the main IMatch Window were now placed incorrectly.

In my case, they were displayed well off to the right of where I had hovered my mouse pointer.  And the Tooltips for the panels docked to the lower-right of the IMatch Window, didn't display at all...(I'm guessing that they were placed far enough to the right, that they were "off the screen").

[Mario]

I can see this effect but I have no explanation.
When I open a panel on the secondary monitor set to 2560 at 125% scaling, the tooltips show wrong for the ribbons on the main monitor. When I close the panel on the secondary monitor, the tooltips on the main monitor are automatically correct again. Magic!

When I make the ribbon the parent window of the tooltip, the tip shows correct on the main monitor but at the wrong position on the secondary monitor. When I make the tooltip a popup window without a parent window, the tooltips show correct in the secondary monitor but wrong on the main monitor.

All the tooltip is doing is to get the cursor position from Windows using GetCursorPos(), adding a fee pixels of padding so the coordinate matches the lower right corner of the corresponding ribbon element and then move the tooltip's top/left edge to that coordinate.

Something strange is going on with DPI scaling and how Windows modifies the coordinates IMatch gets when asking and when IMatch then positions the tooltip window at these coordinates.
The GetCursorPos and then to stuff with it works anywhere in IMatch, except for ribbons. Which are just child windows, like hundreds of other child windows IMatch uses for everything, from panels to File Windows to apps...

[David_H]

I can see this effect but I have no explanation.
When I open a panel on the secondary monitor set to 2560 at 125% scaling, the tooltips show wrong for the ribbons on the main monitor. When I close the panel on the secondary monitor, the tooltips on the main monitor are automatically correct again. Magic!

I think its related to the last window the panel is in; I tried with 3 (1 docked in the main window as before), category window on another screen, then I opened another panel that's in a separate window (Info & Activity but it probably doesn't matter which one) which opened on the same screen as the main window.
Now the tooltips on the main screen are in the right place but the category panel ones are off.

[Mario]

I have found a solution to the problem. But no reason for the problem.

The problem was not only that the tooltip was positioned wrong by Windows, but it was also scaled by the DPI of the main monitor. The panel itself was scaled by Windows based on the screen DPI as it should, but the tooltip was always scaled based on the main monitor...

Even if the panel was closed before and opened for the first time on the secondary monitor, I got the same effect.

It also depended on whether the ribbon was the "parent" window (then the ribbon tooltip on the main monitor were correct) or it has no parent (then the ribbon tooltips on the secondary monitor were correct).
I can see no sense in this, since the ribbon (the parent) is on the same monitor and correctly scaled by Windows according to DPI. Each ribbon creates and maintains its own tooltip.

And when the tooltips on the main window were wrong, closing the panel on the secondary monitor magically caused the tooltips on the main monitor to work correctly. Geeez.

The solution I've found was to destroy and recreate the tooltip window every time the parent (ribbon) is moved or requires a layout update for other reasons. This somehow makes the magic work and results in Windows scaling the size of the tooltip and its position correctly for all configurations and DPI varieties.