Flashing Infotip for Timekeeper on the Taskbar

[arttronics]

When pointer hovering over Timekeeper on the Taskbar, and stationary, the infotip will flash rapidly and not allow Context Menu interaction with Timekeeper during a specific condition.

Specifically, once the right-side-border of the infotip has reached the right side of the monitors edge, then one additional pixel movement to the right will cause this condition.

A possible solution is to configure the infotip behavior for rendering itself to the left of the mouse pointer if there is not enough rendering space to the right of it.

This issue is especially noticeable when very few Notification Tray icons are present, as that places Timekeeper closer to the monitors right side edge.

[skst]

Thank you for reporting this. I've successfully reproduced this issue.

While shifting its location to the left might hide the issue, I think the real solution will be to figure out why Windows is telling Timekeeper to redraw the tooltip over and over.

[arttronics]

I am graceful that this bug exists because as your wrote "While shifting its location to the left might hide the issue..." is what I did shortly after reporting this bug, but to be sure, "shifting to the left" is a solution for a totally different problem of mine, for a temporary solution of Timekeeper.

You see, I created a Empty Folder as a Toolbar and placed it between Timekeeper and the very last Notification Tray Icon seen on the most left side. This Empty Folder has Taskbar Tray Options of No Text and No Title and is RESIZED to allow the full Tooltip from Timekeeper with some extra pixels before it reaches the right side monitor edge, and then I engage: Lock The Taskbar.

What now happens is that I always have allocated space for Timekeeper when very little Notification Tray Icons are present, and when extras pop up, Timekeeper moves to the Left (as expected). As a test to confirm my expectations, I exited all Notification Tray Icons and Timekeeper keeps it's position, thanks the the Empty Toolbar Folder that is locked in place.

In closing, that problem of mine was for family's PC, in where they expect a certain amount of Notification Tray Icons to make sure the PC booted up correctly. Now if they see a gap... they know something is up and will tell me something is not loading in that tray. Thank you!

Getting back the the bug: "why Windows is telling Timekeeper to redraw the Tooltip over and over". I think it's because the Tooltip is not dynamic and has fixed position RIGHT of the mouse pointer. All of my Pinned Taskbar Icons show Infotips in the center, above of the pointer (unless at extreme edges in which case respects the monitors edge). Compare this to Windows native Network Icon in Notification Tray that shows the Tooltip to the left of the pointer, so itself does not flash (I imagine).

I think a solution is to configure Tooltip to be dynamic, based on mouse pointer and monitors right side edge, and if Tooltip is custom API of Timekeeper, then the Stackoverflow solution is to measure the distance to the right side monitor edge at Pointer Location VS length of the Tooltip and then render itself on the left side of the mouse pointer if not enough space is present... tedious. Maybe it's just better to have option to allow custom config of Tooltip STRING, with user choice of RIGHT or LEFT of the mouse pointer.

EXTRA: I suppose this part should be moved to Enhancements, but kudos if the idea of user configurable Tooltip STRING is an option, because making that an option might lead to using a "Timekeeper_Tooltip.ini" file. Such a file can allow specifying certain dates to have a certain Tootip being displayed. For example, multiline Tooltips over Timekeeper can show Anniversaries, Birthdays, Celebrations, via that pre-configured ini file. And because it's a simple text file, other user created tools can configure it to update it (respecting Timekeeper ini format) with such things as Weather, Email Count, RSS, Lottery Numbers, Word of the Day, etc. etc., as multiline Tooltips is a valid option.

[arttronics]

I am mistaken. Pinned Taskbar Icons do not show Infotips relative to the pointer, but to the pinned icons themselves. Here is a screenshot.

[arttronics]

Something else, a configured Taskbar Toolbar to a FOLDER, and shortcuts in this folder shown on the Taskbar, with or without a COMMENT in the Shortcut field will render Tooltip info to the RIGHT of the mouse, unlike Taskbar Pinned items.

The good thing is that Infotips for these items do not have a timeout period, and stay shown until pointer is moved away.

Here is a quick example you can do, select all the text down below (from "I just opened" to last char !) and paste it into Notepad++ and change EOL to UNIX and only then SELECT ALL of that text and copy to clipboard to then paste it into a SHORTCUT COMMENT to see an instant Multiline Infotip. Do this on an empty folder SHORTCUT for best results as some file types don't work, then notice that all of it is not shown due to character limitation. Important: If you change any part of a Tooltip and hover over it, you will probably see the same thing UNTIL you hover over something else that also generates a Tooltip. At this point, go back to see the expected changes show up correctly. This in itself puts to bed my idea of using NATIVE Tooltip as a information mechanism since it does not refresh itself until some other Tooltip is rendered.

I just opened Notepad++ with EOL set for UNIX.

This next line I am writing 1, 2, 3.

Perhaps I should write: A, B, and C.

I know I can write special Characters like ALT+1 = ☺

I will text-select all of this and paste as a SHORTCUT COMMENT.

Multi-Line for the win!

[skst]

Pinned Taskbar Icons do not show Infotips relative to the pointer, but to the pinned icons themselves.

Since those are third-party (not Microsoft) applications, I suspect this behavior is non-standard. Microsoft applications display their tooltip relative to the mouse. (They also time out.)

(Although not pictured, the mouse is hovering over the Security icon.)

[arttronics]

Since those are third-party (not Microsoft) applications, ...

Pinned Taskbar Icons are those icons dragged to the Taskbar or set there via Context Menu "Pin to Taskbar", or Microsoft default ones like File Explorer.

These Pinned Taskbar Icons are found in folder path: %AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar

On the Taskbar, these pinned icons shows their Infotips in the center of the pinned icon itself, above the mouse pointer no matter if the mouse pointer is to the extreme left or right within the pinned icon.

As for Infotips that do not timeout on the Taskbar, I noticed that they do not timeout when creating a Toolbar for a Folder (I previously wrote pinning a folder, but I correct that). The Folder itself or icons in that folder which are then displayed on the Taskbar ignores the time out.

Wow, I never realized that there are so many different types of Tooltips and Infotips and Taskbar related behaviors for them.

[arttronics]

@skst ,

...the real solution will be to figure out why Windows is telling Timekeeper to redraw the tooltip over and over.

Some additional information that might help fix this bug, as it is not the right side edge of Windows, or Windows, after all.

1. Configure Timekeeper to use Alignment option Center.
2. Configure Timekeeper on the Taskbar to use extra space so that you can move the mouse pointer inches to the left and right of it.
3. Monitor tooltip behavior from Right to Left: Location of the mouse pointer is at the very right of Timekeeper and once you see the tooltip, move the mouse pointer to the left.
4. As you are moving the mouse pointer from right to left, you will notice that the tooltip bottom left corner matches the location of the mouse pointer at all times, and the tooltip tracks smoothly.
5. Once you arrive at the extreme left side of Timekeeper, monitor the tooltip behavior from Left to Right.
6. As you are moving the mouse pointer from left to right, you will notice that the tooltip bottom left corner is to the left of the mouse pointer. Alert: The tooltip is repainting itself to the new location of the mouse pointer, but at that point the position of the mouse pointer has moved further to the right which causes the tooltip to repeat the painting process.

It's this behavior that shows whenever the mouse pointer is to the right of the tooltip, that the tooltip will close and then redraw itself to the new location of the mouse pointer instead of using the existing tooltip to update itself.

The original bug report that stated the tooltip flashes when there is not enough room on the screen, on the right side, is not accurate because it's during this moment that the mouse pointer is to the right of the tooltip which is asking for it to be closed and redrawn again.

The expected behavior of the tooltip is to have smooth tracking from left to right just like right to left has, except I don't know if the tooltip tracking can operate the same way for both RTL and LTR. In step 2 above, if you configured Timekeeper to have a tremendous amount of space, then no matter the speed moving from right to left, the tooltip is always tracked correctly.

Once a proper solution for right to left tooltip tracking is found, then the issue with the tooltip not having enough space on the right side of Windows is no longer an issue.

[arttronics]

@skst,

File: MyBands.cpp
Line: 685
Content: Compute the size of the text. If it's larger than the available space, resize the band.

The above probably has nothing to do with the tooltip rendering, but indirectly made me think: Is the tooltip width size calculated starting from the mouse pointer to the end of the configured tooltip text or previous width value?

If so, then the width always comes up short and the tooltip is closing only to make itself wider for the next redraw. Perhaps the tooltip rect width is offset by the position of the mouse cursor as it's moving to the right.

[skst]

Is the tooltip width size calculated starting from the mouse pointer to the end of the configured tooltip text or previous width value?

Timekeeper doesn't manually size the tooltip--that's on Windows--so I don't know how it computes its width.

There is definitely some weirdness around how deskbands are sized. (That's why there are so many comments related to updating the size of the deskband. 🙂) I'd welcome your (or anyone else's) help in solving those issues. If you do, please submit a pull request.