Yes i did, i (we) are using different names in the pre-release group and the forum. Happened somehow while one of us was logged in with the account from the other guy 
But thanks for the reminder. I will mark the other thread as resolved.
I have maybe a related question 
Currently I don’t see such feature in the docs, but… Is it possible to cancel modal execution? If so, how? I see user can cancel it, but can we do it programmatically? I was thinking of the flow something like:
- User starts dragging the slider
- Plugin
onInputinitiatesexecModal()somehow marking that it’s initiated - Slider is still being dragged while execution didn’t finish
- If execution still not cancelled, cancel it and run new
execModal()
This way there would be only a single modal scope
1 Like
This worries me considerably
We are into the second year of UXP which promised to make it easier to create plugins yet it appears we take one step forward and then 2 steps backwards.
If the Input event worked on a version prior to 23.2 then why would moving forward to 23.2.2 break it. Surely there are people testing the new release to make sure it hasn’t broken anything in the previous release.
Back in the days before UXP I used to look forward to the new PS updates but now, if I am honest my heart drops when I see the New Update notification in the menu.
1 Like
It wouldn’t be so painful if we had what we were asking for for a while now - a proper changelog for devs. Currently I saw only one more or less decent changelog - in a pre-release program, but that one is targeted to users, and not devs. Devs now don’t have even normal documentation tied to releases. Yes it’s much better than it was a year ago, but still a mess. Digging through GitHub history or searching for open pull requests is not what I would expect as a documentation from such a company. I would love to have proper changelogs and docs for UDT, UXP, Manifest and Ps itself (all including upcoming version releases), but apparently it’s going to be a few more years until we get those
2 Likes
Same here. I’m a bit worried UXP is a unreliable platform for earning a living. My CEP panels always worked flawlessly and still earn part of my daily outcome.
Too bad the PS team decided so early to add the “legacy” designation to the menu. That really causes problems with sales. Especially because PS team decided to not port CEP to Apple Silicon. I mean all the other apps still support CEP natively.
Then there is the problem with UXP API version. I was nearly done developing my first UXP plugin and i was short before release and then the console said my plugin is deprecated … Again! So again i ported to V2, and now after release all my UXP plugins are broken because of the input event.
Ok, so you could say why i didn’t develop on the prerelease version and then we could have discovered the problem before 23.3 was released. And that is true. But i’m still working as a photographer and
- i don’t want alpha versions in my workflow
- i just don’t have the time to care about all that. Selling Adobe plugins means i have to care for social media, a website, customer support, programming (while this in case of UXP means 80% of programming is finding workarounds)…
It’s just impossible to read all the stuff on GitHub, Medium.com, here, the prerelease group, the (meh) docs… It just gets too demanding for just a few plugins. Too much work, that in the end doesn’t pay off enough. Economically a really difficult task for me.
I appreciate new features in the API of course and i believe Adobe wants only the best for us. But i think the base concept is wrong. At last we are beta testers. That is not fair. I’m literally paying for testing UXP API development.
Therefore:
IMHO it’s still too early to release UXP to public development at all. We would still be fine on CEP.
It would have been way better for devs and customers to have a definitive ready version of UXP right from the start. And it should have been on par with CEP. And then a definitive date for CEP obsolescence should have been anounced. And of course we should have had CEP on M1.
How things went is in my opinion bad business practice. If i would treat my customers like so…oh well…
Although i know of course the teams only had best intentions.
1 Like
While I understand most of your points, I also think that it brings a lot of benefits making a technology available to developers that early: We can give immediate feedback and somewhat help to shape the future of UXP. There’s only so much you can test internally and if you just build out the technology for X years until it’s (seemingly) ready to then give developers access, it might not match with their expectations as well.
So yes, we are beta testers in a way, but it’s not like we were immediately forced to adapt the new technology. You could still be developing CEP extensions (at least for users without M1-chip devices, which is a big drawback), but for me personally UXP has made a lot of things easier as well. I agree that deprecation of CEP could have been handled more clever, for example keeping both types of plugins/extensions under the same menu so that users don’t even see any difference.
1 Like
Well, usually i would say you’re right.
But for example i’m offering beta versions for my plugins as well. And although it’s nice to have some feedback, it’s always the problem that it slows down development a lot, while i’m still the one who has to make the decisions after all.
And i think it’s the same here. It’s alot of noise about things that won’t happen.
We had that with CEP before. After 7 years the docs were still not ready. And i think it will be the same with UXP. In fact UXP is already four years old and has probably already reached more than half of it’s life span. And i said it before: what would we do without Alchemist? If Jaroslav didn’t give us this great great plugin… Where would UXP stand now? What were Adobe’s plans?
Kerri said Adobe is not a monolith. What makes this all a bit more sympathetic. But on the other hand i want a rock solid partner for earning my bread and butter everyday. I wish that at some point Adobe is getting the bigger picture.
My 2 cents on CEP and UXP from personal experience
A few years back I tried to create a simple CEP panel, but it was so time and effort demanding for a new comer, that I simply ended up with a few JSX scripts. When UXP was announced, I created my first quite simple plugin (without a panel - just some commands) in a few days. Couple of months later I created my second plugin. Then after a while I developed my first ever React project which took some time and I really doubt I would’ve taken the task on CEP (not just because a very similar plugin already existed)
So what I want to say, without UXP I probably wouldn’t have developed any plugins at all. UXP made it so much easier to get up and running from the very beginning even with so many issues UDT and UXP itself had. I even learned how to use basic batchPlay descriptors (JSON is so much easier to read and write than - what’s it called? - action manager methods?)
So I personally can’t complain UXP became available in its infancy stage barely allowing to do anything without batchPlay. Also all 3 plugins I developed were mostly intended for my own use, but as Adobe offers a way to sell them, why not take the opportunity? 
2 Likes
Well, their plans are to have a DOM with 100% parity, which will be easy to use and understand and not lack any functionality - this takes a lot of time though, as we see. So I can kind of understand that they didn’t really focus too much on making batchPlay more accessible. Compared to how we dealt with ActionManager in CEP, the new JSON syntax is already a huge win and convenience factor - Alchemist is just the icing on the cake IMO.
You could read out all the descriptor info with a simple listener (and in fact, that’s how we worked with AM before, didn’t we?), but having a well-built UI all about reading and understanding Descriptors makes it a lot easier of course.
Don’t want to get lost in details here.
@Karmalakas you were a highly qualified PS JSX scripter already (PS scripting forum) when i just started learning JS. And i found my way through CEP quite easily. Not saying i’m smarter than you, because i’m not. But it seems you missed an entry point at CEP extension coding. And finding it was not that easy because of the docs. Same for me when i migrated from CEP to UXP. I just didn’t know where to start. There is simply no lead article about how things work together. A simple explanation without geeky code stuff. That would be something.
@simonhenke yes of course we would listen to generator code and we would use the DOM functions we have. I’m just saying: subtract Alchemist, Sorcerer etc… and see what we’ve got after four years. That is not much and far away from CEP (node.js…).
I’m not blaming any of the UXP team here. How could i? My impression just is that UXP devs don’t have enough resources and are permanently drawn from one project to another, building five houses at the same time.
I said it before: look at LR. LUA for years, stable and backwards compatible to pre-CC LR. While on PS i have to explain my customers why their money is lost or why they have to pay for the upgrade to UXP etc, while i have double and three times the work.
Integrating react or Vue in CEP was no problem either BTW.
This had nothing to do with the input event itself, but rather how Photoshop is throwing errors when code called as a result of the input event tries to make changes to the document, because mousedown apparently puts Ps into a modal state.
And yes, there are lots of tests that get run for every release. This particular issue would have been difficult to catch even then, because it requires “real” events, not automated ones. But regardless of the reasons here, the combination of features that developers can use results in a much larger “use case space” than we could ever hope to cover fully. This is why it’s a really good idea to test your plugins in the beta version. Only you know exactly how you’re using your plugin w/ the Ps APIs. If something’s broken in the beta, that might give us a short to fix it before release, or at least have a shorter workaround period.
I’m glad your CEP panels have always worked flawlessly for you and your users. They have not for many other developers, and the same frustration you’ve experienced with UXP and the Photoshop DOM APIs (remember, it’s not all “UXP” – but a combination of modules interacting together) is the same frustration that many other developers have had with CEP. Pretty much every recent major CEP update has caused some major issue that we didn’t discover until a user found it (usually an Enterprise customer… you can imagine the finances involved there…). That you’ve not been affected has been a stroke of good luck, but a lot of other users have not been so lucky. (And I say this not to excuse the break. Just pointing out that CEP does not have a perfect record here.)
Speaking with my own voice here: I agree. But we’re in the universe where that didn’t happen, and have to make do.
UXP has only been available for third-parties to use in Photoshop for TWO years. XD has had it for longer, but XD has an entirely different tech stack, and integrating UXP into XD is very different than integrating with Ps.
Ps’s technology stack is much older, and has a lot of things built on top of older things built on top of older things yet. UXP is also way more tightly integrated into this stack than CEP ever was… which brings a lot of benefits, but also potentially more painful breaks.
Jarda’s plugin has indeed been a lifesaver. There are ways to get at this information in Ps, but none of them are nearly as slick as Alchemist. We owe a large debt of gratitude for his work in supporting the UXP Ps extensibility community.
I know things have been frustrating in UXP & PS API land for awhile. We’re frustrated too. There’s no ‘malice’ here – and there are things internally in motion that I hope will improve these issues going forward. I can’t speak to the details or timing yet because the finer points are still being worked out. But I’m hopeful you’ll be able to see improvements over the next few quarters, and appreciate your patience as we get there.
Last but not least: when it comes to your customers having issues w/ a Ps upgrade that breaks your plugins: you may want to let them know that they can always downgrade their Ps version (or opt out of auto updates). It’s a bit hidden in CCD, but if you click on the ••• menu, the user can choose to install a previous version of Ps. I do not mention this to excuse breaking things, but knowing that we’re all human and no matter how much we improve the odds are 100% that something will break again. Helping your customers know how to backtrack in case of a problem that breaks their critical workflows is useful information, and hopefully will reduce things such as refunds. It won’t address every issue (the upgrade may also be critical for the user), but it might help.
2 Likes
Thanks for responding @kerrishotts. I have to hold my hand up and admit that I rarely test my plugins with the beta version thinking it was mainly for upcoming features.
Moving forward, I shall reinstall it and do some testing
I usually do 50/50 - sometimes develop on beta, test on stable, and sometimes vice versa 
But this way I cover most of use cases on both versions. Otherwise, if always develop on one, might miss some cases on the other
Hi, Wondering if this issue has been fixed?
I can’t seem to get it working (but I’m not a dev, I’m just an artist experimenting with making some simple, fun, and free tools).
Here’s the code… It will only update on mouse release. No matter if I use “change”, “input”, or “mousemove”.
Ps beta 23.5
manifest 5
// LIVE SLIDER
const rotInput = document.getElementById(“rotInput”);
const rot = Number(rotInput.value);
console.log(“SLIDER:”+ rot);
//on Slider update
rotInput.addEventListener(“change”, async function () {
// Get current value
const rot = Number(rotInput.value);
// Start batchplay
await exeModal(async function () {
await batchPlay(
[
// MOVE X & Y
{
_obj: “transform”,
_target: [
{
_ref: “layer”,
_enum: “ordinal”,
_value: “targetEnum”
}
],
freeTransformCenterState: {
_enum: “quadCenterState”,
_value: “QCSAverage”
},
offset: {
_obj: “offset”,
horizontal: {
_unit: “pixelsUnit”,
_value: 0
},
vertical: {
_unit: “pixelsUnit”,
_value: 0
}
},
angle: {
_unit: “angleUnit”,
_value: rot
},
linked: true,
interfaceIconFrameDimmed: {
_enum: “interpolationType”,
_value: “bicubic”
},
_options: {
dialogOptions: “dontDisplay”
}
}
],
{}
); //end batchplay
}); //end modal
}); // END live slider
// Reset Slider
document
.getElementById(“rotInput”)
.addEventListener(“mouseup”, async function () {
rotInput.setAttribute(“value”, 0);
console.log(“X SLIDER:”+ rot);
}); // END
Bit tough to read, could you format it using the 
tool of the editor?
Was this ever actually resolved?
Hi @Michel77. The next minor Photoshop update 23.4 will have a fix that should resolve this issue. If it still persists, try guarding to ensure that only one execute modal scope is pending at any moment in time - and report back with any improvements or findings then.
Thanks everyone above for chiming in and offering insights / workarounds. Yes, this problem should have begun in 23.3.
I also want to bring up this topic again as I want to develop a “live slider”. I just tested it with sp-slider and the input event for changing the opacity of a layer. The opacity update will still only happen after the mouse button is released. So I’m wondering what the fix looks like?
This question seems to be discussed more specifically / precisely in UXP Slider change on move, so let’s move this over there (I think it’s already answered there, but if not, let’s handle follow-up questions there) since this thread is already all over the place and not necessarily easy follow-up on (without first reading through nearly 60 messages, some of them being questions of principle not really related to this particular question) 
.