Open oddgames-david opened 10 years ago
@timothynoel Can you comment on how doable this would be?
To elaborate on what @oddgames-david is looking for: He's running JSX code through Generator that changes the image. That results in an imageChanged event coming back. He'd like to know which imageChanged events are the result of Generator JSX execution, and which are the result of some other action.
I've assigned this bug to @timothynoel because I think he's the man to comment on how doable this is. It would almost certainly require some change in the PS binary.
You can already determine if Generator JSX or any other event is "currently" executing and its transaction id, via the new (kPSNetEventStatus) we added for 14.2, but I don't think it's sufficient to solve the problem at hand, since you have a timing/race-condition where pending Generator JSX could start/finish right after you get the event status back.
But we could put the event info that we send with kPSNetEventStatus (what event was executing, and any associated transaction id) into the imageChanged messages. Photoshop sends the imageChanged messages after any pending event has finished executing and executes Generator JSX at idle time, so there shouldn't be a case where you get a change message that has changes from both JSX and non-JSX (like a user event or other PS command) changes.
@oddgames-david to clarify @timothynoel's comment a bit: Photoshop itself has a new feature in 14.2 where clients connecting to PS (such as Generator) can find out what PS is up to at any point in time. That's the kPSNetEventStatus
that he's referring to. Unfortunately, due to engineering staffing levels (i.e. I've got about 18 different projects going) an API for this hasn't been added to Generator yet.
Even if this API did exist, I think @timothynoel is right in that this data wouldn't be quite enough information to get the job done. The ideal solution here would be to put event info / transaction IDs into imageChanged messages.
@timothynoel how hard is that?
I'd like to know if an incoming imageChanged event was directly caused by evaulateJSXFile or evaluateJSXString so I can ignore it.