PickSingleFileAsync await call hangs app

[MRahilly]

Does a xaml app require additional API calls before showing a file picker that are not required by the C++/WinRT equivalent?

[package]
name = "xaml_code"
version = "0.0.0"
edition = "2018"

[dependencies]
futures = "0.3"

[dependencies.windows]
version = "0.35.0"
features = [
    "implement",
    "ApplicationModel_Activation",
    "Win32_System_Com",
    "UI_Xaml_Controls",
    "UI_Xaml",
    "UI_Xaml_Media",
    "UI",
    "Storage_Pickers",
    "Foundation_Collections",
    "Storage",
    "Foundation",
    "Storage_Streams",
    "Graphics_Imaging",
    "Media_Ocr",
    "ApplicationModel_Core",
    "UI_Core",
]

#![windows_subsystem = "windows"]
#![allow(non_snake_case)]

use windows::{
    core::{
        Result,
        HSTRING,
        implement,
    },
    ApplicationModel::Activation::LaunchActivatedEventArgs,
    Win32::System::Com::{
        CoInitializeEx,
        COINIT_MULTITHREADED,
    },
    UI::{
        Colors,
        Xaml::{
            Controls::{
                TextBlock,
            },
            Application,
            ApplicationInitializationCallback,
            Window,
            Media::{
                FontFamily,
                SolidColorBrush,
            },
            TextAlignment,
            TextWrapping,
            VerticalAlignment,
            FrameworkElement,
            IApplicationOverrides,
            IApplicationOverrides_Impl,
        },
    },
    Storage::{
        StorageFile,
        Pickers::{
            FileOpenPicker,
            PickerLocationId,
        },
    },
};

#[implement(IApplicationOverrides)]
struct App();

impl IApplicationOverrides_Impl for App {
    fn OnLaunched(&self, _: &Option<LaunchActivatedEventArgs>) -> Result<()> {
        let block = TextBlock::new()?;

        block.SetFontFamily(FontFamily::CreateInstanceWithName(HSTRING::from("Segoe UI Semibold"))?)?;
        block.SetFontSize(72.0)?;
        block.SetForeground(SolidColorBrush::CreateInstanceWithColor(Colors::Orange()?)?)?;
    
        FrameworkElement::from(&block).SetVerticalAlignment(VerticalAlignment::Center)?;
        block.SetTextAlignment(TextAlignment::Center)?;
        block.SetTextWrapping(TextWrapping::Wrap)?;
        
        let window = Window::Current()?;
        window.SetContent(&block)?;
        window.Activate()?;

        block.SetText(HSTRING::from("Thursday earlier..."))?;

        futures::executor::block_on(main_async(&block))
    }
}

async fn main_async(block: &TextBlock) -> Result<()> {
    block.SetText(HSTRING::from("Thursday later..."))?;

    let picker = FileOpenPicker::new()?;
    picker.FileTypeFilter()?.Append(HSTRING::from(".png"))?;
    picker.SetSuggestedStartLocation(PickerLocationId::PicturesLibrary)?;
    
    //let result: Result<StorageFile> = picker.PickSingleFileAsync()?.await; // picker does not appear, app hangs
    //let file: StorageFile = picker.PickSingleFileAsync()?.await?;          // picker does not appear, app hangs

    Ok(())
}

fn main() -> Result<()> {
    unsafe {
        CoInitializeEx(std::ptr::null(), COINIT_MULTITHREADED)?;
    }
    Application::Start(ApplicationInitializationCallback::new(|_| {
        Application::compose(App())?;

        Ok(())
    }))
}

[kennykerr]

futures::executor::block_on blocks the calling thread, the UI thread in this case, which is likely why the app hangs.

[MRahilly]

So a thread::spawn() maybe using an Arc<Mutex<>> could be the way to go here?

[kennykerr]

The problem is in the difference between C++/WinRT coroutines and Rust async functions. WinRT async assumes hot-start whereas async functions are cold-start, meaning the Rust async function needs a driver whereas WinRT async is meant to be self-driving. This is something I'm still noodling on, but that's the gist of the problem.

[kennykerr]

And no, using another thread won't help because then the UI calls will originate from a non-UI thread and that is not typically supported.

[MRahilly]

Thanks for the explanation.
We await resume_background_ferris() and resume_foreground_ferris()

[aWeinzierl]

And no, using another thread won't help because then the UI calls will originate from a non-UI thread and that is not typically supported.

What about using RunAsync?

Schedules the provided callback on the UI thread from a worker thread, and returns the results asynchronously.

[kennykerr]

Yes, that's what C++/WinRT uses behind the scenes for resume_foreground - that may work.

[MRahilly]

The closures for RunAsync lead to 'static lifetime requirements on the xaml app Window - leading to cumbersome code.

[kennykerr]

Yes, there are already issues tracking improvements to delegates (including from you). #1110 #332 #313 #1465