Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way of differentiating source of OPEN_FILE and SAVE_FILE commands #1455

Closed
meettitan opened this issue Dec 12, 2020 · 3 comments
Closed
Labels
question causes uncertainty

Comments

@meettitan
Copy link

I have an application that needs to open some data from the user. Currently I am using AppDelegate to listen for druid::commands::OPEN_FILE after using druid::commands::SHOW_OPEN_PANEL.This works great! However, I need to open multiple different data sources that I'd like to store differently in my application state, and there is no way of differentiating which button was pressed once AppDelegate is handling OPEN_FILE.

If druid::commands::OPEN_FILE is fired from a new window, the command's target corresponds with the new window, and I can differentiate the window's source; but I'd like to avoid having every file dialog need to open a new window. This also makes multiple open dialogs from menus impossible.

I would imagine the same problems are present when trying to show two discrete save dialogs in the same window.

@richard-uk1
Copy link
Collaborator

I'm not sure of the "correct" solution, but a workaround would be to have some flag in your application data that you set when SHOW_OPEN_PANEL gets called, that you read when OPEN_FILE gets called.

@richard-uk1 richard-uk1 added the question causes uncertainty label Dec 13, 2020
@cmyr
Copy link
Member

cmyr commented Dec 13, 2020

Yes, this is an oversight. The way I would prefer to solve this is by returning some token when the dialog is requested, and then passing that token back along with the FileInfo struct when that returns.

@jneem
Copy link
Collaborator

jneem commented Mar 19, 2021

Just noticed that this is still open, but I think it's solved by #1463.

@jneem jneem closed this as completed Mar 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question causes uncertainty
Projects
None yet
Development

No branches or pull requests

4 participants