UXP | appplication - afterSave - eventListener | e.target.name

Question

Hi, when I try to reference e.target.name (should be the document name) from an afterSave event i get nothing.

I'm logging 3 lines but since "e" is messed up when I log just "e" I can't access anything, when I try "e.target" the whole line isn't even logged.

video: https://streamable.com/ispiob

This is for a UXP plugin.

Here is the relevant code:

import {app} from "indesign";
import {uxp} from "./globals";

async function saveDoc(e) {
    console.log("saveDoc has been triggered.");
    console.log(e);
    console.log(e.target);
}

function addEventListener() {
    app.eventListeners.everyItem().remove();
    app.eventListeners.add('afterSave', saveDoc)
    app.eventListeners.add('afterSaveAs', saveDoc)
}

uxp.entrypoints.setup({
    plugin: {
        create() {
            addEventListener()
        },
    },
});

export const App = () => {
    return (
        <>
       ...
        </>
    );
};

Thanks!

Dirk Becker · Answer

In short: try without async.

If that does not work:

Back in 18.5 I tracked down a similar problem from the C++ plug-in side.

The main thread of InDesign creates the event object referring to intermediate storage on the target, passes it on to the subscribed handlers and destroys the intermediate storage on return. It also considers flags set by the handler callback by means of event.preventDefault() and alike. Even if you remember the event object during your handler e.g. by storing it in a global (similar to your use of console.log), the backing data will be gone.

Now add UXP's general async processing in a separate thread (not your use of async). This means the event callback is pushed into some queue across the threads, the main thread continues immediately and again cleans up the intermediate storage before the UXP thread comes along for processing.

Only (much) later on the InDesign main thread becomes ready to handle any other script request sent by UXP, including your getter for the event property. The event object is still there waiting for garbage collection but anything backing is already gone, so it is likely throwing an uncaught exception - wrap that other console.log with a try-catch.

Event handlers in UXP can only work if the native main thread event processing itself (the original caller of the event callback) would be busy-waiting for the async handler in UXP thread to do its thing, on the way process all further script requests incoming from UXP such as your property getter but also anything else (remember, UXP could be running plenty other async activity before its separate queue reaches the handler callback). Such a processing was completely missing back when I checked in 18.5, and I don't know whether it was added since then.

For my UXP plugin I was lucky and could work without event handlers at all, besides my business logic still sits in ExtendScript (where event handlers continue to work) and only communicates with UXP for its UI. I'd suggest the same (use ExtendScript via app.doScript) until the problem is resolved.

Note that it could already be resolved for synchronous handlers, but by declaring your handler function async you actually are asking for async processing with all associated troubles. So first try without explicit async.

UXP | appplication -> afterSave -> eventListener | e.target.name

1 reply

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded