Home/ Questions/Q 9108009
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T02:42:25+00:00

I have to port some legacy code, that uses modal dialog boxes all over

  • 0

I have to port some legacy code, that uses modal dialog boxes all over the place to Metro/WinRT (using C++/CX). Because these dialog boxes provide their own message loop (using DialogBoxParam()), the calling code will wait until the user has clicked a button on the message box.

I’m currently trying to write a replacement for the old message box class, that uses XAML and the popup control. To reproduce the same behavior, I have to wait in the calling thread, but also have to keep the UI responsive. I’ve found out, that CoreDispatcher::ProcessEvents() can be used in a loop, to keep processing events (yeah I realize that this isn’t very beautiful, but I don’t want to change all of our legacy code to a new threading model). However I’m running into an issue that keeps crashing my app.

Here is a minimal example that reproduces the issue (just create a XAML app and wire this to a button):

void CPPXamlTest::MainPage::Button_Click_1(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
    bool cancel = false;

    auto popup = ref new Popup();
    auto button = ref new Button();
    button->Content = "Boom";
    auto token = (button->Click += ref new RoutedEventHandler([&cancel] (Object ^, RoutedEventArgs ^) { cancel = true; }));
    popup->Child = button;
    popup->IsOpen = true;

    while (!cancel)
    {
        Window::Current->Dispatcher->ProcessEvents(CoreProcessEventsOption::ProcessOneAndAllPending);
    }

    popup->IsOpen = false;
    button->Click -= token;
}

This seems to work well for the first one or two tries of opening and closing the popup, using the two buttons. After a few tries however, the application will instantly crash deep in Windows.UI.Xaml.dll, while trying to dereference a null pointer. I can also reproduce this in C# (with practically the same code).

Does anyone have an idea, what is going on in here? Or a suggestion for an alternative approach?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If anyone is interested: I asked the same question a few days later on the MSDN forums and got a response there from a Microsoft employee:

    http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/11fa65e7-90b7-41f5-9884-80064ec6e2d8/

    Apparently the problem here is the nested message loop that is caused by calling ProcessEvents inside an event handler. It seems that this is not supported by WinRT, but instead of failing in a well-defined manner, this will or may cause a crash.

    Alas this was the best and only answer I could find, so I ended up working around the problem, by dispatching the event handler (and a lot of other code) into another thread. I could then emulate the waiting behavior of DialogBox()/DialogBoxParam() (outside the main thread), by waiting on an event that was signaled when the user clicked/tapped a button on my XAML “dialog” popup.

    • 0