Event doesn't work from a Modal Window

Hello boys and girls of the community!
I have noticed that some functions from a modal window using batchPlay do not work, this for me is a bad sign, because these dialog windows are part of my work tools in the CEP extension and how will I be able to migrate if this is a limitation of the same in UXP?? Is there any solution for this? Grateful


js

document.querySelector("#ArrangeM").addEventListener("click", async evt => {
		const core = require("photoshop").core;
		await core.executeAsModal( async() => { 
		await app.batchPlay([{"_obj":"duplicate","_target":[{"_enum":"ordinal","_ref":"document","_value":"first"}],"documentID":103,"name":"Montagem13 "}], { });
		await app.batchPlay([{"_obj":"select","_target":[{"_enum":"menuItemType","_ref":"menuItemClass","_value":"2upVertical"}]}], { });
		}
	)
})


When executed via modal, the file duplicates correctly, but we don’t see both on the screen.

Hey guys! In UXP panels are there any limitations on performing some functions from modal windows?
Could someone please take a look at my video above and if possible point me to a solution to my problem. Thank you.

Not sure, but doesn’t “modal” mean that Photoshop is essentially locked in the “modal state” such that many functions it normally performs are NOT accessible. So, if you open a “modal” dialog, you’re essentially lock Ps into the modal state that will prevent many function from executing properly. I’m actually a little surprised to see the extra image for 2-UP was even generated in the background in your video since the Window > Arrange menu item is grayed-out when a modal dialog window is open. So, maybe one way to see what you can do from within a modal dialog is to check and see which menu commands still work. If it’s grayed out in the menus you probably won’t be able to fully access it from within a modal dialog window.

1 Like

Hi @AnthonyK thanks for answering, friend this is a bad sign for me, they say that CEP extensions in the future will no longer exist and that they will give way to UXP plugins. I’ve been working with Photoshop for over 10 years, I’m in the 3d modeling, graphics and sublimation area, I’m not a programmer, I have very basic knowledge of extendScript, htm and css, but enough to create my CEP extensions for personal use, which concentrates and automates almost 100% of my daily workflow and scriptUI dialogs are heavily used and work perfectly with CEP extensions.
If UXP plugins will give rise to CEP extensions, because it does not provide all the basic resources such as making the same functions work in Modal state as in CEP extensions that perfectly support jsx.
Here are two old videos showing that my main tools are used from modal windows.

I think that you’re talking about two different things in this thread.

Modal window
A pop-up window - called a Dialog in UXP.

Modal state
Used in PS to block other processes from interrupting your code execution. See executeAsModal()

1 Like

I’ve just tested this and can confirm that invoking the 2-up view via batchPlay doesn’t appear to work.
When invoked from within a modal state it returns a Photoshop alert with the message “The command is not currently available” and when invoked outside of modal state it throws this error in console:

Error: Event: invokeCommand may modify the state of Photoshop. Such events are only allowed from inside a modal scope. See https://www.adobe.com/go/ps_executeasmodal for details.

This is regardless of whether the button that triggers the event is within a dialog or not.

You might have a point @Timothy_Bennett, but an open UXP modal dialog window appears to disable many functions in Photoshop the same way executeAsModal() does. So the term “modal” seems to apply in both cases in that the “modal” dialog window is “blocking other Ps processes” until you close the window. It’s not just “2-Up” that fails when a modal dialog window is open.

This is one of the reasons I don’t use modal dialog windows to actually make changes to the image. I just use the window for user input and then take that input and use it elsewhere once the window is closed.

If I want to do things to the image with a different interface, I open that interface on the UXP panel itself instead of in a modal dialog window.

1 Like

Yes, @AnthonyK that’s my approach too - I think that if a dialog has that much functionality then it should be a panel in it’s own right

Hi @Timothy_Bennett , I think you must have seen the video at the beginning of the post, I just need to make such functions work correctly from the modal window, maybe I didn’t really express myself correctly. Please tell me that this is possible and if the answer is, yes, what am i doing wrong?
I’ve prepared this simplified plugin template so someone can point me in the right direction.
Thanks.

@PS-fxrios what I’m saying is that I didn’t find that I could invoke 2-up vertical at all

1 Like

I’m going to have another poke around with this tomorrow but I’m currently feeling like it might be a bug.

1 Like

Hi @Timothy_Bennett and @AnthonyK , I did a search on the internet and right here in this same community I found this discussion: Show dialog without having a panel - #4 by Karmalakas
And maybe this could be a solution to the limitations of modal windows in UXP:
What @AnthonyK mentioned about blocking some processes when the modal window is open makes perfect sense.
I replace uxpShowModal() with show(); and to my biggest surprise and it worked perfectly!
Here the end result:

4 Likes