Solve : Tool tips go behind task bar!?

1.	Solve : Tool tips go behind task bar!?
Answer» I haven't searched on this I admit - but anyone had same? Usually occurs at some point after being well advanced after a reboot - and tooltips are all but obscured because behind the task bar. Not major deal - just irritating!Try this: http://neosmart.net/dl.php?id=101. Official Microsoft advice: either log off & on again or else restart PC 2. UNOFFICIAL: go to Start/All Programs: Hover over any program listed, right click and select Sort by Name. Repeat once more. If tooltips still hidden, repeat. It's an old, known issue. A reboot is usually the best and most reliable "fix".Thx Broni - I may try that tho as said - it is just an irritation. Now it has been mentioned I remember it is a long standing win bug. I tried the start-programs approach but to no avail ...... so I think it'll be the old reboot deal, as always! Thx all.Uncheck the "keep taskbar on top of other windows". Click apply. check it. Apply again. Worked for me. the Cause is quite simple; when the taskbar is set to always on top, it is set as a "always on top" window. tooltips do the same; usually their zorder remains correct, but sometimes (for example, after a long run-time) somehow the zorder of the taskbar and it's tooltips get out of sync, and the tooltips appear behind the taskbar. Rather then do it this way, however, I figure it might be possible to "automate" it. It's simply removing and setting the topmost attribute- so I whipped this up; a s mall VB6 program that uses some basic window management API to remove and set the topmost attribute, which should hopefully fix the issue. Code: [Select]Option Explicit Private Declare Function FindWindow Lib "user32.dll" Alias "FindWindowA" _ (ByVal lpClassName As String, ByVal lpWindowName As String) As Long Private Declare Function SetWindowPos Lib "user32.dll" (ByVal hwnd As Long, ByVal hWndInsertAfter As Long, ByVal x As _ Long, ByVal y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long Private Const HWND_TOPMOST As Long = -1 Private Const HWND_NOTOPMOST As Long = -2 Private Const SWP_SHOWWINDOW As Long = &H40 Private Const SWP_NOZORDER As Long = &H4 Sub Main() Dim Shellwindow As Long Dim taskb As Long taskb = FindWindow("Shell_Traywnd", vbNullString) If taskb <> 0 Then SetWindowPos taskb, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_SHOWWINDOW SetWindowPos taskb, HWND_TOPMOST, 0, 0, 0, 0, SWP_SHOWWINDOW Else MsgBox "FindWindow of Shell_Traywnd failed." End If End Sub I cannot test it though since Vista appears immune to this particular issue (no doubt because of the new DWM architecture); let me know if it works, as with the Taskbar settings option toggle. [Saving space, attachment deleted by admin]BC - many thx. Well - I tried the 'taskbar' on top, cancel and reapply - but after reapply it was BACK to old tricks. As I rarely run full screen - usually everything cascaded both screens, I don't need it to take priority and so for now have left it canceled for focus and the tooltips show fine of course! The code routine .... thx for that but a question - how should that be run? - assuming it'll run safely too. Save as 'filename.exe'? Or does it in fact behave as an executable or some other way?. many thx again.Trust me, it won't matter. This is just an old bug that pops up now and then and the only definitive "fix" is a reboot.Its the code I indicated; I don't know any scripts that can call API's directly. It's a ZIP file with an EXE inside; liek I say, I have no clue if it'll work or not, since I am using Vista now and no longer have that problem. For the dialog; there is no invokation of "cancel": Right-click an empty area of the taskbar->properties Taskbar tab Uncheck the "keep taskbar on top of other windows" checkbox. Now press apply. check it again, and press apply.Quote from: Allan on November 20, 2009, 04:27:43 PM Trust me, it won't matter. This is just an old bug that pops up now and then and the only definitive "fix" is a reboot. You say that like there is a such thing as a bug without an explanation. there isn't. This is simply a case of window zorder not being ideal for the tooltip. I explained this quite thoroughly. The important point here is using the SWP_NOZORDER flag, which means that the SetWindowPos() calls will cause changes to the zorder stack, which is exactly what we are trying to achieve. Since getting the window handle of the tooltip object used by the taskbar is likely convoluted and messy, we need to deal with the other window, the taskbar itself. The architecture for window management in XP and below is really quite simple; basically, they are in a "stack" which is quite easy to imagine. the windows are drawn from the farthest back to the closest, however, only those regions that are visible will be drawn at all. For example, when a window is maximized, the desktop is not drawn at all. Windows Only allows for repainting within "invalidated" regions of a window; before calling the window procedure with the WM_PAINT message it basically "locks out" painting outside the invalidated area, usually the area of the window revealed by moving a window that is on top of it. This behaviour can be seen in that when you move a window over top of another program's window that is not responding, you see the "trail" of windows on top of it. This is because the application is busy and no longer servicing it's message queue, and therefore WM_PAINT messages go unfulfilled. In this particular instance; the ordering of the tooltip and the taskbar are incorrect; specifically, this occurs when always on top is checked; due to what I would conjecture are race conditions within the various window management APIs and explorer's hooking of said window functions for the purposes of displaying and updating buttons on the taskbar. The "fix" is simply to fix this zorder. Since the desired ORDER is to have the tooltip topmost, the ideal solution would be to somehow get the hwnd the tooltip is using and use the API to set that Topmost. However, it turns out, that each taskbar button and item on the taskbar is given it's very own tooltip class. Since there are multiple tooltip instances and each one is showing beneath the taskbar, it is thus easy to deduce that the zorder issue is caused by the taskbar window itself and an incorrect zordering. An alternative code solution would be to use EnumWindows() and loop through all windows, setting any with the class name Tooltips_Class32 as topmost windows. This would guarantee that all tooltips appear on top of ALL windows WHATSOEVER. But given the negligible value of tool it seems like more of an academic pursuit that does not catch my immediate fancy. Besides, Log-off Log-on is all that is necessary. (because the windows are destroyed and recreated) BC - great explanation. As you correctly identify - in most ways it is not a biggie this problem. Just a ''nuisance'' which is a tad irritating. Thx for all your input.

Answer»

I haven't searched on this I admit - but anyone had same?

Usually occurs at some point after being well advanced after a reboot - and tooltips are all but obscured because behind the task bar. Not major deal - just irritating!Try this: http://neosmart.net/dl.php?id=101. Official Microsoft advice: either log off & on again or else restart PC

2. UNOFFICIAL: go to Start/All Programs: Hover over any program listed, right click and select Sort by Name. Repeat once more. If tooltips still hidden, repeat.
It's an old, known issue. A reboot is usually the best and most reliable "fix".Thx Broni - I may try that tho as said - it is just an irritation.

Now it has been mentioned I remember it is a long standing win bug.

I tried the start-programs approach but to no avail ...... so I think it'll be the old reboot deal, as always!

Thx all.Uncheck the "keep taskbar on top of other windows". Click apply. check it. Apply again.

Worked for me.

the Cause is quite simple; when the taskbar is set to always on top, it is set as a "always on top" window. tooltips do the same; usually their zorder remains correct, but sometimes (for example, after a long run-time) somehow the zorder of the taskbar and it's tooltips get out of sync, and the tooltips appear behind the taskbar.

Rather then do it this way, however, I figure it might be possible to "automate" it. It's simply removing and setting the topmost attribute- so I whipped this up; a s mall VB6 program that uses some basic window management API to remove and set the topmost attribute, which should hopefully fix the issue.

Code: [Select]Option Explicit

Private Declare Function FindWindow Lib "user32.dll" Alias "FindWindowA" _
(ByVal lpClassName As String, ByVal lpWindowName As String) As Long

Private Declare Function SetWindowPos Lib "user32.dll" (ByVal hwnd As Long, ByVal hWndInsertAfter As Long, ByVal x As _
Long, ByVal y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
Private Const HWND_TOPMOST As Long = -1
Private Const HWND_NOTOPMOST As Long = -2
Private Const SWP_SHOWWINDOW As Long = &H40
Private Const SWP_NOZORDER As Long = &H4

Sub Main()
Dim Shellwindow As Long
Dim taskb As Long

taskb = FindWindow("Shell_Traywnd", vbNullString)

If taskb <> 0 Then

SetWindowPos taskb, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_SHOWWINDOW

SetWindowPos taskb, HWND_TOPMOST, 0, 0, 0, 0, SWP_SHOWWINDOW

Else
MsgBox "FindWindow of Shell_Traywnd failed."

End If

End Sub

I cannot test it though since Vista appears immune to this particular issue (no doubt because of the new DWM architecture); let me know if it works, as with the Taskbar settings option toggle.

[Saving space, attachment deleted by admin]BC - many thx.

Well - I tried the 'taskbar' on top, cancel and reapply - but after reapply it was BACK to old tricks. As I rarely run full screen - usually everything cascaded both screens, I don't need it to take priority and so for now have left it canceled for focus and the tooltips show fine of course!

The code routine .... thx for that but a question - how should that be run? - assuming it'll run safely too. Save as 'filename.exe'? Or does it in fact behave as an executable or some other way?.

many thx again.Trust me, it won't matter. This is just an old bug that pops up now and then and the only definitive "fix" is a reboot.Its the code I indicated; I don't know any scripts that can call API's directly.

It's a ZIP file with an EXE inside; liek I say, I have no clue if it'll work or not, since I am using Vista now and no longer have that problem.

For the dialog; there is no invokation of "cancel":

Right-click an empty area of the taskbar->properties

Taskbar tab

Uncheck the "keep taskbar on top of other windows" checkbox.
Now press apply. check it again, and press apply.Quote from: Allan on November 20, 2009, 04:27:43 PM

Trust me, it won't matter. This is just an old bug that pops up now and then and the only definitive "fix" is a reboot.

You say that like there is a such thing as a bug without an explanation. there isn't. This is simply a case of window zorder not being ideal for the tooltip. I explained this quite thoroughly.

The important point here is using the SWP_NOZORDER flag, which means that the SetWindowPos() calls will cause changes to the zorder stack, which is exactly what we are trying to achieve. Since getting the window handle of the tooltip object used by the taskbar is likely convoluted and messy, we need to deal with the other window, the taskbar itself.

The architecture for window management in XP and below is really quite simple; basically, they are in a "stack" which is quite easy to imagine. the windows are drawn from the farthest back to the closest, however, only those regions that are visible will be drawn at all. For example, when a window is maximized, the desktop is not drawn at all. Windows Only allows for repainting within "invalidated" regions of a window; before calling the window procedure with the WM_PAINT message it basically "locks out" painting outside the invalidated area, usually the area of the window revealed by moving a window that is on top of it. This behaviour can be seen in that when you move a window over top of another program's window that is not responding, you see the "trail" of windows on top of it. This is because the application is busy and no longer servicing it's message queue, and therefore WM_PAINT messages go unfulfilled.

In this particular instance; the ordering of the tooltip and the taskbar are incorrect; specifically, this occurs when always on top is checked; due to what I would conjecture are race conditions within the various window management APIs and explorer's hooking of said window functions for the purposes of displaying and updating buttons on the taskbar. The "fix" is simply to fix this zorder.

Since the desired ORDER is to have the tooltip topmost, the ideal solution would be to somehow get the hwnd the tooltip is using and use the API to set that Topmost. However, it turns out, that each taskbar button and item on the taskbar is given it's very own tooltip class.

Since there are multiple tooltip instances and each one is showing beneath the taskbar, it is thus easy to deduce that the zorder issue is caused by the taskbar window itself and an incorrect zordering.

An alternative code solution would be to use EnumWindows() and loop through all windows, setting any with the class name Tooltips_Class32 as topmost windows. This would guarantee that all tooltips appear on top of ALL windows WHATSOEVER. But given the negligible value of tool it seems like more of an academic pursuit that does not catch my immediate fancy. Besides, Log-off Log-on is all that is necessary. (because the windows are destroyed and recreated)

BC - great explanation.

As you correctly identify - in most ways it is not a biggie this problem. Just a ''nuisance'' which is a tad irritating. Thx for all your input.

Solve : Tool tips go behind task bar!?

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment