2

After a couple hours of Googling I haven't been able to find any comments on this issue. We have a WindowStyle=None window with transparent background and allows transparency and does not show in taskbar, all pretty normal. Here's the XAML so you can test for yourself:

<Window x:Class="AltTabTest.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Name="TestWindow" Title="TestWindow"
WindowStyle="None" AllowsTransparency="True" ResizeMode="NoResize" 
Background="Transparent" ShowInTaskbar="False"
Width="816" Height="820">

<Grid>
    <Border BorderThickness="0" Background="LightBlue" CornerRadius="15" />
</Grid>

Now what's bizarre is once you compile and run this window, follow these steps:

  1. Click on Show Desktop to hide all apps
  2. Alt+Tab back to the WPF Test App
  3. Click outside of the Light Blue border area (to the desktop workspace)
  4. Observe WPF Test App magically disappear
  5. Optionally Alt+Tab to any other running app and observe WPF Test App magically re-appear

So my question is: what the heck is going on here?! Is this expected behavior? If so, is there any way around it?

It feels like the WPF app is not truly getting focus after the Alt+Tab is resolved. Please note this is being tested in Windows 7 and I have not had the capability to test this in Vista or XP. I'd like a way to force the app to truly get focus, but if that's not possible then I'm wondering if there's a way to trap and ignore Alt+Tab actions. The app this is intended to fix is a lockdown mode app so users should never be able to truly get away from it running on the desktop. Any advice, examples, insight or point in the right direction would be appreciated, thanks! =)

tpartee
  • 548
  • 7
  • 20
  • I'm seeing the same thing, but I do notice that the window catches ALT-F4 after Alt-Tabbing to it in step 2, so it does seem to get focus. No leads yet on how to correct the behavior, though. – Ben Collier Dec 18 '09 at 20:02
  • I ran it on Vista/32 and the Window does _not_ disappear. – H H Dec 18 '09 at 20:03
  • I also noticed that if you Alt+Tab to any different window during step 2 instead of the WPF app, the WPF app will show up alongside whichever window you chose, unexpectedly. – Ben Collier Dec 18 '09 at 20:03
  • Some more feedback without a solution: The window also doesn't minimize when you send the WND+M shortcut to minimize all windows, or when you use 'Aero-shake' to minimize all but the top window. The problems also don't go away when switching to a 'basic' theme instead of an 'aero'-based theme. – Ben Collier Dec 18 '09 at 20:06
  • Ben, I can confirm the "Tab to other Win" and Win+M observations on Vista. No shaking to test. – H H Dec 18 '09 at 20:15

1 Answers1

1

According to Spy++ the problem is that the window when set with WindowStyle="None" is not receiving a WM_ACTIVATE message anymore when you alt-tab to it. Having AllowsTransparency="True" is disabling hit testing for the window, so when you click beyond the blue rectangle the only HitTest returning true is that of the desktop.

Because WM_ACTIVATE was never fired, the MinimizeAllWindowsToDesktop thingey doesn't recognize any active windows and so when it receives the notification that you clicked on the desktop the desktop is rendering just as it would had no windows activated and you were doing some work on the desktop (the expected behavior for this function).

I don't know why in Win7 the window is not receiving the WM_ACTIVATE message though.

EDIT: Nevermind, this looks like it's just a bug in WPF and Windows 7. This behavior persists no matter what the settings of the window.

Jim Wallace
  • 1,006
  • 8
  • 21