Validation Error Messages Not Logged In Console Window (FM12)

[Sherri_McCue]

When I save a structured documents as XML (File -> Save As – XML), messages and errors appear in a Console Pod but are not reflected in the Console Window or in consfile.txt

Any help appreciated.

[shoose]

I have this problem also -- I need to capture the validation errors somewhere, but they are not logged to consfile.txt.  Is there a setting somewhere that controls what is written to consfile?

I am using FrameScript also, and have not yet found a way to capture these validation errors from the console pod and copy them to a file somewhere.

This seems like a serious bug or issue in Frame, that errors just disappear and are not logged anywhere, unless there is a workaround.

I'm now on FM 2015.

Thanks much,

Shelley

[Wiedenmaier]

Hi,

this is due to FM 2015 and lower writes XML messages to console pod. Other Messages are written to console window and These messages are also written to console.txt

Within FM 2017 behavior changed. Both messages are written to the same console pod. BUT XML messages are still Not written to console.txt file.

Not sure if you can get these messages, when registering for some events in your clients or if you open XMLs by yourself and check openresults.

I wouldn't call it Bug with FM 2015 and lower. But with FM 2017 I would expect same behavor for all messages

Markus

[Wiedenmaier]

I'm never used the console.txt file for error handling in all the years.

XML messages that appear are validation issues mostly. So you can check the root element if structure is valid after document is opened or before it is saved.

Other issues are due to an inconsistent environment, XML application. So once your Setup is correct, there is no need anymore to check console.txt.

Markus

[shoose]

Markus -- Thanks for taking the time to reply.

We work in an environment with multiple writers, and sometimes someone edits a file in a way that renders it invalid, thus causing parsing messages in Frame. We have everything set up in automation because the products have a large set of documentation that we cannot maintain by hand -- so these parsing errors can just "fly by" during HTML and PDF generation without our knowing that a document is in a bad state.

I therefore need a way to capture these errors, hopefully through FrameScript since FM obviously cannot do it natively. It sounds like, even in FM 2017, these XML parsing errors are not logged to console.txt, unfortunately.

We currently grep console.txt for logged errors relating to broken xrefs, which works well. If console.txt captured a more complete set of errors/logs, it would be highly useful.

Thanks,

Shelley

[Wiedenmaier]

Shelley,

I'm with you, and I think this is a "bug" in FM 2017 (not before) which should be fixed in FM. So that all messages which appear in FM Console are written to console.txt in the same way. Perhaps Adobe's listening 🙂

But as there is no solution and I have no idea, I think you have to find a way around that. I understand that users (as we all) are  making mistakes and this leads to invalid XML files und to problems within publication processes.

To solve this issue and as you are alread working with ExtendScript/FrameScript you can catch these errors easily.

1. Get the highest level element from MainFlow

2. Get the FP_ValidationFlags property of the element. If it's 0, everything is OK otherwise to some error handlings

For more Information see the FDK Programmers Reference and search for "Element validation properties". If you don't have the reference you can get it from here Framemaker Developer Center | Adobe Developer Connection .

If your EDD and XML environment is consistent, this should solve your problems with invalid structures.

My be you will have problems with missing graphics referenced in your XML file. IMHO FM logs this also to this console and not to console.txt. To check this loop the documents for all Graphics of type FO_Inset and check if file is existing.

I don't know of any other problems reported when XML files are opened and your enviornment is setup correctly.

This all can be part of your Validation functionalität. One part of it greps console.txt and the other parts check the document. And in Adobe fixes this issue in future, you can simply remove your code and grep console also for these kind of problems.

But as already said; I always validate the document and don't care console output. One reason is: so I'm sure that what I check is correctly and the other reason is I have not to worry if Adobe changes the log text in any release.

Hope this helps

Markus

[Sherri_McCue]

I concur that it is a bug that makes automation (machine-driven) validation more difficult than it should be. What is the point in having a console pod that has errors that never get to the console and more importantly console.txt. Adobe please fix.

[Russ Ward]

With ExtendScript, you can get the contents of the pod with:

var consoleText = app.FMConsoleString;

...Then you could write it to your own file or whatever. You could tie it to a "save" notification for best results. I did this in a previous release because the pod popped up every time you saved XML, successful or not, and the intrusion was way too intrusive. So I wrote this little script that monitored the contents of the pod for errors only, then I manually hid the pod in the corner of my window so I never had to look at it.

Russ

[Wiedenmaier]

Nice approach Russ, wasn't aware about this property.

Thanks for pointing that way.

[shoose]

Russ -- That does sound like a nice approach.  I have not used ExtendScript -- just FrameScript.  Do they play well together? Could a FrameScript call out to an ExtendScript or vice versa, do you know?

[Russ Ward]

Shelley,

I don't know much about FrameScript, but my guess is that they should work together. That is, you should be able to call an ExtendScript from within a FrameScript with CallClient (or whatever the FS equivalent is). However, you might want to contact the FrameScript people to see if they support this property first. Maybe it is already there and you don't need ExtendScript.

You might also think about adding some custom behavior to assist your post-processing. Not to encourage scope creep, of course, but you know that if you are retrieving and writing the messaging yourself, you can parse it and modify it along the way. All within the FM scripting. You could send it over a socket connection to some listening agent on another server. You could probably have the script email you whenever anyone screws up. Or, you could just write the stuff to a file like you originally wanted

Russ

[Wiedenmaier]

You can execute ExtendScript out of other plugins with

F_ApiCallClient((ConStringT)"ScriptingSupport", „[Path]\YourScript.jsx“) ;

So I'm sure you can also call this from FrameScript-Plugin.

Markus