By: Ryan Mills
Abstract: A paper describing some common Windows problems with the standard Alt-Tab functionality and a couple of hints on how to avoid them. By Ryan J. Mills.
Since the beginning of the Windows
operating system, at least from the release of Windows 95 (Win95) shell,
there have been many bugs found and fixed with the different variants of
the OS. One of the most troublesome, and in my opinion one of the most
trying, has been the Alt-Tab bug.
Now if you don't know what bug I'm
talking about, let me explain. I assume that you know about the Windows
functionality that allows a user to use the key combination of Alt-Tab
to switch between active applications running on the system. When this
functionality is triggered you generally see a small window appear in the
middle of your screen showing the application icons of all the applications
that are currently running, allowing you to select the application you
want to become active.
The Alt-Tab functionality
starts out working exactly as you would expect but when you've selected
your desired application and you release the Alt-Tab key combination
your chosen application becomes active but for some reason the application
you were in is still on top. It's no longer the active application but
it's still on top of the application that is active!
As far as I can tell, this bug first
appeared in the original release of Win95 or to be more specific the Win95
Shell. The Shell is the basic environment that allows Win95, and every
version of the operating system since then, to do its magic. The Shell
is also responsible for how the OS looks by controlling the painting of
controls and system objects within the environment. With the release of
the Win95 Shell, Microsoft created a whole new set of window styles and added other features
to make its OS look new and very fancy.
For those of you who aren't into
low-level API programming, a window style is how the OS decides how a window
should look and behave. There are two different types of window styles; the
original window styles and the extended window styles. The original window styles could be found in the all versions of the Windows
operating system before Win95. The extended window styles were first introduced with Win95 to
to the OS. You can tell that the API constant WS_EX_TOOLWINDOW is
an extended window style because of the "EX" in the name. This particular
window style, according to the Microsoft
API help file, was created to allow programmers to
"create a tool window,
which is a window intended to be used as a floating toolbar. A tool window
has a title bar that is shorter than a normal title bar, and the window
title is drawn using a smaller font. A tool window does not appear in the
task bar or in the window that appears when the user presses Alt-TAB."
As can be seen, Microsoft fully intended
this window style to bypass the standard Alt-Tab functionality.
As a result of this new window style we now have those lovely floating
toolbar windows that can be found in most Microsoft applications.
Except that if you look at the floating
toolbar windows found in most Microsoft applications they don't look exactly like
the toolbar windows that most development environments like Delphi, Visual Basic
or even Microsoft VC/C++ create. There is a very good reason for this: The window
that has the extended window style WS_EX_TOOLWINDOW
causes the dreaded Alt-Tab bug!
To see this behavior simply take your favorite
development language, mine is Borland's Delphi, and create a simple application
with two windows in it. Now each IDE will be different but in Delphi there
is a property for all windows called BorderStyle. If you set the BorderStyle
of the second window to be bsToolWindow or even bsSizeToolWin you can
demonstrate, with amazing results, the dreaded Alt-Tab bug. Execute
the application, making sure that both windows are visible at runtime.
Select the second window, also make sure that there is a second application
running in the background so that you can Alt-Tab to it, press the
You should now be able to do stuff
in your second application but the test program you just wrote should
still be on top, deactivated but on top! If you return to your test program
and make the main form of your application focused and then try the Alt-Tab
sequence again, you should find that your application should behave normally
and disappear to the background.
I can hear you now, "So just don't
use windows that have that extended window style." Well that would be the simple solution, wouldn't it? Unfortunately that pesky window style
gets used a lot, by things like hint windows. Which brings me to my second
Hint windows, those wonderful little
yellow boxes that provide us with so much, yet so little, information about
things. Most hint windows use that extended window style just for the
reasons mentioned in the Window API help manual. If the hint window class
you're using is constructed properly then it won't be a problem, but if it's
not then you can once again suffer from the Alt-Tab bug.
Even Microsoft themselves suffer from it,
although you won't be able to find it in many of their applications these
days. What you should be looking for are the hints that get displayed on
the Microsoft treeview common control. This class is defined in the ComCtl32.DLL
library and is found on every single computer running Win95 or
This bug is slightly harder to trigger
than the last one, but once you have it figured out it's very annoying. To make
this happen requires another application
with at least three windows. The main window in this application is irrelevant
but necessary. The main focus of this demonstration is the two child windows,
both of which must have a treeview control and one of them must also be
a stay-on-top window. Arrange the windows in any fashion you want, set the focus to the child window that is not
stay-on-top and leave the mouse pointer
over one of the child windows. Trigger the Alt-Tab and watch the
Depending on where the mouse pointer
is when the Alt-Tab is triggered you will notice different behaviors.
If it is over one of the treeviews on a child window then the entire application
will stay-on-top. If it is on a client or non-client area of a child window
then just that window will stay-on-top. If the mouse pointer is not in
one of the child windows then the bug never surfaces.
The treeview control and a window
with the ability to stay-on-top are the main triggers for this one. A colleague
of mine was finally able to trace this one back to a hint window that the
treeview creates. There is a property of treeviews that allows it to display
a hint if a treenodes label is off the right-hand side of the control. Moving the mouse over the node shows
the hint allowing the node's full caption to be displayed. If a treeview
is created with that property shut off then this bug never appears. If
that property is turned on after the control has been created then the
bug also never appears. But if the property is turned on before a
window handle has been assigned to the control then the bug returns.
There is a workaround for this treeview
bug that I've come up with. The fix itself is not hard but
it requires creating a new TTreeview descendant and manually implementing
the treeview's hint control. Once that is done the Alt-Tab
doesn't appear and the application works normally.
This Alt-Tab bug has appeared
in a number of commercial applications that use the WS_EX_TOOLWINDOW
window style and even in applications that don't specifically use it. I do have this control
built and working in a couple of applications. It is part of a component
set I've developed over the last couple of years. I plan on releasing the entire component set to the public domain, but I'm not
quite satisfied with a few of the controls yet. If you would like
a copy of the rmTreeview component, this is the fixed version of the treeview
component, contact me directly at email@example.com
and I'll send you a copy of the source.
Server Response from: ETNASC02