afterOpen Event listener in Indesign throws up error of cannot handle request because a modal dialog

[Alex25077296wbvx]

This is driving me nuts now!

What I'm trying to achieve is from a start up script that has an afterOpen eventListener then adds a 

afterSelectionAttributeChanged eventListener (I'm not sure if this is the best thing to use?) to each document that is opened. This would then check any images that are placed for their itemLink. However I'm getting an error message come up saying cannot handle request because a model dialog or alert is active. I don't have anything active. Strange thing is if I put an alert after the 'var doc = app.activeDocument;' line that breaks the script the script then works. Can anyone please explain what's happening? I have put a simplified version of where I am

#targetengine 'cantoImageCheck'

main();

function main() {
    remove_listeners('afterOpen');
    app.eventListeners.add('afterOpen', myfunc);
}

function myfunc(event) {
    if (event.parent.constructor.name !== 'LayoutWindow') return; 
    var doc = app.activeDocument; 

    //alert("Here1")
    if (!doc.eventListeners.itemByName("changeAtt").isValid) {
        var afterImportItem = doc.eventListeners.add("afterSelectionAttributeChanged", hasBeenFired)
        
        afterImportItem.name = "changeAtt"
        
    }
}

function remove_listeners(eventType) {
    var listeners = app.eventListeners;
    var i = listeners.length;
    while (i--) if (listeners[i].eventType == eventType) listeners[i].remove();
}

function hasBeenFired(e) {
    alert("Fired")
}

[Robert at ID-Tasker]

Maybe in the main(), before adding Even Listener - insert this: 

app.scriptPreferences.userInteractionLevel = UserInteractionLevels.NEVER_INTERACT;

https://www.indesignjs.de/extendscriptAPI/indesign-latest/#ScriptPreference.html#d1e335803

[Alex25077296wbvx]

Thank you for your reply but that hasn't worked, I'm still getting the alert, is their maybe some other approach I could take to get around this?

Thanks again

Alex

[Robert at ID-Tasker]

@Alex25077296wbvx

Sorry, I'm not JS guy, maybe @rob day or @Peter Kahrel can be more helpful.

[Manan Joshi]

When do you get this error? I tested the script on 2022 and 2025 versions on a MAC and I did get alert fired on creation of a text frame after creating a document. I did get a crash on trying to close the document though, maybe you need to remove the listener on onclose event to fix the crash. Another thing that I noticied in your code is that you are removing all the afterOpen eventlisteners, this would remove even the ones registered by other scripts. Do you really wanna do that?

-Manan

[Alex25077296wbvx]

Hi, thank you for your reply, the error comes up whenever I create a new document it's ok if I open an existing document and also if I put an alert message in before I add the listener to the document this seems to then allow it to work so I wondered if I'm trying to add a listener to a document that hasn't been properly created yet? if so what would I do about that? Also you are absolutly right about removing the afterOpen I did not intend that, I presume I should do that by giving it a name and searching fot that? I have put a screenshot of the message I'm getting. 

Thank you for taking the trouble to help with this

Alex

[Robert at ID-Tasker]

Hi, thank you for your reply, the error comes up whenever I create a new document it's ok if I open an existing document and also if I put an alert message in before I add the listener to the document this seems to then allow it to work so I wondered if I'm trying to add a listener to a document that hasn't been properly created yet? 

By Alex25077296wbvx

That's most likely the problem. 

[Manan Joshi]

It did not error out for me as I tested with creating a new document itself. I am not sure why it fails for you and even if it does what does the modal dialog have to do with this. Did I suggest you to try this on a different computer? Is this a MAC or a WIN you are testing on? I tested on a MAC

-Manan

[Alex25077296wbvx]

I'm on a Mac and I agree I can't understand why this dialog comes up it seems to have no relevance

[Robert at ID-Tasker]

I'm on a Mac and I agree I can't understand why this dialog comes up it seems to have no relevance

By Alex25077296wbvx

So you don't see any other dialogs - beside the one you've posted? 

[Alex25077296wbvx]

No just that one

[Robert at ID-Tasker]

No just that one

By Alex25077296wbvx

Have you tried adding this user interaction level line at the BEGINNING of the main? 

Before remove_listeners()?

Not in between as I've initially suggested. 

[Alex25077296wbvx]

Tried it still doesn't work

[Dirk Becker]

Try the other new-document dialog.

[Alex25077296wbvx]

Hi, sorry I don't know what you mean by that?

[Dirk Becker]

Sorry, the forum software misplaced my response to @Manan Joshi .

@Alex25077296wbvx as you mentioned new documents: InDesign has two versions of the "New Document" dialog, you can choose the old one via Preferences.

Maybe the new dialog sticks around too long, colliding with your event handler. Pure speculation: The new New Document dialog is written in UXP which runs in a different thread and postpones operations such as finally discarding the dialog via a queue. I faintly remember the dialog was once mentioned for similar trouble, and I remember coming along that queue while debugging something else.

If so, your interfering alert() may have flushed the mentioned queue. Better use $.writeln() output to VSCode console, or write a log file.

More theory:

Many InDesign dialogs have a Preview checkbox. Using that preview means all changes within the dialog are enclosed in a sequence/transaction similar to app.doScript … ENTIRE_SCRIPT, so they can get rolled back when you click cancel. This pending sequence caused trouble when scripts are executed, so almost all script operations "requests" involving the native DOM result in your error dialog. That's even if the offending dialog does not use Preview, because the check does not differentiate the dialogs, it is even a problem with ScriptUI dialogs.

A script can check the condition – is there any dialog open – via app.modalState.

You can read that property from within your handler and return rather than causing the error.

Explicitly allowed methods (there is a mechanism for that) are count(), extractLabel(), addEventListener(), removeEventListener(), activate(), doScript(). So your problem could be your call to doc.eventListeners.itemByName().

Another approach: most events do bubble. So instead of adding your handler to every document, you add it to the application once. Still, wading thru all "afterSelectionAttributeChanged" will slow down the application. Maybe PageItem.AFTER_PLACE works for you? It also bubbles.

[Alex25077296wbvx]

Thank you so much for your help on this. I put in a test for the app.modalState before adding the listener and that was reporting true only I don't know what to do about it? Is there anyway to clear it rather than just break the script with a return?

When you said use $.writeln() instead of the alert how would I use that? Can I use it to, as you say, flush the queue like the alert was doing but not require putting an alert up?

I tried adding the listener to the app but it seemed to give the same result.

Thank you once again for all your trouble

Alex

[Dirk Becker · Accepted solution]

app.modalState just confirms that your handler is triggered when it is limited in its actions. You have to rewrite your code, avoiding what causes the problem. Find the exact statement, then think of alternative ways. E.g. if it is that itemByName, do you really need it?

Using debug output via $.writeln, or writing to a log file are means to get closer, as you found that alert() was interfering with the problem. It does not solve the problem itself. If you don't know how to use a debugger please open a separate thread or ask any AI .

Your main problem as of now appears to be the new New Document dialog, where the event listener is triggered too early - comparing to the legacy New Document dialog. If you insist on using that approach, file a bug at uservoice and wait until it is hopefully fixed.

> I tried adding the listener to the app but it seemed to give the same result.

As we're talking about multiple listeners here, which one was added to the app? Did you remove the others? Following my suggestion using a single event handler (your hasBeenFired) at the application that takes advantage of bubbling, rather than one at each document, you should have eliminated the need of a handler for AFTER_OPEN whose only purpose is to install those individual document event handlers. 

[Alex25077296wbvx]

Thank you so much for all your help, removing the after open and adding the listener to the app has worked 

Thank you 

Alex