Hello, all!
I’m working on a UXP plugin for Photoshop, not using React. I need to provide the user a means to select a folder from which the plugin will subsequently retrieve various preferences that will affect subsequent processing. It seems that the best practice (perhaps the only workable one?) is to use fs.getFolder().
My problem is that the picker dialog opened by fs.getFolder() does not execute as a modal dialog, thus allowing the user to continue interacting with the UI while the dialog is open. Not good! Ifd I were implementing my own dialog, this would be simple matter of using uxpShowModal().
I must be missing something really obvious, as I see lots of instances in other UXP plugins that I use where the implementation behaves exactly as I would wish.
The following snippet illustrates the issue:
document.getElementById("buttonOne").addEventListener("click", async () => {
buttonOneClicked();
});
document.getElementById("buttonTwo").addEventListener("click", async () => {
buttonTwoClicked();
});
async function buttonOneClicked() {
console.log("Button One clicked");
const selectedFolder = await fs.getFolder();
console.log("Button One selected folder: " + selectedFolder);
}
async function buttonTwoClicked() {
console.log("Button Two clicked");
const selectedFolder = await fs.getFolder();
console.log("Button Two selected folder: " + selectedFolder);
}
The user clicks Button One, the getFolder() picker dialog opens, then the user clicks Button Two, and yet another picker dialog opens. The console shows the two “Button XXX clicked” messages. Both dialogs are open.
Thanks
Update:
If I wrap one of the two calls to fs.getFolder() in a call to executeAsModal:
async function buttonTwoClicked() {
console.log("Button Two clicked");
const selectedFolder = await core.executeAsModal(getFolderAsModal,
{ "commandName": "Get Folder As Modal" }
);
console.log("Button Two selected folder: " + selectedFolder);
}
async function getFolderAsModal(executionContext, descriptor) {
const selectedFolder = await fs.getFolder();
return selectedFolder;
}
then this is what happens:
- the user clicks on Button Two
- the console shows “Button Two clicked”
- the folder picker dialog opens
- the user can and does click on Button One
- there is no apparent consequence to the user clicking on Button One. However:
- the user picks a folder
- the folder picker dialog closes and the console shows “Button Two selected folder ….”
- the console shows “Button One clicked” and another picker dialog opens
This, again, is not as desired, and not the behavior that I see implemented in other plugins. In other plugins, the system “beeps” if the user attempts to interact with the UI while the picker dialog is open, and to all appearances the user attempt is disregarded.
I call fs.getFolder() from a button in a modal dialog on OSX, and I am prevented from interacting with my dialog while the file picker is showing. And click outside of the dialog results in a beep.
Thank you. Yes, that’s the workaround I’ve implemented, but it’s clunky:
- User clicks my “call-to-action” button on the plugin panel
- Plugin displays a modal dialog with “Continue” and “Cancel” buttons. The only value this dialog actually provides is to establish the modal state. I make it look a bit useful by placing some instructional text on it, but …
- User clicks the “Continue” button
- The click event listener calls fs.getFolder() and saves the result value:
- A second click event listener (on the “Continue” button) closes the “outer” modal dialog (the one with the “Continue” and “Cancel” buttons). This is the part that I find clunky, but without this step the user would have to intervene directly to dispose of the “outer” modal dialog.
Somehow I suspect I’m going about this all wrong, but I can’t seem to find any guidance that would set me straight …
That’s strange, I just tested it from a panel instead of a modal dialog, and and it is mostly modal. I am not able to interact with my panel while the file picker is showing, but I can interact with some native menu items which come up right after the dialog closes. OSX 14.4.1 / PS: 27.1.0
Yes, it is strange, indeed! Thank you for your continued interest … at this point I fear I need to move on, and maark this matter as a “TODO”.