Skip to main content
Inspiring
March 24, 2025
Answered

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

  • March 24, 2025
  • 2 replies
  • 1474 views

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")
}
Correct answer Dirk Becker

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


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. 

 

2 replies

Community Expert
March 26, 2025

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

-Manan
Inspiring
March 26, 2025

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

Legend
March 26, 2025

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


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.

 

 

Robert at ID-Tasker
Legend
March 25, 2025

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

Inspiring
March 25, 2025

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
Legend
March 25, 2025

@Alex25077296wbvx

 

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