Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X
Hi Folks,
I am currently testing out our Arbortext customizations/environment using Arbortext 7.0 M030 (as we are planning on an upgrade from Arbortext 6.1 M020).
So far, I have managed to fix the toolbar issues (it seems some button icons were not recreated using the newest style) - this was fairly simple to create some new buttons based on the old design. - so this works. and I also fixed a few other issues with our toolset.
However, while PDF composition appears to work well with our current custom stylesheet/schema setup, I have noticed the following error in our event log after the publishing cycle ends:
ERROR: File Save Error: The file "{#APPStyler}_compose.$$$" could not be created.
ERROR: Cannot access file "{#APPStyler}_compose.3ns"
I have been tracing through various acl files, etc trying to determine where Arbortext may be trying to save a file that resembles this - however, as I am sure most of you know, the publishing process is fairly complicated.
I did find a file called _compose.3ns in the \Program Files\PTC\Arbortext Editor\app\libs\APPStyler folder - which resembles the file mentioned in the error log. However, I can't imagine that Arbortext would be attempting to save a file within the program files folder.
So how would one approach trying to determine what part of the process has failed. Clearly I am getting output, but I don't like seeing errors in logs.
Any advice is greatly appreciated.
Thanks,
Rob.
Solved! Go to Solution.
Well folks,
After working on this issue for a few days, we have managed to determine that it is an odd interaction with a 3rd party math product and publishing with the APP engine and also having debugcomposition=on.
We stumbled across this when we deleted the window configuration file (arbortext.wcf) in the user appdata folder. I compared the old file with the recreated version - and this flag jumped out at me.
With debugcomposition=off, the issue goes away. I must have turned this on at some point to try and debug another issue and forgotten to turn it off.
Hopefully this helps someone else in the future.
Thanks,
Rob.
If you are using a .style file and this is happening, then it is likely that some edited source "APP overrides" might be conflicting with the new version? Have you tried clearing the APP edited source from your .style file as a test?
The error you see "shouldn't happen" (are you testing with Styler on desktop or PE on server?) and the file you found is the correct one. {#} is the internal APP way of finding a library, and {#APPStyler} should redirect to the APPStyler library folder you found. The .$$$ message is APP's own message when it can't overwrite a file (why it would want to overwrite a system file like _compose.3ns is the confusing part).
Thanks once again for providing some advice, I'll poke around the APP overrides and see what I can find. I am not an APP expert, but will try and isolate the issue.
Thanks,
Rob.
Forgot to mention, I an just using the editor on desktop - No PE.
Reporting back - I see they just released V7.0 M040 today, so I rebuilt my environment since I might as well test with the latest.
I deleted every override (APP or otherwise) in my stylesheet and any linked module. I re-saved them and also did the Tools>Validate Stylesheet and got the No Errors message.
I am guessing that given I get output, that it isn't something major - however, I'll likely open a ticket with PTC to see if they can determine the cause. Our application setup has worked well with Arbortext 6.0 and 6.1 throughout various maintenance releases.
Thanks for the suggestions.
Rob.
Well folks,
After working on this issue for a few days, we have managed to determine that it is an odd interaction with a 3rd party math product and publishing with the APP engine and also having debugcomposition=on.
We stumbled across this when we deleted the window configuration file (arbortext.wcf) in the user appdata folder. I compared the old file with the recreated version - and this flag jumped out at me.
With debugcomposition=off, the issue goes away. I must have turned this on at some point to try and debug another issue and forgotten to turn it off.
Hopefully this helps someone else in the future.
Thanks,
Rob.