Tooltips behind taskbar - FIXED!

According to Micro$oft, tooltips appear behind the taskbar because both are
trying to be the topmost window in the Z-order. Fair enough. But, to this
day, there has been NO attempt by Micro$oft to fix this particular problem.
WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip windows Z-order
priority over ALL other windows!

OK, there are some workarounds, but none of them work universally and most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the taskbar on top of
other windows" option, and then re-enabling the option. Fine and dandy
except that it has NEVER, EVER worked on ANY of my systems (and quite likely
yours as well). Indeed, permanently disabling the option has been (until
now) the ONLY "workaround" that is guaranteed to work every time. If only we
didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject
(http://support.microsoft.com/default...=rss&spid=3223)
states that the problem occurs when right-clicking and opening a My Document
or a Recent Document in the Start menu. Apart from anything else, the
problem occurs in many more ways than simply opening a document. Show
Desktop is just one. Sorting the menu is another. However, the real killer
is that Micro$oft then go on to recommend logging off or rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results in the context
menu itself being hidden BEHIND the taskbar. This is yet another symptom of
different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the tooltips will swap
their Z-orders around. So if tooltips are already hidden behind the taskbar,
sorting the menu will bring them in front of the taskbar again. But if you
ever need to sort the menu in future, remember to do it TWICE unless
tooltips are already behind the taskbar. Repeating the sort naturally has no
effect on the menu order, but it fixes the Z-order problem.

That's it! No logoff and certainly no reboot required. Just a simple little
workaround--and it will ALWAYS WORK on EVERY XP SYSTEM!

[PAUSE FOR APPLAUSE]

Thank you and good night.

Micky wrote:

According to Micro$oft, tooltips appear behind the taskbar because both are
trying to be the topmost window in the Z-order. Fair enough. But, to this
day, there has been NO attempt by Micro$oft to fix this particular problem.
WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip windows Z-order
priority over ALL other windows!

OK, there are some workarounds, but none of them work universally and most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the taskbar on top of
other windows" option, and then re-enabling the option. Fine and dandy
except that it has NEVER, EVER worked on ANY of my systems (and quite likely
yours as well). Indeed, permanently disabling the option has been (until
now) the ONLY "workaround" that is guaranteed to work every time. If only we
didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject
(http://support.microsoft.com/default...=rss&spid=3223)
states that the problem occurs when right-clicking and opening a My Document
or a Recent Document in the Start menu. Apart from anything else, the
problem occurs in many more ways than simply opening a document. Show
Desktop is just one. Sorting the menu is another. However, the real killer
is that Micro$oft then go on to recommend logging off or rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results in the context
menu itself being hidden BEHIND the taskbar. This is yet another symptom of
different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the tooltips will swap
their Z-orders around. So if tooltips are already hidden behind the taskbar,
sorting the menu will bring them in front of the taskbar again. But if you
ever need to sort the menu in future, remember to do it TWICE unless
tooltips are already behind the taskbar. Repeating the sort naturally has no
effect on the menu order, but it fixes the Z-order problem.

That's it! No logoff and certainly no reboot required. Just a simple little
workaround--and it will ALWAYS WORK on EVERY XP SYSTEM!

[PAUSE FOR APPLAUSE]

Yay!

Thank you and good night.



Good to know, thank you.

Alias

Use the Reply to Sender feature of your news reader program to email me.
Utiliza Responder al Remitente para mandarme un mail.

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

OK that fixed the Tooltips behind the Taskbar for me.

The question is for how long?

Your band-aid lasted as long as all the other band-aids do...

Rebooting or logging off and logging back on. Or hiding the Taskbar then
showing it again. Or killing explorer.exe and restarting it.

Nice try, but no applause here. ;-)

Although, I must say, your band-aid may be quicker to apply than the others.

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In ,
Micky hunted and pecked:
According to Micro$oft, tooltips appear behind the taskbar because both
are trying to be the topmost window in the Z-order. Fair enough. But, to
this day, there has been NO attempt by Micro$oft to fix this particular
problem. WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip windows
Z-order priority over ALL other windows!

OK, there are some workarounds, but none of them work universally and most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the taskbar on top of
other windows" option, and then re-enabling the option. Fine and dandy
except that it has NEVER, EVER worked on ANY of my systems (and quite
likely yours as well). Indeed, permanently disabling the option has been
(until now) the ONLY "workaround" that is guaranteed to work every time.
If only we didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject

(http://support.microsoft.com/default...0&sd=rss&spid=
3223)
states that the problem occurs when right-clicking and opening a My
Document or a Recent Document in the Start menu. Apart from anything
else, the problem occurs in many more ways than simply opening a
document. Show Desktop is just one. Sorting the menu is another. However,
the real killer is that Micro$oft then go on to recommend logging off or
rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results in the context
menu itself being hidden BEHIND the taskbar. This is yet another symptom
of different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the tooltips will swap
their Z-orders around. So if tooltips are already hidden behind the
taskbar, sorting the menu will bring them in front of the taskbar again.
But if you ever need to sort the menu in future, remember to do it TWICE
unless tooltips are already behind the taskbar. Repeating the sort
naturally has no effect on the menu order, but it fixes the Z-order
problem.

That's it! No logoff and certainly no reboot required. Just a simple
little workaround--and it will ALWAYS WORK on EVERY XP SYSTEM!

[PAUSE FOR APPLAUSE]

Thank you and good night.

Wes: I used to see this problem from day 1 with XP. Out of the
blue my computer does not have this problem. Who said miracles
never happen? Don't know what happened but she doth worketh
fine.

Doug
====
"Wesley Vogel" wrote in message
...
Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the
taskbar*
Click Sort by Name

OK that fixed the Tooltips behind the Taskbar for me.

The question is for how long?

Your band-aid lasted as long as all the other band-aids do...

Rebooting or logging off and logging back on. Or hiding the
Taskbar then
showing it again. Or killing explorer.exe and restarting it.

Nice try, but no applause here. ;-)

Although, I must say, your band-aid may be quicker to apply
than the others.

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In ,
Micky hunted and pecked:
According to Micro$oft, tooltips appear behind the taskbar
because both
are trying to be the topmost window in the Z-order. Fair
enough. But, to
this day, there has been NO attempt by Micro$oft to fix this
particular
problem. WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip
windows
Z-order priority over ALL other windows!

OK, there are some workarounds, but none of them work
universally and most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the
taskbar on top of
other windows" option, and then re-enabling the option. Fine
and dandy
except that it has NEVER, EVER worked on ANY of my systems
(and quite
likely yours as well). Indeed, permanently disabling the
option has been
(until now) the ONLY "workaround" that is guaranteed to work
every time.
If only we didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject

(http://support.microsoft.com/default...0&sd=rss&spid=
3223)
states that the problem occurs when right-clicking and
opening a My
Document or a Recent Document in the Start menu. Apart from
anything
else, the problem occurs in many more ways than simply
opening a
document. Show Desktop is just one. Sorting the menu is
another. However,
the real killer is that Micro$oft then go on to recommend
logging off or
rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix
the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the
taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results
in the context
menu itself being hidden BEHIND the taskbar. This is yet
another symptom
of different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the
tooltips will swap
their Z-orders around. So if tooltips are already hidden
behind the
taskbar, sorting the menu will bring them in front of the
taskbar again.
But if you ever need to sort the menu in future, remember to
do it TWICE
unless tooltips are already behind the taskbar. Repeating the
sort
naturally has no effect on the menu order, but it fixes the
Z-order
problem.

That's it! No logoff and certainly no reboot required. Just a
simple
little workaround--and it will ALWAYS WORK on EVERY XP
SYSTEM!

[PAUSE FOR APPLAUSE]

Thank you and good night.

Heck of a deal, Doug. Maybe you should be offering applause to Micky then.
;-)

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In ,
Doug stand@attention hunted and pecked:
Wes: I used to see this problem from day 1 with XP. Out of the
blue my computer does not have this problem. Who said miracles
never happen? Don't know what happened but she doth worketh
fine.

Doug
====
"Wesley Vogel" wrote in message
...
Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the
taskbar*
Click Sort by Name

OK that fixed the Tooltips behind the Taskbar for me.

The question is for how long?

Your band-aid lasted as long as all the other band-aids do...

Rebooting or logging off and logging back on. Or hiding the
Taskbar then
showing it again. Or killing explorer.exe and restarting it.

Nice try, but no applause here. ;-)

Although, I must say, your band-aid may be quicker to apply
than the others.

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In ,
Micky hunted and pecked:
According to Micro$oft, tooltips appear behind the taskbar
because both
are trying to be the topmost window in the Z-order. Fair
enough. But, to
this day, there has been NO attempt by Micro$oft to fix this
particular
problem. WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip
windows
Z-order priority over ALL other windows!

OK, there are some workarounds, but none of them work
universally and most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the
taskbar on top of
other windows" option, and then re-enabling the option. Fine
and dandy
except that it has NEVER, EVER worked on ANY of my systems
(and quite
likely yours as well). Indeed, permanently disabling the
option has been
(until now) the ONLY "workaround" that is guaranteed to work
every time.
If only we didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject


(http://support.microsoft.com/default...0&sd=rss&spid=
3223)
states that the problem occurs when right-clicking and
opening a My
Document or a Recent Document in the Start menu. Apart from
anything
else, the problem occurs in many more ways than simply
opening a
document. Show Desktop is just one. Sorting the menu is
another. However,
the real killer is that Micro$oft then go on to recommend
logging off or
rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix
the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the
taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results
in the context
menu itself being hidden BEHIND the taskbar. This is yet
another symptom
of different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the
tooltips will swap
their Z-orders around. So if tooltips are already hidden
behind the
taskbar, sorting the menu will bring them in front of the
taskbar again.
But if you ever need to sort the menu in future, remember to
do it TWICE
unless tooltips are already behind the taskbar. Repeating the
sort
naturally has no effect on the menu order, but it fixes the
Z-order
problem.

That's it! No logoff and certainly no reboot required. Just a
simple
little workaround--and it will ALWAYS WORK on EVERY XP
SYSTEM!

[PAUSE FOR APPLAUSE]

Thank you and good night.

"Wesley Vogel" wrote in message
...
Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

OK that fixed the Tooltips behind the Taskbar for me.

The question is for how long?

At least until you next right-click on an object in the start menu, or
choose Show Desktop, or do any of the 100 other tasks that contibute to the
problem. Ultimately, the problem is within Explorer itself, and there's
little you nor I can do about that. Is it really asking too much of
Micro$oft to ensure that tooltips always remain on top of all other windows?
I think not.

Your band-aid lasted as long as all the other band-aids do...

To be fair, I never said it was a permanent fix--only that it works on all
my systems when other methods failed. Indeed, sorting the menu will actually
cause the problem, hence you must sort the menu twice to restore the status
quo.

Rebooting or logging off and logging back on.

Which is complete overkill, IMHO. Sledghammer to crack a nut in other words.
It's hardly convenient when you're in the middle of something and just want
a notification tooltip in the system tray...

Or hiding the Taskbar then showing it again.

Which doesn't work on any my systems. Nor does moving the taskbar. Nor
toggling the "on top" option. Nor any of the other "snake oil" remedies I've
encountered.

Or killing explorer.exe and restarting it.

Which simply loses numerous notification icons in the process. It's actually
quicker to logoff and back on than it is to terminate and relaunch each
missing icon. Again, it's sheer overkill.

Nice try, but no applause here. ;-)

Party-pooper! ;-)

Although, I must say, your band-aid may be quicker to apply than the
others.

Not only is it quicker, it is non-destructive (so long as you like your menu
sorted--and who doesn't?) and it works every time on every system--including
your own! It may not be a permanent fix, but it's the closest thing to a
universal workaround to date.

In ,
Micky hunted and pecked:
According to Micro$oft, tooltips appear behind the taskbar because both
are trying to be the topmost window in the Z-order. Fair enough. But, to
this day, there has been NO attempt by Micro$oft to fix this particular
problem. WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip windows
Z-order priority over ALL other windows!

OK, there are some workarounds, but none of them work universally and
most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the taskbar on top
of
other windows" option, and then re-enabling the option. Fine and dandy
except that it has NEVER, EVER worked on ANY of my systems (and quite
likely yours as well). Indeed, permanently disabling the option has been
(until now) the ONLY "workaround" that is guaranteed to work every time.
If only we didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject

(http://support.microsoft.com/default...0&sd=rss&spid=
3223)
states that the problem occurs when right-clicking and opening a My
Document or a Recent Document in the Start menu. Apart from anything
else, the problem occurs in many more ways than simply opening a
document. Show Desktop is just one. Sorting the menu is another. However,
the real killer is that Micro$oft then go on to recommend logging off or
rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results in the
context
menu itself being hidden BEHIND the taskbar. This is yet another symptom
of different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the tooltips will
swap
their Z-orders around. So if tooltips are already hidden behind the
taskbar, sorting the menu will bring them in front of the taskbar again.
But if you ever need to sort the menu in future, remember to do it TWICE
unless tooltips are already behind the taskbar. Repeating the sort
naturally has no effect on the menu order, but it fixes the Z-order
problem.

That's it! No logoff and certainly no reboot required. Just a simple
little workaround--and it will ALWAYS WORK on EVERY XP SYSTEM!

[PAUSE FOR APPLAUSE]

Thank you and good night.

Is it really asking too much
of Micro$oft to ensure that tooltips always remain on top of all other
windows? I think not.

It probably is. Microsoft has other things to worry about, like 10 critical
Updates a month. :-D

At least until you next right-click on an object in the start menu, or
choose Show Desktop, or do any of the 100 other tasks that contibute to
the problem.

I don't believe that I right clicked the Start Menu during that time (can't
be 100% sure) and I never use Show Desktop. Must be the 100 other tasks.
;-)

Which simply loses numerous notification icons in the process.

Not if you only have two notification icons.

Not only is it quicker, it is non-destructive (so long as you like your
menu sorted--and who doesn't?)

I don't. At least this part of it %allusersprofile%\Start Menu on the
Classic Start Menu. The part above Programs, Settings, Search, Help and
Support and Run, whatever it's called. I have eight shortcuts and two
folder shortcuts there.

I would just like to get rid of the balloon tips completely. But I can't.
All I could do was change the back ground color to white, the text to blue
and change the duration.

Right click Desktop | Properties | Appearances tab |
Advanced button | Item: Tooltip |
Color 1: is the back ground color
Color: is the font color

HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\
Explorer\TrayNotify
Value Name: BalloonTip
Data Type: REG_DWORD
Value Data: 0x00000001 (1)

1 = 1 second
3 = 3 seconds
5 = 5 seconds
et cetera

It's fine with me that they are hidden behind the Taskbar.

My favorite one is... Click here to begin. LOL

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In ,
Micky hunted and pecked:
"Wesley Vogel" wrote in message
...
Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

OK that fixed the Tooltips behind the Taskbar for me.

The question is for how long?

At least until you next right-click on an object in the start menu, or
choose Show Desktop, or do any of the 100 other tasks that contibute to
the problem. Ultimately, the problem is within Explorer itself, and
there's little you nor I can do about that. Is it really asking too much
of Micro$oft to ensure that tooltips always remain on top of all other
windows? I think not.

Your band-aid lasted as long as all the other band-aids do...

To be fair, I never said it was a permanent fix--only that it works on all
my systems when other methods failed. Indeed, sorting the menu will
actually cause the problem, hence you must sort the menu twice to restore
the status quo.

Rebooting or logging off and logging back on.

Which is complete overkill, IMHO. Sledghammer to crack a nut in other
words. It's hardly convenient when you're in the middle of something and
just want a notification tooltip in the system tray...

Or hiding the Taskbar then showing it again.

Which doesn't work on any my systems. Nor does moving the taskbar. Nor
toggling the "on top" option. Nor any of the other "snake oil" remedies
I've encountered.

Or killing explorer.exe and restarting it.

Which simply loses numerous notification icons in the process. It's
actually quicker to logoff and back on than it is to terminate and
relaunch each missing icon. Again, it's sheer overkill.

Nice try, but no applause here. ;-)

Party-pooper! ;-)

Although, I must say, your band-aid may be quicker to apply than the
others.

Not only is it quicker, it is non-destructive (so long as you like your
menu sorted--and who doesn't?) and it works every time on every
system--including your own! It may not be a permanent fix, but it's the
closest thing to a universal workaround to date.

In ,
Micky hunted and pecked:
According to Micro$oft, tooltips appear behind the taskbar because both
are trying to be the topmost window in the Z-order. Fair enough. But, to
this day, there has been NO attempt by Micro$oft to fix this particular
problem. WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip windows
Z-order priority over ALL other windows!

OK, there are some workarounds, but none of them work universally and
most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the taskbar on top
of
other windows" option, and then re-enabling the option. Fine and dandy
except that it has NEVER, EVER worked on ANY of my systems (and quite
likely yours as well). Indeed, permanently disabling the option has been
(until now) the ONLY "workaround" that is guaranteed to work every time.
If only we didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject


(http://support.microsoft.com/default...0&sd=rss&spid=
3223)
states that the problem occurs when right-clicking and opening a My
Document or a Recent Document in the Start menu. Apart from anything
else, the problem occurs in many more ways than simply opening a
document. Show Desktop is just one. Sorting the menu is another.
However, the real killer is that Micro$oft then go on to recommend
logging off or rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results in the
context
menu itself being hidden BEHIND the taskbar. This is yet another symptom
of different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the tooltips will
swap
their Z-orders around. So if tooltips are already hidden behind the
taskbar, sorting the menu will bring them in front of the taskbar again.
But if you ever need to sort the menu in future, remember to do it TWICE
unless tooltips are already behind the taskbar. Repeating the sort
naturally has no effect on the menu order, but it fixes the Z-order
problem.

That's it! No logoff and certainly no reboot required. Just a simple
little workaround--and it will ALWAYS WORK on EVERY XP SYSTEM!

[PAUSE FOR APPLAUSE]

Thank you and good night.

Hey, thanks!

applause

But you know, this is such a quick fix that I'm sure Microsoft could add it
in a heartbeat if they wanted to. Maybe in SP3...



"Micky" wrote in message
...
According to Micro$oft, tooltips appear behind the taskbar because both
are trying to be the topmost window in the Z-order. Fair enough. But, to
this day, there has been NO attempt by Micro$oft to fix this particular
problem. WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip windows
Z-order priority over ALL other windows!

OK, there are some workarounds, but none of them work universally and most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the taskbar on top of
other windows" option, and then re-enabling the option. Fine and dandy
except that it has NEVER, EVER worked on ANY of my systems (and quite
likely yours as well). Indeed, permanently disabling the option has been
(until now) the ONLY "workaround" that is guaranteed to work every time.
If only we didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject
(http://support.microsoft.com/default...=rss&spid=3223)
states that the problem occurs when right-clicking and opening a My
Document or a Recent Document in the Start menu. Apart from anything else,
the problem occurs in many more ways than simply opening a document. Show
Desktop is just one. Sorting the menu is another. However, the real killer
is that Micro$oft then go on to recommend logging off or rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results in the context
menu itself being hidden BEHIND the taskbar. This is yet another symptom
of different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the tooltips will swap
their Z-orders around. So if tooltips are already hidden behind the
taskbar, sorting the menu will bring them in front of the taskbar again.
But if you ever need to sort the menu in future, remember to do it TWICE
unless tooltips are already behind the taskbar. Repeating the sort
naturally has no effect on the menu order, but it fixes the Z-order
problem.

That's it! No logoff and certainly no reboot required. Just a simple
little workaround--and it will ALWAYS WORK on EVERY XP SYSTEM!

[PAUSE FOR APPLAUSE]

Thank you and good night.

First, the disclaimer: I am not a programmer; my code experience was BASIC
many, many years ago. But after staying at a Holiday Inn Express
last....er, spending 30 years working on PCs, you do pick up a few things. I
have noticed that many registry entries are identical to the API calls used
by the code jockeys. So I thought I'd experiment a bit.

I've been researching this problem for a couple of days and every fix seen
so far has either not worked or only worked until the next reboot. Many
posts around the 'Net indicated that the problem is created by the taskbar
and tooltips fighting over who gets to be top of the Z order. Logically, it
seemed to me, since the tooltips are "on call" there should be some way to
include a specific "be on top" command to their instructions that would
override the Taskbar's global topmost command during their invocation.

So I read up on the tooltip programming by researching the command strings
found in the registry pertaining to the tooltips. Information found he
http://blogs.msdn.com/oldnewthing/ar...21/495246.aspx
led me he
http://msdn.microsoft.com/library/de...ndowfunctions/

which led to the experiment: After backing up (natch!), I made this
regedit:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer\VisualEffects\TooltipAnimation]

"SetWindowPos"="HwndInsertAfter, Hwnd_Top"
"SetForegroundWindow"=dword:00000001


The related HKCU values were of the "read defaults" nature so logically,
there had to be some defaults SOMEWHERE - HKLM seemed the reasonable place.

So far, so good - 3 days and some 10 reboots along and my tooltips are still
atop the taskbar with no killing the shell, reordering menus, sacrificing
goats or other hassles. Will it last? Who knows? I certainly don't claim
it will. But you're welcome to give it a whirl. Likely it's only one of
those entries that makes it work right - dunno which and don't care
(remember, I'm not a programmer so I don't sweat an extra line of code ).

Oh yeah - SP1+, Taskbar autohide/on top, ballontips off but all visual
effects on, no 3d party WindowsBlinds-ish toys.

Luck to you! Thanks for those who came before and posted...


"Paul Pedersen" wrote:

Hey, thanks!

applause

But you know, this is such a quick fix that I'm sure Microsoft could add it
in a heartbeat if they wanted to. Maybe in SP3...



"Micky" wrote in message
...
According to Micro$oft, tooltips appear behind the taskbar because both
are trying to be the topmost window in the Z-order. Fair enough. But, to
this day, there has been NO attempt by Micro$oft to fix this particular
problem. WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip windows
Z-order priority over ALL other windows!

OK, there are some workarounds, but none of them work universally and most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the taskbar on top of
other windows" option, and then re-enabling the option. Fine and dandy
except that it has NEVER, EVER worked on ANY of my systems (and quite
likely yours as well). Indeed, permanently disabling the option has been
(until now) the ONLY "workaround" that is guaranteed to work every time.
If only we didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject
(http://support.microsoft.com/default...=rss&spid=3223)
states that the problem occurs when right-clicking and opening a My
Document or a Recent Document in the Start menu. Apart from anything else,
the problem occurs in many more ways than simply opening a document. Show
Desktop is just one. Sorting the menu is another. However, the real killer
is that Micro$oft then go on to recommend logging off or rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results in the context
menu itself being hidden BEHIND the taskbar. This is yet another symptom
of different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the tooltips will swap
their Z-orders around. So if tooltips are already hidden behind the
taskbar, sorting the menu will bring them in front of the taskbar again.
But if you ever need to sort the menu in future, remember to do it TWICE
unless tooltips are already behind the taskbar. Repeating the sort
naturally has no effect on the menu order, but it fixes the Z-order
problem.

That's it! No logoff and certainly no reboot required. Just a simple
little workaround--and it will ALWAYS WORK on EVERY XP SYSTEM!

[PAUSE FOR APPLAUSE]

Thank you and good night.

I doubt this does anything at all. I'm writing this so when people search they don't waste time attempting this.

All you've found is the Options dialog. It fills in the sub command for this API (what the SPI stands for)



SystemParametersInfo
The SystemParametersInfo function retrieves or sets the value of one of the system-wide parameters. This function can also update the user profile while setting a parameter.

BOOL SystemParametersInfo(
UINT uiAction, // system parameter to retrieve or set
UINT uiParam, // depends on action to be taken
PVOID pvParam, // depends on action to be taken
UINT fWinIni // user profile update option
);Parameters
uiAction
[in] Specifies the system-wide parameter to retrieve or set. This parameter can be one of the values from the following tables.
The following are the accessibility parameters. Accessibility parameter Meaning
SPI_GETACCESSTIMEOUT Retrieves information about the time-out period associated with the accessibility features. The pvParam parameter must point to an ACCESSTIMEOUT structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(ACCESSTIMEOUT).
SPI_GETFILTERKEYS Retrieves information about the FilterKeys accessibility feature. The pvParam parameter must point to a FILTERKEYS structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(FILTERKEYS).
SPI_GETFOCUSBORDERHEIGHT Windows XP: Gets the height, in pixels, of the top and bottom edges of the focus rectangle drawn with DrawFocusRect. The pvParam parameter must point to a UINT.
SPI_GETFOCUSBORDERWIDTH Windows XP: Gets the width, in pixels, of the left and right edges of the focus rectangle drawn with DrawFocusRect. The pvParam parameter must point to a UINT.
SPI_GETHIGHCONTRAST Windows 95/98/Me, Windows 2000/XP: Retrieves information about the HighContrast accessibility feature. The pvParam parameter must point to a HIGHCONTRAST structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(HIGHCONTRAST).
SPI_GETMOUSECLICKLOCK Windows Me, Windows XP: Gets the state of the Mouse ClickLock feature. The pvParam parameter must point to a BOOL variable that receives TRUE if enabled, or FALSE otherwise. For more information, see About Mouse Input.
SPI_GETMOUSECLICKLOCKTIME Windows Me, Windows XP: Gets the time delay before the primary mouse button is locked. The pvParam parameter must point to DWORD that receives the time delay. This is only enabled if SPI_SETMOUSECLICKLOCK is set to TRUE. For more information, see About Mouse Input.
SPI_GETMOUSEKEYS Retrieves information about the MouseKeys accessibility feature. The pvParam parameter must point to a MOUSEKEYS structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(MOUSEKEYS).
SPI_GETMOUSESONAR Windows Me, Windows XP: Gets the state of the Mouse Sonar feature. The pvParam parameter must point to a BOOL variable that receives TRUE if enabled or FALSE otherwise. For more information, see About Mouse Input.
SPI_GETMOUSEVANISH Windows Me, Windows XP: Gets the state of the Mouse Vanish feature. The pvParam parameter must point to a BOOL variable that receives TRUE if enabled or FALSE otherwise. For more information, see About Mouse Input.
SPI_GETSCREENREADER Windows 95/98/Me, Windows 2000/XP: Determines whether a screen reviewer utility is running. A screen reviewer utility directs textual information to an output device, such as a speech synthesizer or Braille display. When this flag is set, an application should provide textual information in situations where it would otherwise present the information graphically.
The pvParam parameter is a pointer to a BOOL variable that receives TRUE if a screen reviewer utility is running, or FALSE otherwise.

SPI_GETSERIALKEYS Windows 95/98/Me: Retrieves information about the SerialKeys accessibility feature. The pvParam parameter must point to a SERIALKEYS structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(SERIALKEYS).
Windows NT/2000/XP: Not supported.

SPI_GETSHOWSOUNDS Determines whether the Show Sounds accessibility flag is on or off. If it is on, the user requires an application to present information visually in situations where it would otherwise present the information only in audible form. The pvParam parameter must point to a BOOL variable that receives TRUE if the feature is on, or FALSE if it is off.
Using this value is equivalent to calling GetSystemMetrics (SM_SHOWSOUNDS). That is the recommended call.

SPI_GETSOUNDSENTRY Retrieves information about the SoundSentry accessibility feature. The pvParam parameter must point to a SOUNDSENTRY structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(SOUNDSENTRY).
SPI_GETSTICKYKEYS Retrieves information about the StickyKeys accessibility feature. The pvParam parameter must point to a STICKYKEYS structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(STICKYKEYS).
SPI_GETTOGGLEKEYS Retrieves information about the ToggleKeys accessibility feature. The pvParam parameter must point to a TOGGLEKEYS structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(TOGGLEKEYS).
SPI_SETACCESSTIMEOUT Sets the time-out period associated with the accessibility features. The pvParam parameter must point to an ACCESSTIMEOUT structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(ACCESSTIMEOUT).
SPI_SETFILTERKEYS Sets the parameters of the FilterKeys accessibility feature. The pvParam parameter must point to a FILTERKEYS structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(FILTERKEYS).
SPI_SETFOCUSBORDERHEIGHT Windows XP: Sets the height of the top and bottom edges of the focus rectangle drawn with DrawFocusRect to the value of the pvParam parameter.
SPI_SETFOCUSBORDERWIDTH Windows XP: Sets the height of the left and right edges of the focus rectangle drawn with DrawFocusRect to the value of the pvParam parameter.
SPI_SETHIGHCONTRAST Windows 95/98/Me, Windows 2000/XP: Sets the parameters of the HighContrast accessibility feature. The pvParam parameter must point to a HIGHCONTRAST structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(HIGHCONTRAST).
SPI_SETMOUSECLICKLOCK Windows Me, Windows XP: Turns the Mouse ClickLock accessibility feature on or off. This feature temporarily locks down the primary mouse button when that button is clicked and held down for the time specified by SPI_SETMOUSECLICKLOCKTIME. The uiParam parameter specifies TRUE for on, or FALSE for off. The default is off. For more information, see Remarks and About Mouse Input.
SPI_SETMOUSECLICKLOCKTIME Windows Me, Windows XP: Adjusts the time delay before the primary mouse button is locked. The uiParam parameter specifies the time delay in microseconds. For example, specify 1000 for a 1 second delay. The default is 1200. For more information, see About Mouse Input.
SPI_SETMOUSEKEYS Sets the parameters of the MouseKeys accessibility feature. The pvParam parameter must point to a MOUSEKEYS structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(MOUSEKEYS).
SPI_SETMOUSESONAR Windows Me, Windows XP: Turns the Sonar accessibility feature on or off. This feature briefly shows several concentric circles around the mouse pointer when the user presses and releases the CTRL key. The pvParam parameter specifies TRUE for on and FALSE for off. The default is off. For more information, see About Mouse Input.
SPI_SETMOUSEVANISH Windows Me, Windows XP: Turns the Vanish feature on or off. This feature hides the mouse pointer when the user types; the pointer reappears when the user moves the mouse. The pvParam parameter specifies TRUE for on and FALSE for off. The default is off. For more information, see About Mouse Input.
SPI_SETSCREENREADER Windows 95/98/Me, Windows 2000/XP: Indicates whether a screen review utility is running. The uiParam parameter specifies TRUE for on, or FALSE for off.
SPI_SETSERIALKEYS Windows 95/98/Me: Sets the parameters of the SerialKeys accessibility feature. The pvParam parameter must point to a SERIALKEYS structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(SERIALKEYS).
SPI_SETSHOWSOUNDS Sets the ShowSounds accessibility feature as on or off. The uiParam parameter specifies TRUE for on, or FALSE for off.
SPI_SETSOUNDSENTRY Sets the parameters of the SoundSentry accessibility feature. The pvParam parameter must point to a SOUNDSENTRY structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(SOUNDSENTRY).
SPI_SETSTICKYKEYS Sets the parameters of the StickyKeys accessibility feature. The pvParam parameter must point to a STICKYKEYS structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(STICKYKEYS).
SPI_SETTOGGLEKEYS Sets the parameters of the ToggleKeys accessibility feature. The pvParam parameter must point to a TOGGLEKEYS structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(TOGGLEKEYS).



The following are the desktop parameters. Desktop parameter Meaning
SPI_GETDESKWALLPAPER Windows 2000/XP: Retrieves the full path of the bitmap file for the desktop wallpaper. The pvParam parameter must point to a buffer that receives a null-terminated path string. Set the uiParam parameter to the size, in characters, of the pvParam buffer. The returned string will not exceed MAX_PATH characters. If there is no desktop wallpaper, the returned string is empty.
SPI_GETDROPSHADOW Windows XP: Indicates whether the drop shadow effect is enabled. The pvParam parameter must point to a BOOL variable that returns TRUE if enabled or FALSE if disabled.
SPI_GETFLATMENU Windows XP: Indicates whether native User menus have flat menu appearance. The pvParam parameter must point to a BOOL variable that returns TRUE if the flat menu appearance is set, or FALSE otherwise.
SPI_GETFONTSMOOTHING Indicates whether the font smoothing feature is enabled. This feature uses font antialiasing to make font curves appear smoother by painting pixels at different gray levels.
The pvParam parameter must point to a BOOL variable that receives TRUE if the feature is enabled, or FALSE if it is not.

Windows 95: This flag is supported only if Windows Plus! is installed. See SPI_GETWINDOWSEXTENSION.

SPI_GETFONTSMOOTHINGCONTRAST Windows XP: Returns a contrast value that is used in ClearTypeâ„¢ smoothing. The pvParam parameter must point to a UINT that receives the information.
SPI_GETFONTSMOOTHINGTYPE Windows XP: Returns the type of font smoothing. The pvParam parameter must point to a UINT that receives the information.
SPI_GETWORKAREA Retrieves the size of the work area on the primary display monitor. The work area is the portion of the screen not obscured by the system taskbar or by application desktop toolbars. The pvParam parameter must point to a RECT structure that receives the coordinates of the work area, expressed in virtual screen coordinates.
To get the work area of a monitor other than the primary display monitor, call the GetMonitorInfo function.

SPI_SETCURSORS Reloads the system cursors. Set the uiParam parameter to zero and the pvParam parameter to NULL
SPI_SETDESKPATTERN Sets the current desktop pattern by causing Windows to read the Pattern= setting from the WIN.INI file.
SPI_SETDESKWALLPAPER Sets the desktop wallpaper. The value of the pvParam parameter determines the new wallpaper. To specify a wallpaper bitmap, set pvParam to point to a null-terminated string containing the name of a bitmap file. Setting pvParam to "" removes the wallpaper. Setting pvParam to SETWALLPAPER_DEFAULT or NULL reverts to the default wallpaper.
SPI_SETDROPSHADOW Windows XP: Enables or disables the drop shadow effect. Set pvParam to TRUE to enable the drop shadow effect or FALSE to disable it. You must also have CS_DROPSHADOW in the window class style.
SPI_SETFLATMENU Windows XP: Enables or disables flat menu appearance for native User menus. Set pvParam to TRUE to enable flat menu appearance or FALSE to disable it.
When enabled, the menu bar uses COLOR_MENUBAR for the menubar background, COLOR_MENU for the menu-popup background, COLOR_MENUHILIGHT for the fill of the current menu selection, and COLOR_HILIGHT for the outline of the current menu selection. If disabled, menus are drawn using the same metrics and colors as in Windows 2000 and earlier.

SPI_SETFONTSMOOTHING Enables or disables the font smoothing feature, which uses font antialiasing to make font curves appear smoother by painting pixels at different gray levels.
To enable the feature, set the uiParam parameter to TRUE. To disable the feature, set uiParam to FALSE.

Windows 95: This flag is supported only if Windows Plus! is installed. See SPI_GETWINDOWSEXTENSION.

SPI_SETFONTSMOOTHINGCONTRAST Windows XP: Changes the contrast value used in ClearType smoothing. The pvParam parameter points to a UINT that holds the contrast value. Valid contrast values are from 1000 to 2200. The default value is 1400.
SPI_SETFONTSMOOTHINGTYPE must also be set to FE_FONTSMOOTHINGCLEARTYPE.

SPI_SETFONTSMOOTHINGTYPE Windows XP: Changes the font smoothing type. The pvParam parameter points to a UINT that contains either FE_FONTSMOOTHINGSTANDARD, if standard anti-aliasing is used, or FE_FONTSMOOTHINGCLEARTYPE, if ClearType is used. The default is FE_FONTSMOOTHINGSTANDARD.
SPI_SETFONTSMOOTHING must also be set.

SPI_SETWORKAREA Sets the size of the work area. The work area is the portion of the screen not obscured by the system taskbar or by application desktop toolbars. The pvParam parameter is a pointer to a RECT structure that specifies the new work area rectangle, expressed in virtual screen coordinates. In a system with multiple display monitors, the function sets the work area of the monitor that contains the specified rectangle.
If pvParam is NULL, the function sets the work area of the primary display monitor to the full screen.




The following are the icon parameters. Icon parameter Meaning
SPI_GETICONMETRICS Retrieves the metrics associated with icons. The pvParam parameter must point to an ICONMETRICS structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(ICONMETRICS).
SPI_GETICONTITLELOGFONT Retrieves the logical font information for the current icon-title font. The uiParam parameter specifies the size of a LOGFONT structure, and the pvParam parameter must point to the LOGFONT structure to fill in.
SPI_GETICONTITLEWRAP Determines whether icon-title wrapping is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE if enabled, or FALSE otherwise.
SPI_ICONHORIZONTALSPACING Sets or retrieves the width, in pixels, of an icon cell. The system uses this rectangle to arrange icons in large icon view.
To set this value, set uiParam to the new value and set pvParam to NULL. You cannot set this value to less than SM_CXICON.

To retrieve this value, pvParam must point to an integer that receives the current value.

SPI_ICONVERTICALSPACING Sets or retrieves the height, in pixels, of an icon cell.
To set this value, set uiParam to the new value and set pvParam to NULL. You cannot set this value to less than SM_CYICON.

To retrieve this value, pvParam must point to an integer that receives the current value.

SPI_SETICONMETRICS Sets the metrics associated with icons. The pvParam parameter must point to an ICONMETRICS structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(ICONMETRICS).
SPI_SETICONS Reloads the system icons. Set the uiParam parameter to zero and the pvParam parameter to NULL
SPI_SETICONTITLELOGFONT Sets the font that is used for icon titles. The uiParam parameter specifies the size of a LOGFONT structure, and the pvParam parameter must point to a LOGFONT structure.
SPI_SETICONTITLEWRAP Turns icon-title wrapping on or off. The uiParam parameter specifies TRUE for on, or FALSE for off.



The following are the input parameters. They include parameters related to the keyboard, mouse, input language, and the warning beeper. Input parameter Meaning
SPI_GETBEEP Indicates whether the warning beeper is on.
The pvParam parameter must point to a BOOL variable that receives TRUE if the beeper is on, or FALSE if it is off.

SPI_GETDEFAULTINPUTLANG Returns the input locale identifier for the system default input language. The pvParam parameter must point to an HKL variable that receives this value. For more information, see Languages, Locales, and Keyboard Layouts.
SPI_GETKEYBOARDCUES Windows 98/Me, Windows 2000/XP: Indicates whether menu access keys are always underlined. The pvParam parameter must point to a BOOL variable that receives TRUE if menu access keys are always underlined, and FALSE if they are underlined only when the menu is activated by the keyboard.
SPI_GETKEYBOARDDELAY Retrieves the keyboard repeat-delay setting, which is a value in the range from 0 (approximately 250 ms delay) through 3 (approximately 1 second delay). The actual delay associated with each value may vary depending on the hardware. The pvParam parameter must point to an integer variable that receives the setting.
SPI_GETKEYBOARDPREF Windows 95/98/Me, Windows 2000/XP: Determines whether the user relies on the keyboard instead of the mouse, and wants applications to display keyboard interfaces that would otherwise be hidden. The pvParam parameter must point to a BOOL variable that receives TRUE if the user relies on the keyboard; or FALSE otherwise.
SPI_GETKEYBOARDSPEED Retrieves the keyboard repeat-speed setting, which is a value in the range from 0 (approximately 2.5 repetitions per second) through 31 (approximately 30 repetitions per second). The actual repeat rates are hardware-dependent and may vary from a linear scale by as much as 20%. The pvParam parameter must point to a DWORD variable that receives the setting.
SPI_GETMOUSE Retrieves the two mouse threshold values and the mouse acceleration. The pvParam parameter must point to an array of three integers that receives these values. See mouse_event for further information.
SPI_GETMOUSEHOVERHEIGHT Gets the height, in pixels, of the rectangle within which the mouse pointer has to stay for TrackMouseEvent to generate a WM_MOUSEHOVER message. The pvParam parameter must point to a UINT variable that receives the height.
Windows 95: Not supported.

SPI_GETMOUSEHOVERTIME Gets the time, in milliseconds, that the mouse pointer has to stay in the hover rectangle for TrackMouseEvent to generate a WM_MOUSEHOVER message. The pvParam parameter must point to a UINT variable that receives the time.
Windows 95: Not supported.

SPI_GETMOUSEHOVERWIDTH Gets the width, in pixels, of the rectangle within which the mouse pointer has to stay for TrackMouseEvent to generate a WM_MOUSEHOVER message. The pvParam parameter must point to a UINT variable that receives the width.
Windows 95: Not supported.

SPI_GETMOUSESPEED Windows 98/Me, Windows 2000/XP: Retrieves the current mouse speed. The mouse speed determines how far the pointer will move based on the distance the mouse moves. The pvParam parameter must point to an integer that receives a value which ranges between 1 (slowest) and 20 (fastest). A value of 10 is the default. The value can be set by an end user using the mouse control panel application or by an application using SPI_SETMOUSESPEED.
SPI_GETMOUSETRAILS Windows 95/98/Me, Windows XP: Indicates whether the Mouse Trails feature is enabled. This feature improves the visibility of mouse cursor movements by briefly showing a trail of cursors and quickly erasing them.
The pvParam parameter must point to an integer variable that receives a value. If the value is zero or 1, the feature is disabled. If the value is greater than 1, the feature is enabled and the value indicates the number of cursors drawn in the trail. The uiParam parameter is not used.

SPI_GETSNAPTODEFBUTTON Determines whether the snap-to-default-button feature is enabled. If enabled, the mouse cursor automatically moves to the default button, such as OK or Apply, of a dialog box. The pvParam parameter must point to a BOOL variable that receives TRUE if the feature is on, or FALSE if it is off.
Windows 95: Not supported.

SPI_GETWHEELSCROLLLINES Gets the number of lines to scroll when the mouse wheel is rotated. The pvParam parameter must point to a UINT variable that receives the number of lines. The default value is 3.
Windows 95: Not supported.

SPI_SETBEEP Turns the warning beeper on or off. The uiParam parameter specifies TRUE for on, or FALSE for off.
SPI_SETDEFAULTINPUTLANG Sets the default input language for the system shell and applications. The specified language must be displayable using the current system character set. The pvParam parameter must point to an HKL variable that contains the input locale identifier for the default language. For more information, see Languages, Locales, and Keyboard Layouts.
SPI_SETDOUBLECLICKTIME Sets the double-click time for the mouse to the value of the uiParam parameter. The double-click time is the maximum number of milliseconds that can occur between the first and second clicks of a double-click. You can also call the SetDoubleClickTime function to set the double-click time. To get the current double-click time, call the GetDoubleClickTime function.
SPI_SETDOUBLECLKHEIGHT Sets the height of the double-click rectangle to the value of the uiParam parameter.
The double-click rectangle is the rectangle within which the second click of a double-click must fall for it to be registered as a double-click.

To retrieve the height of the double-click rectangle, call GetSystemMetrics with the SM_CYDOUBLECLK flag.

SPI_SETDOUBLECLKWIDTH Sets the width of the double-click rectangle to the value of the uiParam parameter.
The double-click rectangle is the rectangle within which the second click of a double-click must fall for it to be registered as a double-click.

To retrieve the width of the double-click rectangle, call GetSystemMetrics with the SM_CXDOUBLECLK flag.

SPI_SETKEYBOARDCUES Windows 98/Me, Windows 2000/XP: Sets the underlining of menu access key letters. The pvParam parameter is a BOOL variable. Set pvParam to TRUE to always underline menu access keys, or FALSE to underline menu access keys only when the menu is activated from the keyboard.
SPI_SETKEYBOARDDELAY Sets the keyboard repeat-delay setting. The uiParam parameter must specify 0, 1, 2, or 3, where zero sets the shortest delay (approximately 250 ms) and 3 sets the longest delay (approximately 1 second). The actual delay associated with each value may vary depending on the hardware.
SPI_SETKEYBOARDPREF Windows 95/98, Windows 2000/XP: Sets the keyboard preference. The uiParam parameter specifies TRUE if the user relies on the keyboard instead of the mouse, and wants applications to display keyboard interfaces that would otherwise be hidden; uiParam is FALSE otherwise.
SPI_SETKEYBOARDSPEED Sets the keyboard repeat-speed setting. The uiParam parameter must specify a value in the range from 0 (approximately 2.5 repetitions per second) through 31 (approximately 30 repetitions per second). The actual repeat rates are hardware-dependent and may vary from a linear scale by as much as 20%. If uiParam is greater than 31, the parameter is set to 31.
SPI_SETLANGTOGGLE Sets the hot key set for switching between input languages. The uiParam and pvParam parameters are not used. The value sets the shortcut keys in the keyboard property sheets by reading the registry again. The registry must be set before this flag is used. the path in the registry is \HKEY_CURRENT_USER\keyboard layout\toggle. Valid values are "1" = ALT+SHIFT, "2" = CTRL+SHIFT, and "3" = none.
SPI_SETMOUSE Sets the two mouse threshold values and the mouse acceleration. The pvParam parameter must point to an array of three integers that specifies these values. See mouse_event for further information.
SPI_SETMOUSEBUTTONSWAP Swaps or restores the meaning of the left and right mouse buttons. The uiParam parameter specifies TRUE to swap the meanings of the buttons, or FALSE to restore their original meanings.
SPI_SETMOUSEHOVERHEIGHT Sets the height, in pixels, of the rectangle within which the mouse pointer has to stay for TrackMouseEvent to generate a WM_MOUSEHOVER message. Set the uiParam parameter to the new height.
Windows 95: Not supported.

SPI_SETMOUSEHOVERTIME Sets the time, in milliseconds, that the mouse pointer has to stay in the hover rectangle for TrackMouseEvent to generate a WM_MOUSEHOVER message. This is used only if you pass HOVER_DEFAULT in the dwHoverTime parameter in the call to TrackMouseEvent. Set the uiParam parameter to the new time.
Windows 95: Not supported.

SPI_SETMOUSEHOVERWIDTH Sets the width, in pixels, of the rectangle within which the mouse pointer has to stay for TrackMouseEvent to generate a WM_MOUSEHOVER message. Set the uiParam parameter to the new width.
Windows 95: Not supported.

SPI_SETMOUSESPEED Windows 98/Me, Windows 2000/XP: Sets the current mouse speed. The pvParam parameter is an integer between 1 (slowest) and 20 (fastest). A value of 10 is the default. This value is typically set using the mouse control panel application.
SPI_SETMOUSETRAILS Windows 95/98/Me, Windows XP: Enables or disables the Mouse Trails feature, which improves the visibility of mouse cursor movements by briefly showing a trail of cursors and quickly erasing them.
To disable the feature, set the uiParam parameter to zero or 1. To enable the feature, set uiParam to a value greater than 1 to indicate the number of cursors drawn in the trail.

SPI_SETSNAPTODEFBUTTON Enables or disables the snap-to-default-button feature. If enabled, the mouse cursor automatically moves to the default button, such as OK or Apply, of a dialog box. Set the uiParam parameter to TRUE to enable the feature, or FALSE to disable it. Applications should use the ShowWindow function when displaying a dialog box so the dialog manager can position the mouse cursor.
Windows 95: Not supported.

SPI_SETWHEELSCROLLLINES Sets the number of lines to scroll when the mouse wheel is rotated. The number of lines is set from the uiParam parameter.
The number of lines is the suggested number of lines to scroll when the mouse wheel is rolled without using modifier keys. If the number is 0, then no scrolling should occur. If the number of lines to scroll is greater than the number of lines viewable, and in particular if it is WHEEL_PAGESCROLL (#defined as UINT_MAX), the scroll operation should be interpreted as clicking once in the page down or page up regions of the scroll bar.

Windows 95: Not supported.




The following are the menu parameters. Menu parameter Meaning
SPI_GETMENUDROPALIGNMENT Determines whether pop-up menus are left-aligned or right-aligned, relative to the corresponding menu-bar item. The pvParam parameter must point to a BOOL variable that receives TRUE if left-aligned, or FALSE otherwise.
SPI_GETMENUFADE Windows 2000/XP: Indicates whether menu fade animation is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE when fade animation is enabled and FALSE when it is disabled. If fade animation is disabled, menus use slide animation. This flag is ignored unless menu animation is enabled, which you can do using the SPI_SETMENUANIMATION flag. For more information, see AnimateWindow.
SPI_GETMENUSHOWDELAY Indicates the time, in milliseconds, that the system waits before displaying a shortcut menu when the mouse cursor is over a submenu item. The pvParam parameter must point to a DWORD variable that receives the time of the delay.
Windows 95: Not supported.

SPI_SETMENUDROPALIGNMENT Sets the alignment value of pop-up menus. The uiParam parameter specifies TRUE for right alignment, or FALSE for left alignment.
SPI_SETMENUFADE Windows 2000/XP: Enables or disables menu fade animation. Set pvParam to TRUE to enable the menu fade effect or FALSE to disable it. If fade animation is disabled, menus use slide animation. he The menu fade effect is possible only if the system has a color depth of more than 256 colors. This flag is ignored unless SPI_MENUANIMATION is also set. For more information, see AnimateWindow.
SPI_SETMENUSHOWDELAY Set uiParam to the time, in milliseconds, that the system waits before displaying a shortcut menu when the mouse cursor is over a submenu item.
Windows 95: Not supported.




The following are the power parameters. Power parameter Meaning
SPI_GETLOWPOWERACTIVE Determines whether the low-power phase of screen saving is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE if enabled, or FALSE if disabled.
Windows 98/Me: This flag is supported for 16-bit and 32-bit applications.

Windows 95: This flag is supported for 16-bit applications only.

Windows 2000/XP: This flag is supported for 32-bit. It is not supported for 16-bit applications.

SPI_GETLOWPOWERTIMEOUT Retrieves the time-out value for the low-power phase of screen saving. The pvParam parameter must point to an integer variable that receives the value.
Windows 98/Me: This flag is supported for 16-bit and 32-bit applications.

Windows 95: This flag is supported for 16-bit applications only.

Windows 2000/XP: This flag is supported for 32-bit applications. It is not supported for 16-bit applications.

SPI_GETPOWEROFFACTIVE Determines whether the power-off phase of screen saving is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE if enabled, or FALSE if disabled.
Windows 98/Me: This flag is supported for 16-bit and 32-bit applications.

Windows 95: This flag is supported for 16-bit applications only.

Windows 2000/XP: This flag is supported for 32-bit applications. It is not supported for 16-bit applications.

SPI_GETPOWEROFFTIMEOUT Retrieves the time-out value for the power-off phase of screen saving. The pvParam parameter must point to an integer variable that receives the value.
Windows 98/Me: This flag is supported for 16-bit and 32-bit applications.

Windows 95: This flag is supported for 16-bit applications only.

Windows 2000/XP: This flag is supported for 32-bit applications. It is not supported for 16-bit applications.

SPI_SETLOWPOWERACTIVE Activates or deactivates the low-power phase of screen saving. Set uiParam to 1 to activate, or zero to deactivate. The pvParam parameter must be NULL.
Windows 98/Me: This flag is supported for 16-bit and 32-bit applications.

Windows 95: This flag is supported for 16-bit applications only.

Windows 2000/XP: This flag is supported for 32-bit applications. It is not supported for 16-bit applications.

SPI_SETLOWPOWERTIMEOUT Sets the time-out value, in seconds, for the low-power phase of screen saving. The uiParam parameter specifies the new value. The pvParam parameter must be NULL.
Windows 98/Me: This flag is supported for 16-bit and 32-bit applications.

Windows 95: This flag is supported for 16-bit applications only.

Windows 2000/XP: This flag is supported for 32-bit applications. It is not supported for 16-bit applications.

SPI_SETPOWEROFFACTIVE Activates or deactivates the power-off phase of screen saving. Set uiParam to 1 to activate, or zero to deactivate. The pvParam parameter must be NULL.
Windows 98/Me: This flag is supported for 16-bit and 32-bit applications.

Windows 95: This flag is supported for 16-bit applications only.

Windows 2000/XP: This flag is supported for 32-bit applications. It is not supported for 16-bit applications.

SPI_SETPOWEROFFTIMEOUT Sets the time-out value, in seconds, for the power-off phase of screen saving. The uiParam parameter specifies the new value. The pvParam parameter must be NULL.
Windows 98/Me: This flag is supported for 16-bit and 32-bit applications.

Windows 95: This flag is supported for 16-bit applications only.

Windows 2000/XP: This flag is supported for 32-bit applications. It is not supported for 16-bit applications.




The following are the screen saver parameters. Screen saver parameter Meaning
SPI_GETSCREENSAVEACTIVE Determines whether screen saving is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE if screen saving is enabled, or FALSE otherwise.
SPI_GETSCREENSAVERRUNNING Windows 98/Me, Windows 2000/XP: Determines whether a screen saver is currently running on the window station of the calling process. The pvParam parameter must point to a BOOL variable that receives TRUE if a screen saver is currently running, or FALSE otherwise. Note that only the interactive window station, "WinSta0", can have a screen saver running.
SPI_GETSCREENSAVETIMEOUT Retrieves the screen saver time-out value, in seconds. The pvParam parameter must point to an integer variable that receives the value.
SPI_SETSCREENSAVEACTIVE Sets the state of the screen saver. The uiParam parameter specifies TRUE to activate screen saving, or FALSE to deactivate it.
SPI_SETSCREENSAVERRUNNING Windows 95/98/Me: Used internally; applications should not use this flag.
SPI_SETSCREENSAVETIMEOUT Sets the screen saver time-out value to the value of the uiParam parameter. This value is the amount of time, in seconds, that the system must be idle before the screen saver activates.



The following are the UI effects parameters. The SPI_SETUIEFFECTS value is used to enable or disable all the UI effect values at once. This table contains the complete list of UI effect values. UI effects parameter Meaning
SPI_GETCOMBOBOXANIMATION Windows 98/Me, Windows 2000/XP: Indicates whether the slide-open effect for combo boxes is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE for enabled, or FALSE for disabled.
SPI_GETCURSORSHADOW Windows 2000/XP: Indicates whether the cursor has a shadow around it. The pvParam parameter must point to a BOOL variable that receives TRUE if the shadow is enabled, FALSE if it is disabled. This effect appears only if the system has a color depth of more than 256 colors.
SPI_GETGRADIENTCAPTIONS Windows 98/Me, Windows 2000/XP: Indicates whether the gradient effect for window title bars is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE for enabled, or FALSE for disabled. For more information about the gradient effect, see the GetSysColor function.
SPI_GETHOTTRACKING Windows 98/Me, Windows 2000/XP: Indicates whether hot tracking of user-interface elements, such as menu names on menu bars, is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE for enabled, or FALSE for disabled.
Hot tracking means that when the cursor moves over an item, it is highlighted but not selected. You can query this value to decide whether to use hot tracking in the user interface of your application.

SPI_GETLISTBOXSMOOTHSCROLLING Windows 98/Me, Windows 2000/XP: Indicates whether the smooth-scrolling effect for list boxes is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE for enabled, or FALSE for disabled.
SPI_GETMENUANIMATION Windows 98/Me, Windows 2000/XP: Indicates whether the menu animation feature is enabled. This master switch must be on to enable menu animation effects. The pvParam parameter must point to a BOOL variable that receives TRUE if animation is enabled and FALSE if it is disabled.
Windows 2000/XP: If animation is enabled, SPI_GETMENUFADE indicates whether menus use fade or slide animation.

SPI_GETMENUUNDERLINES Windows 98/Me, Windows 2000/XP: Same as SPI_GETKEYBOARDCUES.
SPI_GETSELECTIONFADE Windows 2000/XP: Indicates whether the selection fade effect is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE if enabled or FALSE if disabled.
The selection fade effect causes the menu item selected by the user to remain on the screen briefly while fading out after the menu is dismissed.

SPI_GETTOOLTIPANIMATION Windows 2000/XP: Indicates whether ToolTip animation is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE if enabled or FALSE if disabled. If ToolTip animation is enabled, SPI_GETTOOLTIPFADE indicates whether ToolTips use fade or slide animation.
SPI_GETTOOLTIPFADE Windows 2000/XP: If SPI_SETTOOLTIPANIMATION is enabled, SPI_GETTOOLTIPFADE indicates whether ToolTip animation uses a fade effect or a slide effect. The pvParam parameter must point to a BOOL variable that receives TRUE for fade animation or FALSE for slide animation. For more information on slide and fade effects, see AnimateWindow.
SPI_GETUIEFFECTS Windows 2000/XP: Indicates whether all UI effects are disabled or not. The pvParam parameter must point to a BOOL variable that receives TRUE if UI effects are enabled, or FALSE if they are disabled. For the complete list of UI effects, see the Remarks section later in this topic.
SPI_SETCOMBOBOXANIMATION Windows 98/Me, Windows 2000/XP: Enables or disables the slide-open effect for combo boxes. Set the pvParam parameter to TRUE to enable the gradient effect, or FALSE to disable it.
SPI_SETCURSORSHADOW Windows 2000/XP: Enables or disables a shadow around the cursor. The pvParam parameter is a BOOL variable. Set pvParam to TRUE to enable the shadow or FALSE to disable the shadow. This effect appears only if the system has a color depth of more than 256 colors.
SPI_SETGRADIENTCAPTIONS Windows 98/Me, Windows 2000/XP: Enables or disables the gradient effect for window title bars. Set the pvParam parameter to TRUE to enable it, or FALSE to disable it. The gradient effect is possible only if the system has a color depth of more than 256 colors. For more information about the gradient effect, see the GetSysColor function.
SPI_SETHOTTRACKING Windows 98/Me, Windows 2000/XP: Enables or disables hot tracking of user-interface elements such as menu names on menu bars. Set the pvParam parameter to TRUE to enable it, or FALSE to disable it.
Hot-tracking means that when the cursor moves over an item, it is highlighted but not selected.

SPI_SETLISTBOXSMOOTHSCROLLING Windows 98/Me, Windows 2000/XP: Enables or disables the smooth-scrolling effect for list boxes. Set the pvParam parameter to TRUE to enable the smooth-scrolling effect, or FALSE to disable it.
SPI_SETMENUANIMATION Windows 98/Me, Windows 2000/XP: Enables or disables menu animation. This master switch must be on for any menu animation to occur. The pvParam parameter is a BOOL variable; set pvParam to TRUE to enable animation and FALSE to disable animation.
Windows 2000/XP: If animation is enabled, SPI_GETMENUFADE indicates whether menus use fade or slide animation.

SPI_SETMENUUNDERLINES Windows 98/Me, Windows 2000/XP: Same as SPI_SETKEYBOARDCUES.
SPI_SETSELECTIONFADE Windows 2000/XP: Set pvParam to TRUE to enable the selection fade effect or FALSE to disable it.
The selection fade effect causes the menu item selected by the user to remain on the screen briefly while fading out after the menu is dismissed. The selection fade effect is possible only if the system has a color depth of more than 256 colors.

SPI_SETTOOLTIPANIMATION Windows 2000/XP: Set pvParam to TRUE to enable ToolTip animation or FALSE to disable it. If enabled, you can use SPI_SETTOOLTIPFADE to specify fade or slide animation.
SPI_SETTOOLTIPFADE Windows 2000/XP: If the SPI_SETTOOLTIPANIMATION flag is enabled, use SPI_SETTOOLTIPFADE to indicate whether ToolTip animation uses a fade effect or a slide effect. Set pvParam to TRUE for fade animation or FALSE for slide animation. The tooltip fade effect is possible only if the system has a color depth of more than 256 colors. For more information on the slide and fade effects, see the AnimateWindow function.
SPI_SETUIEFFECTS Windows 2000/XP: Enables or disables UI effects. Set the pvParam parameter to TRUE to enable all UI effects or FALSE to disable all UI effects. For the complete list of UI effects, see the Remarks section later in this topic.



The following are the window parameters. Window parameter Meaning
SPI_GETACTIVEWINDOWTRACKING Windows 98/Me, Windows 2000/XP: Indicates whether active window tracking (activating the window the mouse is on) is on or off. The pvParam parameter must point to a BOOL variable that receives TRUE for on, or FALSE for off.
SPI_GETACTIVEWNDTRKZORDER Windows 98/Me, Windows 2000/XP: Indicates whether windows activated through active window tracking will be brought to the top. The pvParam parameter must point to a BOOL variable that receives TRUE for on, or FALSE for off.
SPI_GETACTIVEWNDTRKTIMEOUT Windows 98/Me, Windows 2000/XP: Indicates the active window tracking delay, in milliseconds. The pvParam parameter must point to a DWORD variable that receives the time.
SPI_GETANIMATION Retrieves the animation effects associated with user actions. The pvParam parameter must point to an ANIMATIONINFO structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(ANIMATIONINFO).
SPI_GETBORDER Retrieves the border multiplier factor that determines the width of a window's sizing border. The pvParam parameter must point to an integer variable that receives this value.
SPI_GETCARETWIDTH Windows 2000/XP: Indicates the caret width in edit controls. The pvParam parameter must point to a DWORD that receives the width of the caret in pixels.
SPI_GETDRAGFULLWINDOWS Determines whether dragging of full windows is enabled. The pvParam parameter must point to a BOOL variable that receives TRUE if enabled, or FALSE otherwise.
Windows 95: This flag is supported only if Windows Plus! is installed. See SPI_GETWINDOWSEXTENSION.

SPI_GETFOREGROUNDFLASHCOUNT Windows 98/Me, Windows 2000/XP: Indicates the number of times SetForegroundWindow will flash the taskbar button when rejecting a foreground switch request. The pvParam parameter must point to a DWORD variable that receives the value.
SPI_GETFOREGROUNDLOCKTIMEOUT Windows 98/Me, Windows 2000/XP: Indicates the amount of time following user input, in milliseconds, during which the system will not allow applications to force themselves into the foreground. The pvParam parameter must point to a DWORD variable that receives the time.
SPI_GETMINIMIZEDMETRICS Retrieves the metrics associated with minimized windows. The pvParam parameter must point to a MINIMIZEDMETRICS structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(MINIMIZEDMETRICS).
SPI_GETNONCLIENTMETRICS Retrieves the metrics associated with the nonclient area of nonminimized windows. The pvParam parameter must point to a NONCLIENTMETRICS structure that receives the information. Set the cbSize member of this structure and the uiParam parameter to sizeof(NONCLIENTMETRICS).
SPI_GETSHOWIMEUI Windows 98/Me, Windows 2000/XP: Indicates whether the IME status window is visible (on a per-user basis). The pvParam parameter must point to a BOOL variable that receives TRUE if the status window is visible, or FALSE if it is not.
SPI_SETACTIVEWINDOWTRACKING Windows 98/Me, Windows 2000/XP: Sets active window tracking (activating the window the mouse is on) either on or off. Set pvParam to TRUE for on or FALSE for off.
SPI_SETACTIVEWNDTRKZORDER Windows 98/Me, Windows 2000/XP: Indicates whether or not windows activated through active window tracking should be brought to the top. Set pvParam to TRUE for on or FALSE for off.
SPI_SETACTIVEWNDTRKTIMEOUT Windows 98/Me, Windows 2000/XP: Sets the active window tracking delay. Set pvParam to the number of milliseconds to delay before activating the window under the mouse pointer.
SPI_SETANIMATION Sets the animation effects associated with user actions. The pvParam parameter must point to an ANIMATIONINFO structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(ANIMATIONINFO).
SPI_SETBORDER Sets the border multiplier factor that determines the width of a window's sizing border. The uiParam parameter specifies the new value.
SPI_SETCARETWIDTH Windows 2000/XP: Sets the caret width in edit controls. Set pvParam to the desired width, in pixels. The default and minimum value is 1.
SPI_SETDRAGFULLWINDOWS Sets dragging of full windows either on or off. The uiParam parameter specifies TRUE for on, or FALSE for off.
Windows 95: This flag is supported only if Windows Plus! is installed. See SPI_GETWINDOWSEXTENSION.

SPI_SETDRAGHEIGHT Sets the height, in pixels, of the rectangle used to detect the start of a drag operation. Set uiParam to the new value. To retrieve the drag height, call GetSystemMetrics with the SM_CYDRAG flag.
SPI_SETDRAGWIDTH Sets the width, in pixels, of the rectangle used to detect the start of a drag operation. Set uiParam to the new value. To retrieve the drag width, call GetSystemMetrics with the SM_CXDRAG flag.
SPI_SETFOREGROUNDFLASHCOUNT Windows 98/Me, Windows 2000/XP: Sets the number of times SetForegroundWindow will flash the taskbar button when rejecting a foreground switch request. Set pvParam to the number of times to flash.
SPI_SETFOREGROUNDLOCKTIMEOUT Windows 98/Me, Windows 2000/XP: Sets the amount of time following user input, in milliseconds, during which the system will not allow applications to force themselves into the foreground. Set pvParam to the new timeout value.
SPI_SETMINIMIZEDMETRICS Sets the metrics associated with minimized windows. The pvParam parameter must point to a MINIMIZEDMETRICS structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(MINIMIZEDMETRICS).
SPI_SETNONCLIENTMETRICS Sets the metrics associated with the nonclient area of nonminimized windows. The pvParam parameter must point to a NONCLIENTMETRICS structure that contains the new parameters. Set the cbSize member of this structure and the uiParam parameter to sizeof(NONCLIENTMETRICS).
SPI_SETSHOWIMEUI Windows 98/Me, Windows 2000/XP: Sets whether the IME status window is visible or not on a per-user basis. The uiParam parameter specifies TRUE for on or FALSE for off.



The following parameters are specific to Windows 95, Windows 98, and Windows Me. Parameter Meaning
SPI_GETWINDOWSEXTENSION Windows 95: Indicates whether the Windows extension, Windows Plus!, is installed. Set the uiParam parameter to 1. The pvParam parameter is not used. The function returns TRUE if the extension is installed, or FALSE if it is not.
SPI_SETPENWINDOWS Windows 95/98/Me: Specifies that pen windows is being loaded or unloaded. The uiParam parameter is TRUE when loading and FALSE when unloading pen windows. The pvParam parameter is NULL.



uiParam
[in] Depends on the system parameter being queried or set. For more information about system-wide parameters, see the uiAction parameter. If not otherwise indicated, you must specify zero for this parameter.
pvParam
[in/out] Depends on the system parameter being queried or set. For more information about system-wide parameters, see the uiAction parameter. If not otherwise indicated, you must specify NULL for this parameter.
fWinIni
[in] If a system parameter is being set, specifies whether the user profile is to be updated, and if so, whether the WM_SETTINGCHANGE message is to be broadcast to all top-level windows to notify them of the change.
This parameter can be zero if you don't want to update the user profile or broadcast the WM_SETTINGCHANGE message, or it can be one or more of the following values. Value Action
SPIF_UPDATEINIFILE Writes the new system-wide parameter setting to the user profile.
SPIF_SENDCHANGE Broadcasts the WM_SETTINGCHANGE message after updating the user profile.
SPIF_SENDWININICHANGE Same as SPIF_SENDCHANGE.



Return Values
If the function succeeds, the return value is a nonzero value.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

Remarks
This function is intended for use with applications that allow the user to customize the environment.

A keyboard layout name should be derived from the hexadecimal value of the language identifier corresponding to the layout. For example, U.S. English has a language identifier of 0x0409, so the primary U.S. English layout is named "00000409." Variants of U.S. English layout, such as the Dvorak layout, are named "00010409," "00020409" and so on. For a list of the primary language identifiers and sublanguage identifiers that make up a language identifier, see the MAKELANGID macro.

Windows Me, Windows XP: During the time that the primary button is held down to activate the Mouse ClickLock feature, the user can move the mouse. Once the primary button is locked down, releasing the primary button does not result in a WM_LBUTTONUP message. Thus, it will appear to an application that the primary button is still down. Any subsequent button message releases the primary button, sending a WM_LBUTTONUP message to the application, thus the button can be unlocked programmatically or through the user clicking any button.

Windows 95/98/Me: SystemParametersInfoW is supported by the Microsoft Layer for Unicode. To use this, you must add certain files to your application, as outlined in Microsoft Layer for Unicode on Windows 95/98/Me Systems.

Example Code
For an example, see Getting Hardware Information.

Requirements
Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.
Header: Declared in Winuser.h; include Windows.h.
Library: Use User32.lib.
Unicode: Implemented as Unicode and ANSI versions on Windows NT/2000/XP. Also supported by Microsoft Layer for Unicode.

See Also
System Information Overview, System Information Functions, ACCESSTIMEOUT, ANIMATIONINFO, FILTERKEYS, HIGHCONTRAST, ICONMETRICS, LOGFONT, MAKELANGID, MINIMIZEDMETRICS, MOUSEKEYS, NONCLIENTMETRICS, RECT, SERIALKEYS, SOUNDSENTRY, STICKYKEYS, TOGGLEKEYS, WM_SETTINGCHANGE


Platform SDK Release: August 2001 What did you think of this topic?
Let us know. Order a Platform SDK CD Online
(U.S/Canada) (International)



Requirements
Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.
Header: Declared in Winuser.h; include Windows.h.
Library: Use User32.lib.
Unicode: Implemented as Unicode and ANSI versions on Windows NT/2000/XP. Also supported by Microsoft Layer for Unicode.

See Also
System Information Overview, System Information Functions, ACCESSTIMEOUT, ANIMATIONINFO, FILTERKEYS, HIGHCONTRAST, ICONMETRICS, LOGFONT, MAKELANGID, MINIMIZEDMETRICS, MOUSEKEYS, NONCLIENTMETRICS, RECT, SERIALKEYS, SOUNDSENTRY, STICKYKEYS, TOGGLEKEYS, WM_SETTINGCHANGE


--
--------------------------------------------------------------------------------------------------
Goodbye Web Diary
http://margokingston.typepad.com/har....html#comments
=================================================
"MrAnon" wrote in message ...
First, the disclaimer: I am not a programmer; my code experience was BASIC
many, many years ago. But after staying at a Holiday Inn Express
last....er, spending 30 years working on PCs, you do pick up a few things. I
have noticed that many registry entries are identical to the API calls used
by the code jockeys. So I thought I'd experiment a bit.

I've been researching this problem for a couple of days and every fix seen
so far has either not worked or only worked until the next reboot. Many
posts around the 'Net indicated that the problem is created by the taskbar
and tooltips fighting over who gets to be top of the Z order. Logically, it
seemed to me, since the tooltips are "on call" there should be some way to
include a specific "be on top" command to their instructions that would
override the Taskbar's global topmost command during their invocation.

So I read up on the tooltip programming by researching the command strings
found in the registry pertaining to the tooltips. Information found he
http://blogs.msdn.com/oldnewthing/ar...21/495246.aspx
led me he
http://msdn.microsoft.com/library/de...ndowfunctions/

which led to the experiment: After backing up (natch!), I made this
regedit:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer\VisualEffects\TooltipAnimation]

"SetWindowPos"="HwndInsertAfter, Hwnd_Top"
"SetForegroundWindow"=dword:00000001


The related HKCU values were of the "read defaults" nature so logically,
there had to be some defaults SOMEWHERE - HKLM seemed the reasonable place.

So far, so good - 3 days and some 10 reboots along and my tooltips are still
atop the taskbar with no killing the shell, reordering menus, sacrificing
goats or other hassles. Will it last? Who knows? I certainly don't claim
it will. But you're welcome to give it a whirl. Likely it's only one of
those entries that makes it work right - dunno which and don't care
(remember, I'm not a programmer so I don't sweat an extra line of code ).

Oh yeah - SP1+, Taskbar autohide/on top, ballontips off but all visual
effects on, no 3d party WindowsBlinds-ish toys.

Luck to you! Thanks for those who came before and posted...


"Paul Pedersen" wrote:

Hey, thanks!

applause

But you know, this is such a quick fix that I'm sure Microsoft could add it
in a heartbeat if they wanted to. Maybe in SP3...



"Micky" wrote in message
...
According to Micro$oft, tooltips appear behind the taskbar because both
are trying to be the topmost window in the Z-order. Fair enough. But, to
this day, there has been NO attempt by Micro$oft to fix this particular
problem. WHY IS THIS SO DIFFICULT TO FIX? Simply give tooltip windows
Z-order priority over ALL other windows!

OK, there are some workarounds, but none of them work universally and most
are nothing more than the ramblings of amateur dabblers.

By far the most popular "fix" is disabling the "Keep the taskbar on top of
other windows" option, and then re-enabling the option. Fine and dandy
except that it has NEVER, EVER worked on ANY of my systems (and quite
likely yours as well). Indeed, permanently disabling the option has been
(until now) the ONLY "workaround" that is guaranteed to work every time.
If only we didn't want the taskbar on top...

Furthermore, Micro$oft's KB article on the subject
(http://support.microsoft.com/default...=rss&spid=3223)
states that the problem occurs when right-clicking and opening a My
Document or a Recent Document in the Start menu. Apart from anything else,
the problem occurs in many more ways than simply opening a document. Show
Desktop is just one. Sorting the menu is another. However, the real killer
is that Micro$oft then go on to recommend logging off or rebooting...

Logoff? Reboot?? Sheesh! Give us a break Micro$oft! Just fix the damn
problem!!


OK, enough of my rants ... here's the REAL workaround:

Click Start
Click All Programs
Right-click ANY folder OR shortcut that appears ABOVE the taskbar*
Click Sort by Name

*Clicking items that appear OVER the taskbar simply results in the context
menu itself being hidden BEHIND the taskbar. This is yet another symptom
of different windows fighting to be "on top" of each other.

Every time you sort the start menu, the taskbar and the tooltips will swap
their Z-orders around. So if tooltips are already hidden behind the
taskbar, sorting the menu will bring them in front of the taskbar again.
But if you ever need to sort the menu in future, remember to do it TWICE
unless tooltips are already behind the taskbar. Repeating the sort
naturally has no effect on the menu order, but it fixes the Z-order
problem.

That's it! No logoff and certainly no reboot required. Just a simple
little workaround--and it will ALWAYS WORK on EVERY XP SYSTEM!

[PAUSE FOR APPLAUSE]

Thank you and good night.

"David Candy" wrote:

I doubt this does anything at all. I'm writing this so when people search they don't waste time attempting this.

All you've found is the Options dialog. It fills in the sub command for this API (what the SPI stands for)


First, let me point out again that I'm not a programmer so the somewhat
disparaging tone is out of place.

Second, let me thank you for cutting-and-pasting the entirety of the MSDN
entry on System Information Functions:
http://msdn.microsoft.com/library/de..._functions.asp
as I'm sure it will be more helpful than a simple link would have been to
readers. What I'm not sure of is *why* you did it since the material doesn't
pertain to the registry edits I posted.

Third, what does it matter if "all I've done..." is found an option
dialogue? If the hack works, does it matter where it is?

Fourth, I'm wondering if you actually *tried* the edit? Or did you just
poo-poo it because "it shouldn't work"? I'm not a code jockey, so if it does
work, great. If not, oh well - it's not as bad as some suggestions I've
seen. But really - wouldn't some hard empirical data be more useful to the
the Reading Masses? Shouldn't you *KNOW* before you claim something is
workable or not?

For the record: My tooltips are still above the bar about 90-95% of the
time. Sometimes immediately after opening something on the desktop the tips
will be hidden but so far have returned to the top after a couple of normal
window open/closings and taskbar unhides. It's been a week, lots of reboots
as I do some long-overdue maintenance and upgrades and 1 system state restore
and so far, so good. I'd be interested in some results if anyone tries this.



SystemParametersInfo
The SystemParametersInfo function retrieves or sets the value of one of the system-wide parameters. This function can also update the user profile while setting a parameter.


****Many pages snipped for the sake of readablity******

Dear David Candy -
If your intention is to convince us that Micro$oft Windows are complex
programs, thanks, but I think you are preaching an audience that would have
believed a simple statement, as well as to the choir.

MrAnon reports his activity and his results-to-date; IF his report is
accurate,
someone familiar with your material might be able to either explain his
success
(and more elegantly produce it, suggesting a fix to Micro$oft), or provide a
possible explanation of the apparent coincidence, perhaps leading back to the
fix. I have been a programmer (and systems analyst) [since I am considering
my
what my THIRD career will be, does that mean I am NO LONGER a
programmer?], and, to some extent, consider producing the desired outcome
causing any detectable harm to be a 'success', I think your and our efforts
could
be better spent in directing people [with a link and/or a citation] to the
text you provided, with more 'human' discussion and/or advise content HERE.

Thank you for your efforts, anyway, and THANK YOU to MrAnon. Right after my
taxes are done, I plan to back up MY registry and try MrAnon's suggestion.
You
might be interested in finding out whether his results can be replicated.

"David Candy" wrote:

I doubt this does anything at all. I'm writing this so when people search they don't waste time attempting this.

All you've found is the Options dialog. It fills in the sub command for this API (what the SPI stands for)



SystemParametersInfo what appears to be a copy of manual
I will NOT allow the inclusion of the history of this thread at
this point.
[even when the 'Discussion Group' software truncated it.]
If you NEED the details - some 200+ lines at this point,
read them above.

Writing WindowsProc in a text file does not make a program.

--
--------------------------------------------------------------------------------------------------
How to lose a war in Iraq
http://webdiary.com.au/cms/?q=node/1335#comment-48641
=================================================
"Hesch" wrote in message ...
Dear David Candy -
If your intention is to convince us that Micro$oft Windows are complex
programs, thanks, but I think you are preaching an audience that would have
believed a simple statement, as well as to the choir.

MrAnon reports his activity and his results-to-date; IF his report is
accurate,
someone familiar with your material might be able to either explain his
success
(and more elegantly produce it, suggesting a fix to Micro$oft), or provide a
possible explanation of the apparent coincidence, perhaps leading back to the
fix. I have been a programmer (and systems analyst) [since I am considering
my
what my THIRD career will be, does that mean I am NO LONGER a
programmer?], and, to some extent, consider producing the desired outcome
causing any detectable harm to be a 'success', I think your and our efforts
could
be better spent in directing people [with a link and/or a citation] to the
text you provided, with more 'human' discussion and/or advise content HERE.

Thank you for your efforts, anyway, and THANK YOU to MrAnon. Right after my
taxes are done, I plan to back up MY registry and try MrAnon's suggestion.
You
might be interested in finding out whether his results can be replicated.

"David Candy" wrote:

I doubt this does anything at all. I'm writing this so when people search they don't waste time attempting this.

All you've found is the Options dialog. It fills in the sub command for this API (what the SPI stands for)



SystemParametersInfo what appears to be a copy of manual
I will NOT allow the inclusion of the history of this thread at
this point.
[even when the 'Discussion Group' software truncated it.]
If you NEED the details - some 200+ lines at this point,
read them above.

Check out this web site for more information and a fix:
http://www.acquaviva.us/tooltipmanager

Tool Tip Manager specifically fixes this problem by looking at various
taskbar window messages and resetting the tooltip's "topmost" window
style automatically as needed.

Regards,

Nick Acquaviva