How to implement single-instance application in wWinMian and switch the target instance to foreground

[zy-ih]

I am using C++/WinRT to develop a single-instance application, the expected behavior is that each time a new instance is launched, it will redirect to the default instance and activate the window. However, the document suggests, "It’s best to check for the need to redirect activation as early as possible in your app’s execution. ". This is difficult to do, I can’t activate the target window and switch it to the foreground in the Activated event handler according to the implementation method in #1439, because the Activated callback and DispatcherQueue are in different threads.

I want to know if there is a better way to implement this behavior.

//App.xaml.cpp
#include "pch.h"
#include "App.xaml.h"
#include "MainWindow.xaml.h"
#include <ppltasks.h>
#include <pplawait.h>

//Current instance window handle used to bring window to foreground.
HWND currenthWnd{};
//The event remains set until explicitly reset.
wil::slim_event_manual_reset getCurrenthWndFinished;

inline HWND GetHWndFromWindow(mux::Window const& window)
{
    HWND hWnd{};
    auto windowNative{window.try_as<::IWindowNative>()};
    winrt::check_bool(windowNative);
    windowNative->get_WindowHandle(&hWnd);
    return hWnd;
}

namespace winrt::Demo::implementation
{
    //...

    /// <summary>
    /// Invoked when the application is launched.
    /// </summary>
    /// <param name="e">Details about the launch request and process.</param>
    void App::OnLaunched([[maybe_unused]] mux::LaunchActivatedEventArgs const& e)
    {
        window = make<MainWindow>();
        window.Activate();
        currenthWnd = GetHWndFromWindow(window);
        getCurrenthWndFinished.SetEvent();
    }
}

#ifdef DISABLE_XAML_GENERATED_MAIN
int __stdcall wWinMain(HINSTANCE, HINSTANCE, PWSTR, int)
{
    {
        void (WINAPI * pfnXamlCheckProcessRequirements)();
        auto module = ::LoadLibrary(L"Microsoft.ui.xaml.dll");
        if (module)
        {
            pfnXamlCheckProcessRequirements = reinterpret_cast<decltype(pfnXamlCheckProcessRequirements)>(GetProcAddress(module, "XamlCheckProcessRequirements"));
            if (pfnXamlCheckProcessRequirements)
            {
                (*pfnXamlCheckProcessRequirements)();
            }

            ::FreeLibrary(module);
        }
    }
    winrt::init_apartment(winrt::apartment_type::single_threaded);
    auto currentInstance = mwal::AppInstance::FindOrRegisterForKey(L"current");
    if (currentInstance.IsCurrent())
    {
        currentInstance.Activated([](const wf::IInspectable& sender, const mwal::AppActivationArguments& args){
                getCurrenthWndFinished.wait();
                SetForegroundWindow(currenthWnd);
            });
        ::winrt::Microsoft::UI::Xaml::Application::Start([](auto&&){
                ::winrt::make<::winrt::ListViewDemo::implementation::App>();
            });
    }
    else
    {
        auto args = mwal::AppInstance::GetCurrent().GetActivatedEventArgs();

        [&]() -> concurrency::task<void> {
            co_await currentInstance.RedirectActivationToAsync(args);
        }().get();
    }

    return 0;
}
#endif

[DarranRowe]

One thing to remember is that, as long as you have a reference to it, a DispatcherQueue is usable from another thread. This is documented in TryEnqueue. DispatcherQueue is also marked as agile, so it is usable across threads/apartments.
The big issue is when the main thread's dispatcher queue is created. If you try to obtain the DispatcherQueue early, it doesn't exist. The DispatcherQueue doesn't naturally exist on the main thread.

In the autos at the bottom of the VS window, you can see that Microsoft.UI.Dispatching.DispatcherQueue.GetForCurrentThread returns null. However, if you try to obtain it in the Start handler, the results are different.

As you can see from the autos at the bottom, GetForCurrentThread returns something, the {...} indicates that it is a valid object here. This means two things. First Application.Start creates the DispatcherQueue for the main thread. Secondly, if you want to grab a reference to the DispatcherQueue instance, the callback is the best time to do it.

The above shows obtaining a reference to the DispatcherQueue and storing it in a global variable. It does require that you check to see if the reference is valid, but you can use this instance to queue up work on the main thread's dispatcher queue. If anything, the worst you would have to do is get the existing process ID from the activated event args and then use AllowSetForegroundWindow to allow your single instance to bring itself to the front.

[zy-ih]

Thank you for reply. Indeed, it’s a convenient way to obtain the DispatcherQueue, although it may not fully address the challenges encountered when creating single-instance applications. After reviewing the information here , perhaps the goal is to provide a modern multi-window manager through WindowsAppSDK, adding more Win32 wrappers to AppWindow, and even allowing customization of taskbar icons associated with windows. Although this hope isn’t visible yet, I sincerely appreciate your valuable suggestion.🙌

[DarranRowe]

The big question then is, does SetForegroundWindow work. If it doesn't, then the issue is likely that your main application instance doesn't have the right to bring itself to the front.
As the documentation for SetForegroundWindow states, there are four conditions required for SetForegroundWindow to work, and at least one other condition that needs to be true.

1. The application is a desktop application. This will always be true for the cases where you use the Windows App SDK.
2. The foreground process has not disabled calls to SetForegroundWindow.
3. The foreground process hasn't received input for a long enough period of time. This period of time can be found using SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo.
4. No menus are active.

All of the above have to be true. Additionally, at least one of the following must be true.

1. The calling process is the foreground process.
2. The calling process was started by the foreground process.
3. There is currently no foreground process.
4. The calling process received the last input event.
5. The foreground process or the calling process is being debugged.

It is easy for this situation to run afoul of one of the 5 additional requirements. In particular, the main application instance isn't the foreground process and it wasn't started by the second instance. This is why I mentioned using AllowSetForegroundWindow to explicitly give your main instance the right to bring itself to the front. By using the Windows API explicitly here, you can figure out where the problem is.