I assume you are using APID.
What does your spln do?
It's not using APID.
The error message gives a line in the XHTML plugin as a fault,
but I think it's a line in my own plugin.
Don't know why it gives the XHTML plugin as the source.
Without knowing what you are doing, it's hard to guess why you are
getting that error.
You are probably removing some data which is used by the XHTML code...
could you insert an empty line in your code to verify that line 381 (or then 382) is causing the error? (one of my scripts is also used by the customer but line 381 is a comment.)
to reduce confusion let's call a script a script rather than plugin, even if it is delivered as jsxbin.
Isolation into a target engine is good, but the target engine is not at all indicated by the error message, so do not assume this is an issue.
The error is about a strange file "6" containing at least those 381 lines, which during initial execution (when its functions were defined / installed) was located within that XHTML for Digital Editions subdirectory. If there is no such file, it could already be removed when the error pops up, who knows. That is, unless InDesign lies about the source file, but I have never heard of that.
It would also be good to know whether your script uses try-catch brackets in all its entries (menu callbacks or other handlers), or why not. If this is new to you, this way you can intercept any system error message like the quoted one which is a very generic one, and add your own comments such as "while performing this/that task" or other context information. You could then also recover gracefully from any errors such as a stale references to a deleted object. For the beginning though, you can at least find out whether the problem is at all within your code.
It is also generally good practice to have an option ready in source code that produces an exhaustive log file for any general steps but also caught error messages. It is not like walking around with a debugger, but you can find out the call chain and general area of code involved when the dreaded dialog pops up again.
Finally if it is the same problem as mentioned by Ralf, you should better get in direct contact with him - this forum has a personal mail feature and probably both of you have a phone ;-) .
I am sure now that Indesign is lying about the source of the error
and that the error is in my own script.
1. I have removed the XHTML For Digital Editions scripted plugin.
Indesign is now giving this path as the errorsource:
There is no file "6" in my Documents folder.
2. I know now that the error in my first posting is in my own script and
that it stops at line 381. I have changed the order of execution and now
another line in my script is displayed as the errorsource and it's stopping
at the same code.
So Indesign is definitely lying about the filename. I think this happens
with .jsxbin files. The question is why?
I've never seen anything like that. Without seeing your code, I would
not even know where to begin guessing...
Harbs is right on that we're at a level of flat guessing. My first guess is that the 6 is the 6th invokation of something temporary, along the lines below.
Note that with this script, executing straight from ESTK, I did not see any message close to yours. The access of the deleted tf within the alert was intended to reproduce the error number, but here it gives just a flat "Undefined". So it must be a different way - could be app.doScript, $.evalFile, #include, or maybe the menu handlers number themself ? anonymous functions, or any combination of these possibilities?
var whine = "\
var tf = app.activeDocument.pages.item(0).textFrames.add();\
// more padding