#Is it possible to use blocking `FileDialogBuilder` in a `on_menu_event` handler?

6 messages · Page 1 of 1 (latest)

lucid coral
#

When I call tauri::api::dialog::blocking::FileDialogBuilder::new().pick_folder() in a menu handler, it blocks the main thread, but doesn't show the dialog itself.

I was assuming the behaviour would be something like: show OS file picker, block everything else until a folder is picked, once it's picked, return and continue the rest.

Am I misunderstanding something? Any help would be appreciated.

celest crag
lucid coral
#

Ah OK, I see. Thank you, that makes sense. If I need the behaviour I mention, where until the folder is picked, the function doesn't return, would I need to make an async fn? I have not ever touched that side of Rust and am worried it's a whole can of worms.

#

Maybe to explain in more detail: I have a command that I want to be fallible, and needs to be checked on the Frontend to have succeeded (i.e. with try {await invoke(...)} catch (e) { console.log("oh no") }), so the signature is something like

use tauri::api::dialog::blocking::FileDialogBuilder as Dialog;
#[tauri::command]
pub fn open_folder_and_do_something() -> Result<(), String> {
    let path = Dialog::new().pick_folder().ok_or("no folder picked")?;
    some_other_result_fn(&path)?; // if this isn't Ok, the frontend has to know
    Ok(())
}

I want to be able to call the same command from a menu handler. I don't know what's the recommended / standard approach for something like this. I assume it's a frequently encountered need.

Since the command is fallible, I cannot easily use the non-blocking picker, as there's no way to find out if some_other_result_fn is Ok, as it would only be called and returned from in the pick_folder(|path| {some_other_result_fn(path)}) closure.

celest crag
#

So basically 2 options here, both are conceptually the same:

  1. use std::thread::spawn in on_menu_event and call the command in there
  2. make the command async (no changes for the js invokation) and use tauri::async_runtime::spawn to call the command

the async task is a bit lighter but i don't think it really matters.

lucid coral
#

OK thank you for the advice! Will attempt the async command approach.