mixed-mode WPF app does not become foreground app RRS feed

  • Question

  • Hey,

    About 5 months into a major conversion of an MFC app to WPF, we've noticed an oddity:  When we launch our app, it does not become the foreground app in Windows.  For example, if you double-click the EXE file in Windows Explorer, the app comes up *behind* the Explorer window.  Even in scenarios where it comes up on top, it does not have keyboard focus.

    The startup for this app could probably be considered odd.  The app actually launches as an MFC app, via AfxWinMain().  So we have an MFC CWinApp-derived class, and AfxWinMain() calls its InitInstance() function followed by its Run() function.  During CWinApp::InitInstance(), we new up (or rather gcnew up) our WPF Application-derived class, and then CWinApp::Run() calls Run() on the WPF Application instance.  The implementation of Run() on our WPF Application-derived class creates our quasi-main WPF window and then calls the base class Run() function.

    Any thoughts on what we can do in an app like this to convince Windows to make this application the foreground application?  Or what we might be doing that could be getting in the way of that?



    Thursday, June 25, 2009 1:47 AM


  • I have found the source of our activation problem.  Fortunately, it was not related to our MFC-based initialization.  Our application has its own Ctrl+Tab Window Switcher (similar to Visual Studio), and, during initialization, the Window Switcher was getting created.  But, in order to hide the Window Switcher window from the operating system's Alt+Tab switcher, we had to set the WS_EX_NOACTIVATE style on the window.  Even though this window was not the first window created and was a hidden window, its existing was preventing WPF (or whoever) from activating our application.

    The workaround is to wait for Application.OnActivated, at which point we know we're in good shape, and *then* create the window switcher window.

    Friday, June 26, 2009 6:41 PM